I’m familiar with Wireguard and happy to see it made it into RouterOS.
Recently I upgraded some devices to 7.x and thought about giving it a try to replace some OpenVPN tunnels and NATted instance of Wireguard (VM).
It’s working smoothly so far but I witnessed two things, that may not be related to Mikrotik/RouterOS rather to Wireguard’s code.
1 - I have an HAP AC^2 (7.1.1) behind a RB2011 (6.49) and wanted to use the access point to establish a Wireguard tunnel towards a RB1100AHx2 (7.1.1).
The HAP AC^2 did not initiate any traffic (no rx, no tx, added a firewall rule to log that traffic, no nothing) until I added a persistent keepalive - That’s when it started initiating the connection and it’s working just fine now. Provided there is an endpoint specified in the peer, shouldn’t it initiate the connection without any keepalive setting configured?
2 - In the other hand, I declared two peers on the RB1100AHx2 with no endpoint. My understanding is that they’re waiting for a connection from a remote device and not initiating anything.
Oddly enough one is trying to establish the tunnel but not the other one.
For the one having some TX, log say “Handshake for peer did not complete after 5 seconds, retrying (try 10)” but not for the other peer.
Thank you
Not big issues but was just wondering if there aren’t small bugs here.
If I understand that right, Wireguard only establishes the connections on demand, i.e. until there is a packet for the remote peer, Wireguard doesn’t send any transport/control packet to that peer. This can be overridden by enabling the persistent keepalive. Would this explain also your case 2?
I’m eager to know how could you establish the connection without the port of the endpoint ( site to site ) cuz if it’s empty it doesn’t mean that it will use a default port.
Awesome. That was exactly the issue!
In one case tunnel didn’t establish until there was a packet for the remote peer (allowed address) and keepalived “fixes” it. It’s logical for a stealthy protocol.
And reason why the other tunnel has some TX traffic is because there’s something behind the Mikrotik that tries to reach the other end of the tunnel. Odd thing is, since I’m expecting the remote location to connect, there is no endpoint. Wondering what wireguard is trying to do if there’s not remote endpoint defined.
And this is what could be a bug. The stack has to send the packets in order to establish the connection, and it apparently counts them as sent, but since no destination is known for them, neither a configured one nor an auto-learned one, it doesn’t actually send them anywhere. If the bug is even worse, it sends them to some bogus IP and port.
That was my point if that peer would just receive a tunnel from any IP that was correct to leave it. but as it isn’t it’s a site-to-site it should have an IP and also have to know the endpoint port. cuz its a blank right now it won’t use the default WG port.
I see my assumption was these peers on the screenshot are referring to different sides of the tunnel. But now I can see they are both peers at the one device?
@dynek
No need, That’s on me. I don’t want to be stubborn about this but at the same time I did set up an STS for my self I’m not behind CGNAT, But I know an OP that was doing the same thing and was behind CGNAT and it did work just fine. I still think this is a config-related issue. Can I have the config out of the curiosity?
When configuring the peer on the server site for device which is behind CGNAT, set the internal IP of the “client” as endpoint address. Use the same port.
The client will go out using the public accessible IP and endpoint port of the server and establish the WG connection.
At that moment the server will “see” the internal IP of the client and establish the connection as well.
That’s how I have it. And it works.
Or did I misunderstand the issue here ?
I was high as I’m right now when I was reading this topic but then… . Thats why I’m asking for the config. the endpoint could be NS record or IP.so even behind the CGNAT you could establish your Connection with DDNS and if you have the same IP range in both interfaces with correct routing. then it’s all good. But as I don’t know the full scenario I cant be sure if I’m right or not.
