Three remote sites are connected to Main office. Site1 and site3 connect to the Main Office via Wireguard. Site2 connects to Site1 and Site3 via radio links and has no direct link to the public internet. This is a ring topology in a remote area; multiple pathways to/from site are a design requirement to make sure data flows with maximum uptime.
Routing is done via OSPF. The link between Site1 and Main Office is fiber so OSPF cost=10. The Link between Site3 and Main Office is via cell modem so OSPF cost=500 to weigh it less favorably.
OSPF works as desired if a radio link between Site2 and one of the adjacent sites fails; meaning the alternative Wireguard path via WG-site3 becomes active with Site2 and/or Site3 remaining accessible via that link.
The problem occurs when the link between Site1 and the Main Office fails. The route via WG-site3 takes over for ~15 seconds and then the route via WG-Site1 takes its place in the routing table for ~35seconds before reverting once again to WG-Site3. This pattern continues indefinitely, causing an unusable flapping situation.
Once the route via WG-site3 becomes active, WG-site1 believes it has re-established its connection since the remote side of that Wireguard connection is available via the route throughWG-site3. This does not occur when using IPsec for VPN. I believe the issue hinges on the fact that Wireguard interfaces are considered to be in a running state regardless of whether there is actually a viable session with its peer.
It seems like there should be a workable solution, but as of yet, it has escaped me. I would like to continue using Wireguard since the performance is much better, especially over poor connections like cell modems. Configuration is included below. Thanks in advance for your thoughts and suggestions.
Code: Select all
Main Office router config:
/interface wireguard add listen-port=13230 mtu=1420 name=WG-site1
/interface wireguard add listen-port=13229 mtu=1420 name=WG-site3
/interface wireguard peers add allowed-address=0.0.0.0/0 comment=site1 endpoint-port=13230 interface=WG-site1 persistent-keepalive=30s public-key=""
/interface wireguard peers add allowed-address=0.0.0.0/0 comment=site3 endpoint-port=13229 interface=WG-site3 persistent-keepalive=30s public-key=""
/routing ospf interface-template add area=backbone cost=10 disabled=no interfaces=WG-site1 networks=10.10.128.0/30 type=ptp
/routing ospf interface-template add area=backbone cost=500 disabled=no interfaces=WG-site3 networks=10.10.128.4/30 type=ptp
/ip address add address=10.10.128.1/30 interface=WG-site1 network=10.10.128.0/30
/ip address add address=10.10.128.5/30 interface=WG-site3 network=10.10.128.4/30Code: Select all
Site1 router config:
/interface wireguard add comment="WG to Main Office" listen-port=13230 mtu=1420 name=wireguard1
/interface wireguard peers add allowed-address=0.0.0.0/0 endpoint-address=192.168.10.1 endpoint-port=13230 interface=wireguard1 persistent-keepalive=30s public-key=""
/routing ospf interface-template add area=backbone-v2 cost=10 disabled=no interfaces=wireguard1 networks=10.10.128.0/30 type=ptp
/ip address add address=10.10.128.2/30 interface=wireguard1 network=10.10.128.0/30
Code: Select all
Site3 router config:
/interface wireguard add comment="WG to Main Office" listen-port=13229 mtu=1420 name=wireguard1
/interface wireguard peers add allowed-address=0.0.0.0/0 endpoint-address=192.168.20.1 endpoint-port=13229 interface=wireguard1 persistent-keepalive=30s public-key=""
/routing ospf interface-template add area=backbone-v2 cost=500 disabled=no interfaces=wireguard1 networks=10.10.128.4/30 type=ptp
/ip address add address=10.10.128.6/30 interface=wireguard1 network=10.10.128.4/30
I'm working on the issue some more now and will attempt to launch a script via Netwatch to disable the B-A ospf interface when it's not available. I may also experiment with firewall rules to reject WG traffic going the 'wrong' way.
