Sorry if this is redundant, but I wanted to post a possible bug regarding wireguard tunnels:
Upgrading Routeros 7.13.4. to 7.14.1: working Wireguard tunnels (eg to NordVPN) fail to TX (no change in config). 0 bytes send/received, error # increasing.
Downgraded → same problem
Upgraded again → problem still there.
Then changed the private/public keys in the interface as well as in the peers to WRONG keys and applied. Then entered the correct keys again, applied and voila: everything is working again!
I have encountered this bug many times. It has driven me nuts over and over. The linked thread looks like a different issue to me. I don’t have an issue with too many logs, but as described in licht77’s post. TX goes up but RX stays at zero and no connection. I remove the client endpoint, apply, add it back, apply and things start to work. I’ve encountered this at least 5 times and now 100% sure of the mechanism. It applies when both ends have a client endpoint specified. Before someone says that maybe it’s not meant to work with my config, then it has to be a bug when it starts working. In one way or the other it’s a bug. I am on 7.20.1
Do both ends have public IP addresses or is any of the two peers behind NAT/CGNAT? When the tunnel is running and also when it's not running, can you compare the values of Endpoint and Endpoint Port, with the values in the read-only fields Current Endpoint Address and Current Endpoint Port below them? Are there any mismatch?
If one side is behind NAT or CGNAT, that side should turn on Persistent Keepalive (set to 25s for example).
1.Why do you have this rule? add action=accept chain=input comment="Allow wireguard UDP connections" dst-port=13233 protocol=udp
Clearly the router is client peer for handshake and therefore not expecting an incoming connection to be originated at the other end hitting this router.
Just left over from trying different stuff. With both ends being fixed public IPs either end could initiate the connection. My understanding of wireguard is there is no persistent connection, so if I turn off keep alive then either end could send packets. I quite often make rules like that when setting stuff up “just in case” and then delete them if the byte count is zero.
Obviously RouterOS is not bug free, but in my experience, these things could always be traced to two non-trivial (but not bug) causes:
Wireguard equips handshakes with timestamps. In order to prevent replays, these have to be monotonic. Timestamps going back in time lead to failed handshakes. Disabling and enabling (or removing/readding) the peer resets the stored value.
Wireguard is often NAT-ed. With the relatively fast handshake retries, a nat entry that should be updated isn't allowed to expire. Changing the interface port or disabling the peer for long enough to let the conntrack entry expire fixes this.
Of course if you have a reproducible bug, preferably without nat and with monotonic clocks, let MT know.
I think I may have tracked down the issue. I have 3 MT routers like this
Source router 192.168.10.1 (Main LAN) → 10.8.8.2 (VLAN98 for WAN to SXT)
Default route to 10.8.8.1 (no NAT)
SXT 10.8.8.1 (VLAN98) NATted to LTE1
Destination router with fixed public IP
I had a firewall rule in the SXT to forward 192.168.0.0/16 to internet to cover myself for any LANs I might create (this is all testing at the moment). However the interesting thing was the packets for the wireguard connection didn’t have a source IP of 192.168.10.x as I expected. MT set the source as 10.8.8.2, skipping 1 hop. One of those things that makes sense once you know. But here is the interesting thing, I have 2 WG connections setup and one of them was working. That was really baffling me. So this is what I think happened. I setup 1 WG connection, got it working. I added the firewall rule because the SXT initially had no rules at all. Then I setup the second WG connection. Maybe connection tracking was holding a connection open? I rebooted both routers but never the SXT. @lurker888 is that what you’re talking about above with NAT?
