The RB has a public IP, there is no need for BTH. Or another router!
Am I missing something the OP said??
Quote:" Home A :
Router : RB4011iGS+
firmware : v6.49.10
Internet : Dynamic public IP - but stays same for months unless I turn off modem for 3 - 4 days. “unquote”
Setup the RB as a proper server for handshake wireguard router Then any client device an connect to it be it:
a. iphone
b. windows pc
c. Hex router at another location.
RB setup
wireguard IP: add address=192.168.68.1/24 interface=wireguardRB network=192.168.68.0
listening port 15445
name=wireguardRB
private key=xxxx who cares.
public key= ( this is what you use on the peer settings on all clients, on their peer setting line for the RB (aka hex and remote devices) )
Peer Setup
allowed ips= 192.168.68.2/32 interface=wireguardRB public-key=(public key issued from remote device A)
allowed ips= 192.168.68.3/32 interface=wireguardRB public-key=(public key issued from remote device B)
allowed ips= 192.168.68.3/32,HexSubnet1,HexSubnet2 etc. interface=wireguardRB public-key=(public key issued from remote HEX)
Note where a router is a client, we should add the subnets from the hex if they are involved in any traffic
a. users/admin on RB need to reach hex subnets
OR
b. users/admin on HEX needs to reach RB subnets.
TO match the hex subnet traffic the RB needs routes if applicable, as the subnets are NOT local to the RB. This allow Hex subnet users return traffic back into the tunnel.
This allows local RB users, originating traffic, a path into the tunnel to reach Hex subnets.
This allows remote users coming into the RB and needing to reach the hex subnets.
/ip route
add dst-address=HEXsubnet1 gateway=wireguardRB routing-table=main
add dst-address=HEXsubnet2 gateway=wireguardRB routing-table=main
etc.
Firewall rules.
input chain
add chain=input action=accept dst-port=15445 protocol=udp comment=“wireguard handshake”
add chain=input action=accept in-interface=wireguardRB src-address-list=Authorized.
where Authorized is a list of a IPs that are allowed to access the RB for config purposes.
- think admin on iphone, or PC while away (remote devices connected via wireguard)
- think admin while at the hex router physically and using an admin local IP address ( statically set from dhcp leases ).
Forward chain
add chain=forward action=accept in-interface=wireguardRB ( place valid destinations and limitations here)
add chain=forward action=accept in-interface=wireguardRB ( place valid destinations and limitations here)
etc…
You might simply have out-interface-list=LAN and thus anyone coming in wireguard can access all RB subnets.
THen you have to consider allowing traffic into the tunnel for local users who may want to reach the HEX
add chain=forward action=accept (place valid local users here) out-interface=wireguardRB
Finally, here is the neat rule, the RELAY rule. so that any remote user (iphone, laptop etc… ) can access the hex through the RB
Remember WG is peer to peer, so any user connects to the RB, exits the tunnel and is sitting parallel to the LAN level.
That traffic then needs to reenter the tunnel heading towards the Hex…
add chain=forward action=accept in-interface=wireguardRB out-interface-wireguardRB
Interface list… Common is to add wireguard to interface-list=LAN.
This allows us to make use of existing rules, allow LAN to DNS services in input chain to resolve internet requests. (PLUS).
This allows us to make use of existing LAN to WAN firewall rules, permission to use local WAN…
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
THe HEX>…
wireguard IP: add address=192.168.68**.3**/24 interface=wireguardHEX network=192.168.68.0
listening port 13231 (doesnt matter what this is default is fine )
name=wireguardRB
private key=xxxx who cares.
public key: (This is what you use on on the RB device, when configuring the peer line for the hex )
Peer Setup
_allowed ips= 192.168.68**.0/24**,RBsubnet1,RBsubnet2 interface=wireguardHex
endpoint-address=mynetnameIPcloud(RBRouter): endpointport:15445 public-key=(public key issued from RB)
persistent-keep-alive=35s
Note where a router is a client connecting to a router server for handshake, we should add the subnets from the RB if they are involved in any traffic
a. if any RB subnet users are coming to the HEX or
b. if any RB subnets need to reached by local Hex Users…
Note: Any remote devices, iphones, laptops etc, can reach the hex due:
a. the relay rule on the RB
b. the IP routes for the hex subnets
c. they have a WIREGUARD ADDRESS 192.168.68.X which if you look at the peer setup, are already included and thus filtered and accepted by the HEX.
As per the other router, need to establish IP routes for any subnets identified in allowed Ips.
Traffic coming from or Traffic headed to those subnets.
/ip route
add dst-address=RBsubnet1 gateway=wireguardHEX routing-table=main
add dst-address=RBsubnet2 gateway=wireguardHEXrouting-table=main
etc.
Firewall rules.
input chain
add chain=input action=accept in-interface=wireguardHEX src-address-list=Authorized.
where Authorized is a list of a IPs that are allowed to access the HEX for config purposes.
- think admin on iphone, or PC while away (remote devices connected via wireguard)
- think admin while at the RB router physically and using an admin local IP address ( statically set from dhcp leases ).
Forward chain
add chain=forward action=accept in-interface=wireguardHEX ( place valid destinations and limitations here)
add chain=forward action=accept in-interface=wireguardHEX ( place valid destinations and limitations here)
etc…
You might simply have out-interface-list=LAN and thus anyone coming in wireguard can access all HEX subnets.
Finally you have to consider allowing traffic into the tunnel for local users who may want to reach the RB
add chain=forward action=accept (place valid local users here) out-interface=wireguardHEX_