I’m just beginning to dive into wireguard and I ran into a really weird issue:
Everytime my router gets rebooted I’m not able to route anything over any wireguard connection (i only got Roadwarrior ones as of now)
The wireguard connection itself works fine, and takes no time to establish but I cannot reach any other IP addresses in my WAN, including the address given to the wireguard interface on the concentrator I dial into.
The routing issue can be resolved when I disable and reenable the peer I’m connected with in the wireguard settings.
Afterwards the VPN connection(s) work(s) as expected until the next reboot.
I also tested:
-) waiting random amounts of time after reboot for my first connection
-) using different client listen ports (I got multiple wireguard interfaces) for different peers
-) disabling all but one wg-interface
-) reproducing the issue on other devices (tested it on RB4011 and RB5009)
All tested devices had RouterOS 7.14.3 running.
As a workaround I implemented a script that state-cycles the peers 30s after reboot.
Can anyone tell me if I’m doing something wrong or if that is a bug?
Without looking at the config, of both router and client peer hard to say.
This was a known issue but got resolved around 7.12 I thought.
Assuming your client peers have keep alive settings ?
IP address for the WG-interface is 10.253.250.254/24.
The issue really only shows up after a reboot of the router, when the WG-Peer hadn’t been disabled and reenabled. Afterwards the system works as expected for days (haven’t had more time to test, yet) until the router got rebooted or power cycled again.
Your wireguard setup is incorrect.
It would appear the MIKROTIK is acting as Server Peer for handshake and the roadwarriors/others are acting as Client peer for handshake.
To be clear each client must be defined on the MT device.
Using 0.0.0.0/0 as a matching criteria for traffic would mean that only the first peer would only get traffic as 0.0.0.0 matches all traffic.
ON the router get rid of anything other than the following,
On the client Peer
[Peer]
PublicKey =“&^&&^&&^&&^**&&” { this is generated by the MT Router and pasted here }
AllowedIPs = 0.0.0.0/0
Endpoint = 99.99.99.99:16385
Persistent-keep-alive=35s
Thank you so much for your help, I implemented the changes but the issue remains:
After a restart of the router no networks are reachable until the peers are disabled and reenabled.
Nevertheless my workaround with a script doing the statechanges automatically after reboot work so I’ll stop meddling with a ‘working’ config.
The problem might be the “client-endpoint=99.99.99.99” parameter in your peer config. I never had to specify this parameter in all my WG peer configurations in RouterOS. With that parameter, you tell RouterOS to listen only on the interface with that address for incoming WG connection for this peer. So, in your case, it might be that right after the reboot, the WG interface is already up, but the interface that should have that 99.99.99.99 address isn’t yet, or hasn’t obtained the address yet. And the peer has nowhere to bind to? Later when you disable-reenable the peer, the 99.99.99.99 address is already active and it works then.
Try to remove (clear) the client-endpoint parameter on the peer.
What the weird config tells me is that you probably used BTH or quickset or something to setup the wireguard on the MT.
If setup manually there is no client nonsense like that on the Allowed IP settings on Server Peer for any other client peer.
ITS
allowed IPs, Interface NAME, Public key DONE!!