Just wanted to say thank you to the members here who have patiently and generously shared their help.
I now have 6 (soon to be 7) locations all connected via VPN.
Among other things, this allows me to view CCTV cameras, and monitor and manage environmental conditions, energy and fuel usage, etc.
I'm sure there are other useful things I can do, but I haven't discovered them yet.
Here are the wireguard peers:
Thank you!
You do not have the required permissions to view the files attached to this post.
Re: Thank you!
I'm sure Anav is the one to be thanked mostly (he seems to become the WG guru around here 
and he was pretty involved in your last threads regarding this topic)
Nevertheless, thank you as well for providing feedback.
All too often people come here with a question, get an answer and never respond back if it worked or not.
and he was pretty involved in your last threads regarding this topic)Nevertheless, thank you as well for providing feedback.
All too often people come here with a question, get an answer and never respond back if it worked or not.
Re: Thank you!
Thanks to you because from the image I think I got mine wrong
You have used only one wireguard interface (212-Wireguard) while I created one for each site, everything works but now I don't know which is the most correct configuration
You have used only one wireguard interface (212-Wireguard) while I created one for each site, everything works but now I don't know which is the most correct configuration
Re: Thank you!
Depends on your use case.
When peers need to communicate with each other, put them on the same interface. Much easier.
I have 3 wg itf.
One private for personal use
One for several devices at work
One for a specific server i daily pull 7gb data from every morning at 5 am (luckily using a backup tool which can work using a schedule )
When peers need to communicate with each other, put them on the same interface. Much easier.
I have 3 wg itf.
One private for personal use
One for several devices at work
One for a specific server i daily pull 7gb data from every morning at 5 am (luckily using a backup tool which can work using a schedule
)Re: Thank you!
Perfect, now I understand ... thanks 
Re: Thank you!
So do I Hoelve is wasteful LOL.
Unless there is overlap between peers, one interface is enough,
I suppose you use bridges for everything and not vlans...............
Same concept one bridge many vlans
One wg interface many peers.
KISS,
Nice to get positive feedback, I may bark a lot but I really want users to feel like they have learned something and it often takes prodding
Unless there is overlap between peers, one interface is enough,
I suppose you use bridges for everything and not vlans...............
Same concept one bridge many vlans
One wg interface many peers.
KISS,
Nice to get positive feedback, I may bark a lot but I really want users to feel like they have learned something and it often takes prodding
Re: Thank you!
So now I've been experimenting with achieving the following:
1) Route all internet traffic out the WG iface (355-WGhEX) so that all non-LAN traffic gets to the internet from a WG peer
2) Route traffic from current location (192.168.0.x) to PEER-2 (e.g., 192.168.1.x) via PEER-1 (192.168.2.x)
The hEX at 192.168.2.2 has the following cross-WG firewall rule:
I've failed at both.
I tried changing the /IP/ROUTE to 192.168.1.0/24 at my current location (hEX 192.168.0.11) from using the WG iface (355-WGhEX) to the IP address of the hEX at PEER-2 (192.168.2.2):
to:
but that didn't work.
I also tried just disabling the route at my location to 192.168.1.x, but that didn't work either.
1) Route all internet traffic out the WG iface (355-WGhEX) so that all non-LAN traffic gets to the internet from a WG peer
2) Route traffic from current location (192.168.0.x) to PEER-2 (e.g., 192.168.1.x) via PEER-1 (192.168.2.x)
The hEX at 192.168.2.2 has the following cross-WG firewall rule:
Code: Select all
add action=accept chain=forward comment="Allows cross peer subnet traffic" in-interface=212-Wireguard out-interface=212-Wireguard
I've failed at both.
I tried changing the /IP/ROUTE to 192.168.1.0/24 at my current location (hEX 192.168.0.11) from using the WG iface (355-WGhEX) to the IP address of the hEX at PEER-2 (192.168.2.2):
Code: Select all
add disabled=no distance=1 dst-address=192.168.1.0/24 gateway=355-WGhEX pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10
to:
Code: Select all
add disabled=no distance=1 dst-address=192.168.1.0/24 gateway=192.168.2.2 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10
but that didn't work.
I also tried just disabling the route at my location to 192.168.1.x, but that didn't work either.
Re: Thank you!
Without a network diagram to show all connected devices, its impossible to assist.
Further its not clear about which devices are involved. It appears there are multiplex hexes for example.
You need to establish, assuming there a single WG server for handshakes, which device this is and then provide the full config for it.
For any device/MT routers that you want traffic to go to or handle from the single Server Router, would need the full config.
For any other device involved in the above traffic flow would need the full config.
The physical relationships between them must be clear,
The use cases of traffic flow must be clear. Its nice you have mentioned new ones, but any change to the config must understand the context of all existing requirements.
Further its not clear about which devices are involved. It appears there are multiplex hexes for example.
You need to establish, assuming there a single WG server for handshakes, which device this is and then provide the full config for it.
For any device/MT routers that you want traffic to go to or handle from the single Server Router, would need the full config.
For any other device involved in the above traffic flow would need the full config.
The physical relationships between them must be clear,
The use cases of traffic flow must be clear. Its nice you have mentioned new ones, but any change to the config must understand the context of all existing requirements.
Re: Thank you!
Simply put, you should know better by now to come with half baked questions. ;-PP
Re: Thank you!
I know, I know.
I wanted to be able to solve it by getting help in a conceptual form this time.
But, I believe I figured it out.
IP/ROUTE for all VPNs uses the WG iface as gateway.
All I had to do is add the private subnet and the VPN addresses to the WG peer.
That is, PEER-A wants to talk to PEER-C without a WG connection between them.
Both PEER-A and PEER-C have a WG tunnel to PEER-B.
By putting PEER-A's private network and the WG IP in the allowed addresses of PEER-C's connection to PEER-B,
and,
putting PEER-C's private network and the WG IP in the allowed addresses of PEER-A's connection to PEER-B,
This allows PEER-B to act as a relay.
Putting this explanation into words in a clear way is indeed not easy.
Here's the relevant code:
PEER-A:
PEER-C:
PEER-B:
I wanted to be able to solve it by getting help in a conceptual form this time.
But, I believe I figured it out.
IP/ROUTE for all VPNs uses the WG iface as gateway.
All I had to do is add the private subnet and the VPN addresses to the WG peer.
That is, PEER-A wants to talk to PEER-C without a WG connection between them.
Both PEER-A and PEER-C have a WG tunnel to PEER-B.
By putting PEER-A's private network and the WG IP in the allowed addresses of PEER-C's connection to PEER-B,
and,
putting PEER-C's private network and the WG IP in the allowed addresses of PEER-A's connection to PEER-B,
This allows PEER-B to act as a relay.
Putting this explanation into words in a clear way is indeed not easy.
Here's the relevant code:
PEER-A:
Code: Select all
/interface wireguard peers
add allowed-address=\
10.10.100.1/32,192.168.2.0/24,192.168.88.0/24,10.10.100.2/32 comment=212 \
endpoint-address=xxxxxxx.dyndns.org endpoint-port=51820 interface=\
wireguard1 persistent-keepalive=40s public-key=\
"xxxxxxxxx"
/ip address
add address=192.168.20.1/24 comment=defconf interface=bridge network=\
192.168.20.0
add address=10.10.100.12/24 interface=wireguard1 network=10.10.100.0
/ip route
add disabled=no distance=1 dst-address=192.168.2.0/24 gateway=wireguard1 \
routing-table=main scope=30 suppress-hw-offload=no target-scope=10
add disabled=no dst-address=192.168.88.0/24 gateway=wireguard1 routing-table=\
main suppress-hw-offload=no
PEER-C:
Code: Select all
/interface wireguard peers
add allowed-address=\
10.10.100.1/32,192.168.2.0/24,192.168.20.0/24,10.10.100.12/32 comment=212 \
endpoint-address=xxxxxxxx.dyndns.org endpoint-port=51820 interface=\
wireguard1 persistent-keepalive=40s public-key=\
"xxxxxxxxxxxx"
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
192.168.88.0
add address=10.10.100.2/24 interface=wireguard1 network=10.10.100.0
/ip route
add disabled=no distance=1 dst-address=192.168.2.0/24 gateway=wireguard1 \
routing-table=main scope=30 suppress-hw-offload=no target-scope=10
add disabled=no dst-address=192.168.20.0/24 gateway=wireguard1 routing-table=\
main suppress-hw-offload=no
PEER-B:
Code: Select all
/interface wireguard peers
add allowed-address=10.10.100.2/32,192.168.88.0/24 comment=371 \
endpoint-address=xxxxxxx.dyndns.org endpoint-port=52820 interface=\
212-Wireguard persistent-keepalive=40s public-key=\
"zoxxxxxxxxx"
add allowed-address=10.10.100.12/32,192.168.20.0/24 comment=629 \
endpoint-address=xxxxxxx.dyndns.org endpoint-port=51821 interface=\
212-Wireguard persistent-keepalive=40s public-key=\
"q2xxxxxxxxx"
/ip address
add address=192.168.2.2/24 comment=defconf interface=bridge network=\
192.168.2.0
add address=10.10.100.1/24 interface=212-Wireguard network=10.10.100.0
/ip route
add comment=371 disabled=no distance=1 dst-address=192.168.88.0/24 gateway=\
212-Wireguard routing-table=main scope=30 suppress-hw-offload=no \
target-scope=10
add comment=629 disabled=no distance=1 dst-address=192.168.20.0/24 gateway=\
212-Wireguard pref-src="" routing-table=main scope=30 \
suppress-hw-offload=no target-scope=10
Re: Thank you!
Awesome, luke skywalker, you can finally use the force!!!
Exactly, thus the beauty of the in/out firewall rule at the wgserver router in the forward chain. All client devices can connect through the main server router to each other without much fuss JUST using their wireguard IP address ( as the rule of thumb is for the peer to the main server router one puts in the SUBNET of the wireguard network ) and all traffic flow is good with crypto routing.
Where it gets tricky is if one or both of those client devices is a router with subnets. Then one has two options...
A. (i) include the lan subnets of the other client you want to reach in the allowed IPs for the peer to main router, or if on the incoming side include the lans subnets coming into your device.
(ii) ensure a route exists for those subnets back into the tunnel
(iii) ensure firewall rules permit the traffic required on the local device.
On the main router, ensure there are IP routes for the above remote lan subnet traffic to direct that traffic into the tunnel. As LAN traffic from one peer exits the tunnel at the main router, it will need to be routed back into the tunnel.
B. There is another option, for the case of routers with LAN subnets.. --> To blow your mind, you could source-nat all the local LAN subnet traffic going into the tunnel at the remote devices and thus (not have to do anything else). Traffic would appear to be coming from the remote devices wireguard IP address and would get autorouted everywhere etc.............
I prefer A. because then one has a better handle at the end devices, who is coming in and who is allowed to go where........
Exactly, thus the beauty of the in/out firewall rule at the wgserver router in the forward chain. All client devices can connect through the main server router to each other without much fuss JUST using their wireguard IP address ( as the rule of thumb is for the peer to the main server router one puts in the SUBNET of the wireguard network ) and all traffic flow is good with crypto routing.
Where it gets tricky is if one or both of those client devices is a router with subnets. Then one has two options...
A. (i) include the lan subnets of the other client you want to reach in the allowed IPs for the peer to main router, or if on the incoming side include the lans subnets coming into your device.
(ii) ensure a route exists for those subnets back into the tunnel
(iii) ensure firewall rules permit the traffic required on the local device.
On the main router, ensure there are IP routes for the above remote lan subnet traffic to direct that traffic into the tunnel. As LAN traffic from one peer exits the tunnel at the main router, it will need to be routed back into the tunnel.
B. There is another option, for the case of routers with LAN subnets.. --> To blow your mind, you could source-nat all the local LAN subnet traffic going into the tunnel at the remote devices and thus (not have to do anything else). Traffic would appear to be coming from the remote devices wireguard IP address and would get autorouted everywhere etc.............
I prefer A. because then one has a better handle at the end devices, who is coming in and who is allowed to go where........