Hi all, hoping someone can help me with this as I've been pulling my hair out for a few weeks now.

Long story short, I have 2x sites (imaginatively named SiteA + SiteB) and I'm having some issues getting Wireguard/Mikrotik to obey the rules I've setup.

As an example, I can ping the Site B LAN IPs from the Mikrotik at Site A and vice versa, but trying to ping from SiteA's LAN devices to Site B's LAN devices, it always fails. This is backed up with changing the interface on the ping command on each Mikrotik to simulate an end-device: I have IP routes setup to tell when things are trying to reach the alternate LAN, to use the Wireguard interface, but when inbound from any of the LAN interfaces (be it the bridge, the bond interface or the VLAN ..it doesn't seem to work).

When I try to ping the Wireguard interfaces of the local or the peer WG, it works fine from LAN devices.

Hopefully this is irrelevant, but each site has some EOIP tunnels for VLANs 20/40 respectively, these are important because the devices connected to those VLANs can only ever go across to the tunnel and should never go across the local internet directly. The idea at the time was that if the opposite side was serving the DHCP IP, then that's a fairly good safety net to prevent leakage. That and it's nice to have L2 on the opposite side for a few scenarios. They generally have no need to access the LAN/IoT subnets and is purely as a means for changing the public IP to the opposite site, as such they live in their own subnets (10.0.20.0/24 / 10.0.40.0/24). Anyway, EOIP has been working great at both locations, so I don't think this is related.

I've turned logging on for all firewall rules to see if it's hitting any of the drop rules, but I'm not seeing anything of value and I'm

I've thrown this diagram together and attached some configs, would really appreciate any help as I'm getting nowhere!

Diagram:

Pinging ? For what purpose is that?
If you wish to access devices or share devices or access internet/devices, those are actual requirements, pinging is just a tool.
Will look at the configs.

What is not clear is which device is intended to be the main server and which is intended to be the client.......... at least for initial handshake.
Also having 0.0.0.0/0 at both ends makes this an impossible setup. Its typically only viable at the client side.

Thanks for the reply!

I'm trying more than ping, but I'm just trying to validate basic connectivity with ping. I have some servers on both sides that I'm ideally trying to access over the tunnel within each VLAN of each site, I'm also trying to access those but having no luck. Just seems a bit weird that there's a route on the Mikrotik for how to reach the respective VLAN, the Mikrotik can ping it, yet the end-devices in each VLAN can't reach the other side.

I've removed the 0.0.0.0/0 from each side and the endpoint address from one of the sides as you suggested, results are still the same unfortunately.

Appreciate your help!

You didnt answer my question try again.
What is not clear is which device is intended to be the main server and which is intended to be the client ( for wireguard connectivity ).......... at least for initial handshake.????

Typically use the CPU with more oophm or the connection with best throughput.

Apologies for my misunderstanding, I did think you were referring to the initial handshake which is what I meant when I said I'd removed the endpoint address (from Site B)

I would consider Site A best to initiate the handshake, so I've went in already and removed the endpoint address from Site B so that Site A initiates the handshake.

Site A has the newer CCR2116-12G-4S+, and Site B has a CCR1036-8G-2S+ so I think this makes sense to do it this way.

Thanks for the help!

Yes, good idea to remove 0.0.0.0/0 if not intending to use internet at one of the ends........

Please post your latest two configs for me to look at........

See attached, thanks!

Update: so things are a bit weird..

I can ping/access resources on 10.13.37.0/24 in Site B from 10.0.70.0/24 in Site A.
Yet, I can't ping/access resources on 10.0.80.0/24 in Site B from 10.0.70.0/24 in Site A.

I'll see if I can get some testing done in the opposite direction to see what happens there.

For Testing of WG, remove needless restrictions on ICMP.
add action=drop chain=input comment=\
"drop ICMP traffic from the WAN Interface" in-interface-list=WAN log=yes \
log-prefix="[Drop WAN ICMP]" protocol=icmp
In general I find your firewall rules garbage.
Its also confusing to distinguish the configs using the same wireguard interface name.............. so change it to be clearer

The mix of bridge without and without vlans is highly disturbing as it complicates matters needlessly, but will muddle through..........
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Okay, once again NO clarity on what is the server and what is the client, both have keep alives both have input chain rules excepting traffic etc.....
I will modify the config so as to confirm Site A initiates the handshake and thus is the client and the Site B device receives the handshake and just for that process acts like the server. After the connection is made its peer to peer!!

Site A allowed IP for the other end should be 10.0.100.0/24
Add route for the other site b subnet.
Remove the input chain rule for handshake.
Remove the 0.0.0.0/0 from the allowed IPs.

Site A

/interface wireguard peers
add allowed-address=10.0.100.0/24,10.0.80.0/24,10.13.37.0/24
endpoint-address=siteb.domain.com endpoint-port=13236 interface=\
SITEA-WGD persistent-keepalive=25s public-key=\
"PUBLICKEYREMOVED"

/ip firewall-filter
REMOVE THIS RULE ITS NOT THE END POINT
(add action=accept chain=input comment=SITEA-WGD dst-port=13233 in-interface-list=WAN protocol=udp)

/ip route
add dst-address=10.13.37.0/24 gateway=SITEA-WGD routing-table=main
add dst-address=10.0.80.0/24 gateway=SITEA-WGD routing-table=main

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Remove the allowed Ips 0.0.0.0/0
Remove the keep alive, endpoint etc.... etc.....

Site B
/interface wireguard
add listen-port=13236 mtu=1420 name=SITEB-WGD
/interface wireguard peers
add allowed-address=10.0.100.1/32,10.13.38.0/24,10.0.70.0/24
comment=SITEB-WGD public-key="PUBLICKEYREMOVED"

/ip firewall-filter
add action=accept chain=input comment=SITEB-WGD dst-port=13236 protocol=udp
/ip route
add dst-address=10.13.38.0/24 gateway=SITEB-WGD routing-table=main
add dst-address=10.0.70.0/24 gateway=SITEB-WGD routing-table=main

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

FoR FIREWALL RULES, find the easy path. Remember the router will not allow any LAN traffic outbound through the tunnel that doesnt match destination address in allowed IPs. Additionally, the receiving wireguard will not let any remote subnets leave the Tunnel and enter the LAN unless they are in allowed IPs.
Also your forward chain rule are really screwed. YOu dont allow the wireguard IP to the LAN, you allow the subnets to subnets or single LAN ip to LANips or subnets....... like firewall for normal traffic.
The wireguard IP is not a single user or single device when its coming from a router.........
From your rules, ONLY subnets 38 and 37 actually traverse the tunnel.
We can delineate those on the outgoing traffic to simplify.

Site A:
/ip firewall address-list
add ip-address=10.13.38.0/24 list=Visit-By-SiteB
add ip-address=10.0.70.0.0/24 list=Visit-By-SiteB
add ip-address=IP-address-Admin-siteB1 list=Authorized comment="admin desktop site B"
add ip-address=IP-address-Admin-siteB2 list=Authorized comment="admin laptop site B"
add ip-address=IP-address-Admin-siteB3 list=Authorized comment="admin smartphone site B"
/ip firewall filter
add action=accept chain=input in-interface=SITEA-WGD src-address-list=Authorized comment="Remote admin access for config"
add action=accept chain=forward comment="wireguard outgoing access" src-address=10.13.38.0/24 out-interface=SITEA-WGD
add action=accept chain=forward comment="Wireguard incoming access" in-interface=SITEA-WGD dst-address-list=Visit-By-SiteB

Site B:
/ip firewall address-list
add ip-address=10.13.37.0/24 list=Visit-By-SiteA
add ip-address=10.0.80.0.0/24 list=Visit-By-SiteA
add ip-address=IP-address-Admin-siteA1 list=Authorized comment="admin desktop site A"
add ip-address=IP-address-Admin-siteA2 list=Authorized comment="admin laptop site A"
add ip-address=IP-address-Admin-siteA3 list=Authorized comment="admin smartphone site A"
/ip firewall filter
add action=accept chain=input in-interface=SITEB-WGD src-address-list=Authorized comment="Remote admin access for config"
add action=accept chain=forward comment="wireguard outgoing access" src-address=10.13.37.0/24 out-interface=SITEB-WGD
add action=accept chain=forward comment="Wireguard incoming access" in-interface=SITEB-WGD dst-address-list=Visit-By-SiteA

Thanks for spending some serious time on this, I've made the changes. Don't think I've missed anything..

Everything is similar to how it is now, but it's certainly a lot cleaner. Still not able to ping from clients in Site A to Site B etc.

The wireguard looks okay to me, so the issue is in all the EOIP and bonding stuff unfortunately.
On Router A there is no bonding and overly fancy stuff, so expect that you can ping subnets 38 and 70.
On Router B there is a whole hockey sock of extra rules so pinging issues to 37 and 80 are not a surprize.


Errors Noted!

(1) On router A, you have two local subnets of interest, 38 and 70.
Look closely at the Visit-By-B subnets, this address list is supposed to idenfity which local subnets users from Router B will be accessing, namely 38 and 70 but you have it down as 38 and 80!!!
The authorized list is correct assuming it consists of specific admin IPs existing on Router B.

add address=10.13.38.0/24 list=Visit-By-SiteB
add address=10.0.80.0/24 list=Visit-By-SiteB { should be 70 }
add address=10.0.80.32 list=Authorized
add address=10.13.37.2 list=Authorized

(2) Same issue on Router B, you have two local subnets of interest 37, 80
We use the firewall address list Visit-By-A to include both of these subnets as the ones allowed to be visited by users from Router A.
Thus users from Router A should be accessing subnets 37 and 80, you have them as 38 and 70, both wrong.
The authorized list is correct assuming it consists of specific admin IPs existing on Router A.

add address=10.0.70.0/24 list=Visit-By-SiteA { should be 80 }
add address=10.13.38.0/24 list=Visit-By-SiteA { should be 37 }
add address=10.0.70.11 list=Authorized
add address=10.13.38.2 list=Authorized
add address=10.13.38.200 list=Authorized

Oops, I misunderstood the order. I've updated those, and still no luck.

..From my client devices in SiteA/Router A (10.13.38.200/10.13.38.2/10.0.70.11), I still can't ping the alternate sites (can ping the WG IPs though). Strangely, it's still not an issue from the Mikrotik routers themselves ..and they appear to be utilising the Wireguard interfaces to get there according to traceroute (see attached)

I really hope the EOIP isn't the issue, because I rely on that and it seems like the most reliable way to effectively blackhole traffic if they were ever to go down.

I don't care too much about the EOIP devices seeing end-devices in either sites, it's just a means to get out onto the internet as if I was in the alternate location, so maybe there's something I could do to prevent any 37/38/70/80 traffic routing across to those tunnels?

I could go back to IPSec as I had that working fine previously, but I'd really prefer to use WG as it seems a lot more elegant/simpler ..which is obviously a plus when you've seen my rats nest firewall rules/general mess of the config.

Thanks again for your help, it's greatly appreciated!