Deleted for privacy / account security
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.
Deleted for privacy / account security
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.
Deleted for privacy / account security
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…
Deleted for privacy / account security
Deleted for privacy / account security
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
Deleted for privacy / account security
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
Deleted for privacy / account security