I meant full config on MT device
/export file=anynameyouwish (minus router serial number, public WANIP informaiton, keys etc…)
(1) MT Router Client (B)
a.. the allowed IPs should be on the MT CLIENT (B) router…
Allowed address 192.168.100.0/24,10.11.11.0/24
Persistent Keepalive 25sec
b. What is with this IP route?
Static 10.11.11.0/24 - 192.168.100.1 ??
If you are either telling the local B router where to send traffic with that destination, OR, telling the local B router where to send return traffic from those users, then it should be:
add dst-address=10.11.11.0/24 gateway=wireguard1 routing-table=main
c. Can you tell me why you think you need an input chain rule for wireguard handshake on the client router ???
What you need on the Router B client is the ability to access the router for config purposes from both RouterB, RouterA and any remote admin access. So make a firewall address list called Authorized, including RouterB local LANIPs (wired or wired with static leases set), Router A local LANIPs ( wired or wired with static leases set) and any admin remote wireguard IPs ( android, laptop when remote, ipad etc.). I imagine this list will probably be the same list you can use for Router A, because regardless which Router you are physically at, you want to be able to get to the other router for config purposes AND when remote you want to be able to reach both routers. Thus on routers B and A, you should have, after the default rules..
add chain=input action=accept comment=“Admin Access” src-address-list=Authorized
d. For firewall rules I tend to be more open on the outgoing and then tight on the incoming wrt forward chain.
add chain=forward action=accept src-address=192.168.88.0/24 out-interface=wireguard1
add chain=forward action=accept in-interface=wireguard1 src-address=110.11.11.0/24 dst-address=192.168.88.0/24
e. Methinks you have an error in your firewall rules too:
forward udp src 192.168.88.0/24 dst 10.11.1.0/24 accept
(2) Wireguard Server Router (A)
a. assuming this is just a lazy typo?? ( and the lack of comma between the entities and the extra spaces )?
Allowed address 192.168.100.4/32 192.168.88**.0/24/24**
b. same comment as for router B, route should be:
add dst-address=192.168.88.0/24 gateway=wireguard1 routing-table=main
Personally to avoid confusion and always no what router I am looking at I would use different interface names for the wiregaurds.
WG-B, WG-A, WG-Server WG-Client, WG-Work, WG-Home, WG-Local, WG-Remote, lots of options LOL.
c. SAME SAME comments for input chain list to access router, here the input rule for handshake is appropriate.
With respect to firewall rules…
add chain=forward action=accept src-address=10.11.11.0/24 out-interface=wireguard1
add chain=forward action=accept in-interface=wireguard1 src-address=192.168.88.0/24 dst-address=10.11.11.0/24 comment=“allow RB users to RA subnet if required”
add chain=forward action=accept in-interface=wireguard1 src-address=192.168.100.4 dst-address=10.11.11.0/24 comment=“allow android to RA subnet if required”
The most important thing to join two clients is what I call RELAY… since its a peer to peer network the C location only reaches A, the B location only reaches A,
Thus to ensure that A and C can connect use the firewall rule.
add chain=forward action=accept in-interface=wireguard1 out-interface=wireguard1
What we are saying is that in your case Android or Location C, wants to reach 192.168.88.0. Android C device notes that allowed IPs=0.0.0.0/0 so this is permitted (as the device checks the destination addresses. The traffic is sent through the tunnel to Router A. Router A notes that 10.11.11.4 is an acceptable source for traffic (its on the allowed IPs as it checks for legit incoming sources). In effect the android traffic is now sitting at the LAN LEVEL at router A…
The router says okay I have this traffic for 192.168.88.0 destination, Hey wait, I have route for that I know where it should go, back into the tunnel towards peer B. The router checks to see if there is a bonafide dst address for this on the allowed IPs and finds yes at peerB, the final requirement is to allow that traffic from the tunnel to go to the tunnel!! Hence our relay rule!!
Would be extra handy if B and C were both routers etc…
In any case any remote wireguard device coming into Router A, will be able to reach Router B with this setup.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Okay so after reading this there is a glaring step we missed… hint reaching router B…
Well so android C has successfully travelled back into the tunnel through router A to router B with source address 192.168.100.4
Luckily we modifed the allowed IPs to include this as one of our first steps (192.168.100.0/24) …jolly good. So the wireguard code lets the traffic exit the tunnel.
But uh oh, the firewall says, who the EFF is this trying to come from wirguard to the LAN.
Thus we need to adjust the firewall rules to (on Router B)"
add chain=forward action=accept src-address=192.168.88.0/24 out-interface=wireguard1
add chain=forward action=accept in-interface=wireguard1 src-address=110.11.11.0/24 dst-address=192.168.88.0/24 comment=“allow RA users to RB subnet”
add chain=forward action=accept in-interface=wireguard1 src-address=192.168.100.4/32 dst-address=192.168.88.0/24
