ROS7.5-Wireguard Site to Site

RouterOS General
1

Summary:
2x RB3011 ROS 7.5,
-The wireguard tunnel is up,

  • From terminal in winbox and from either side, I can ping the remote router lan and devices on the bridge, like servers and whatnot. I can also ping both tunnel interfaces.
    However:
    From a lan device, I can ping both tunnel interfaces, but not the remote router or lan devices

It seems the router knows how to route properly, lan packets can find both ends of the tunnel, but lan devices can’t route to devices on the remote lan?
Seems easy right…packets from the bridge, can’t find their way to the tunnel…but I have the route in place that should make it work…arg…frustrating…here is the relevant config

HQ Config

/interface wireguard
add listen-port=13231 mtu=1420 name=WireguardHQ
/interface wireguard peers
add allowed-address=192.168.252.0/24,10.10.10.1/32 endpoint-address=\
    104.220.147.143 endpoint-port=13232 interface=WireguardHQ \
    persistent-keepalive=10s public-key=\
    "mykey"
    
    /ip address
add address=192.168.254.254/24 comment=defconf interface=bridge network=\
    192.168.254.0
add address=12.30.127.98/27 comment="WAN " interface=Ether1-Outbound network=\
    12.30.127.96
add address=172.16.20.1/24 interface=CCRead network=172.16.20.0
add address=10.10.10.2/24 interface=WireguardHQ network=10.10.10.0

/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=12.30.127.97
add disabled=no dst-address=192.168.10.0/24 gateway=192.168.254.200
add disabled=no distance=1 dst-address=192.168.252.0/24 gateway=10.10.10.1 \
    pref-src="" routing-table=main scope=30 suppress-hw-offload=no \
    target-scope=10

Remote Office:

/interface wireguard
add listen-port=13232 mtu=1420 name=WireguardRock
/interface wireguard peers
add allowed-address=192.168.254.0/24,10.10.10.2/32 endpoint-address=\
    12.30.127.98 endpoint-port=13231 interface=WireguardRock \
    persistent-keepalive=10s public-key=\
    "mykey2"
    
   /ip address
add address=192.168.252.1/24 comment=defconf interface=bridge network=\
    192.168.252.0
add address=10.10.10.1/24 interface=WireguardRock network=10.10.10.0
/ip route
add disabled=no distance=1 dst-address=192.168.254.0/24 gateway=10.10.10.2 \
    pref-src="" routing-table=main scope=30 suppress-hw-offload=no \
    target-scope=10

Now this I see this, it’s odd that the remote office doesnt show the other routes…

2

Routes dont necessarily show up on the /export config. (as dynamic routes wont show)

Its best to view current routes using /IP routes and paste that separately just be sure to cover any public IP info!!!

(1) The one thing I would change is the IP routes you have correctly created for the subnets to get into the tunnel (either origination or return traffic).
Use the wireguard name vice IP address so.

Server: add dst-address=192.168.252.0/24 gateway=WireguardHQ routing-table=main

Client: add distance=1 dst-address=192.168.254.0/24 gateway=wireguardRock routing-table=main

(2) The only other change, assuming most of the time the HQ will be on the receiving end of initial traffic (the wg server) is to modify the IP allowed IPs of the Rock (mostly client device).
/interface wireguard peers
add allowed-address=192.168.254.0/24,10.10.10**.0/24** endpoint-address=\

3

Well, I had high hopes for those changes, but I got no love. Behavior remains the same. Any other ideas?

My fall back would be to rebuild the HQ router from defaults…It has many ROS version upgrades for years and I am wondering if the changes they made a few years ago on how the bridges were built internally might be messing with me. But I am willing to try other ideas you may have…

4

I couldnt see anything else, and thus your rebuild plan makes sense.

5

FYI - After the factory default of the HQ router everything worked perfect. The HQ router had been in place for several years and gone through many upgrades. I suspect it just had a terd somewhere in the config that I couldn’t find…good thing rebuilds are simple when you are ready for them.

6

Been there, done that.
Experienced it myself too in the past.

And we’re not the first ones seeing things starting to work after a clean reset and rebuild of identical config.