Score:0

Wireguard Site2Site with mobile office

us flag
TRW

I've to networks connected with Wireguard.

Lan1:
  10.240.0.0/24
  via 10.100.1.1/32 on public static ip A.B.C.D/32

Lan2:
  192.168.0.0/24
  via 10.100.1.6/32 on dynamic ip from provider

The 10.240.0.0 net is a wireguard net (wg0) over multiple public servers and one server is a "gateway" with a special wg1 interface with 10.100.1.1. So I can reach from the gateway all nodes in the 192.168.0.0 network. On Lan2 it is a classic local network with some servers. Also on that peer I can reach all nodes behind Lan1.

Now I want to add a new peer somewhere in the "wild" - a mobile offce. The user should have access to Lan1 and Lan2 at the same time e.g. reach 10.240.0.0/24 and 192.168.0.0/24. The peer itself is a cell phone with Wireguard client as an example.

Lan1 gateway wg1.conf

[Interface]
Address = 10.100.1.1/32
...

PostUp   = iptables  -A FORWARD -i %i -j ACCEPT; iptables  -A FORWARD -o %i -j ACCEPT; iptables  -t nat -A POSTROUTING -o eth0 -j MASQUERADE;
PostDown = iptables  -D FORWARD -i %i -j ACCEPT; iptables  -D FORWARD -o %i -j ACCEPT; iptables  -t nat -D POSTROUTING -o eth0 -j MASQUERADE;

# road-warrior
[Peer]
PublicKey = ...
AllowedIps = 10.100.1.2/32

# Lan2 gateway
[Peer]
PublicKey = ...
AllowedIps = 10.100.1.6/32, 192.168.0.0/24

And the Lan2 host

[Interface]
Address = 10.100.1.6/32
...

PostUp   = iptables  -A FORWARD -i %i -j ACCEPT; iptables  -A FORWARD -o %i -j ACCEPT; iptables  -t nat -A POSTROUTING -o ens18 -j MASQUERADE
PostDown = iptables  -D FORWARD -i %i -j ACCEPT; iptables  -D FORWARD -o %i -j ACCEPT; iptables  -t nat -D POSTROUTING -o ens18 -j MASQUERADE

# lan1_gate
[Peer]
PublicKey = ...
EndPoint = fqdn:port
AllowedIPs = 10.100.1.1/32, 10.240.0.0/24

I can only define (in my understanding) on that cell phone the peer of the lan1 gateway, because I don't have access to lan2_gateway but I want to route all traffic von 192.168.0.0 over lan1_gateway to lan2_gateway

[Interface]
Address = 10.100.1.2/32
...

[Peer]
PublicKey = ...
EndPoint = fqdn:port
AllowedIPs = 10.100.1.1/32, 192.168.0.0/24, 10.240.0.0/24

When I connect the road warrior with lan1, I can reach 10.240.0.0/24 but not 192.168.0.0. What is wrong? Do I need another forward rule on lan1_gate to forward traffic for 192.168.0.0 to 10.100.1.6? That should be already done.

#> ip r s
default via 172.31.1.1 dev eth0 onlink
...
10.100.1.2 dev wg1 scope link 
10.100.1.6 dev wg1 scope link 
...
10.240.0.4 dev wg0 scope link 
10.240.0.5 dev wg0 scope link 
...
172.31.1.1 dev eth0 proto kernel scope link src A.B.C.D 
192.168.10.0/24 dev wg1 scope link 

Any ideas?

ph flag
I wrote a script for the scenario of connecting a mobile phone to a Wireguard VLAN [`wireguard-client-to-site.sh`](https://gist.github.com/jtmoon79/217e55272c55631ba6025c9f890b3dde). It will generate configuration files needed. You could compare your work to it's output, maybe it will give you some ideas.
ph flag
Your example shows a typo. Configuration `Lan2: 192.168.0.0/24` but `ip route` output shows `192.168.10.0/24`.
us flag
TRW
Thanks - I fixed it
Score:1
cn flag

Unless you have some additional firewall rules set up on the Lan1 gateway host, traffic from your "road warrior" cell phone will be forwarded from your Lan1 gateway to your Lan2 gateway using the phone's original WireGuard source address of 10.100.1.2. So you need to add the phone's address to the AllowedIPs setting in the WireGuard configuration for the Lan2 gateway host:

AllowedIPs = 10.100.1.1/32, 10.100.1.2/32, 10.240.0.0/24

The Lan2 gateway will drop any packets it receives from its WireGuard connection with the Lan1 gateway when the packet's source address is not included in this AllowedIPs setting.

us flag
TRW
You're right in two points. The gateway had additional Firewall-Rules to disallow traffic from peer X to peer Y (which I created after this question, the original settings would work) and LAN2 needs to know which IP is coming in. I always thought, that this is the route for outgoing traffic, but it seems to be also relevant for incoming traffic. Thanks a lot. Works.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.