There are two problems with this setup:
- The hosts on LAN1 know nothing about the LAN2 segment. When you ping a host on LAN1 (let's call it host1) from SRV-02, the packet will be routed through SRV-01 and will reach host1. However, host1 will send the reply to it's default gateway (ISP router) as it doesn't have a specific route to LAN2. (The ISP router will either a) also send it to it's default gateway as it also doesn't know about LAN2, or b) drop the packet as it comes from an unknown source not it's local LAN.)
- When trying to reach WAN from LAN2, the packets will be routed through SRV-02 to ISP router where two situations are possible:
- The router will not NAT translate the packet as the source of the packet (LAN2) is not it's local LAN (this is the more probable situation), or
- The router will NAT translate the packet and send it to the Internet. However, when the reply comes and the destination is translated back to the LAN2 address, the packet will not be delivered as the ISP router doesn't have a route for that network. The packet will be sent incorrectly to the default gateway (ISP).
These issues could be fixed by adding a static route to LAN2 to ISP router and adding a source NAT configuration for LAN2 on SRV-01. However, that is not possible due to no admin access to the ISP router.
There are two solutions that get around it:
A. Make SRV-01 a full router for LAN1 and LAN2 hosts
- Add another network adapter to SRV-01 (making it 3 in total)
- Change the topology as follows:
.
WAN -> ISP router -> LAN1 -> SRV-01 +-> LAN3 (for hosts originally in LAN1)
+-> LAN2 -> SRV-02
Basically, we're making SRV-01 a router for both LAN segments.
- This will require moving hosts originally in LAN1 to a new subnet LAN3 - let's say we use
10.0.1.0/24
- The network configuration of SRV-01 will need to be changed as follows:
/etc/network/interfaces:
# LAN1 - to ISP router
auto eth0
iface eth0 inet dhcp
# we can even use dhcp as the IP address is not really important
# - there are no more hosts on LAN1 apart from ISP router and SRV-01
# LAN3 - for hosts originally in LAN1
iface eth1
address 10.0.1.1
netmask 255.255.255.0
# LAN2
iface eth2
address 10.0.2.1
netmask 255.255.255.0
iptables rules to make WAN access work:
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.1.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.2.0/24 -j MASQUERADE
Alternatively, if you choose to keep the static IP address on SRV-01 on eth0 the rules could be changed (although MASQUERADE
would still work):
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.1.0/24 -j SNAT --to-source 192.168.5.8
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.2.0/24 -j SNAT --to-source 192.168.5.8
- DHCP will need to be configured on SRV-01 on eth1 (LAN3, for hosts originally on LAN1), and possibly on eth2 (LAN2) as well if required. (In both cases the gateway will be the local address of eth1 or eth2 respectively, but that goes without saying :)
This will make communication possible between LAN3 and LAN2 (via SRV-01 which is the default gateway for both). WAN access will also work from both LAN3 and LAN2 thanks to the double source NAT.
B. Make SRV-01 a DHCP server for LAN1
This approach is not as clean as above but is slightly simpler. It assumes you are able to disable DHCP on ISP router
- Disable DHCP on ISP router
- Set up DHCP for LAN1 on SRV-01 and make SRV-01 (192.168.5.8) the default gateway for LAN1
- Set up source NAT translation for LAN2 on SRV-01 so that the WAN access works from LAN2:
.
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.2.0/24 -d 192.168.5.4 -j SNAT --to-source 192.168.5.8
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.2.0/24 ! -d 192.168.5.0/24 -j SNAT --to-source 192.168.5.8
The first line enables SNAT so that LAN2 hosts can access the ISP router itself and the second line disables SNAT for LAN2-LAN1 access.
Again, this approach is not as clean as the one above as there are two routers in the same subnet (SRV-01, ISP router). When I used this approach myself I noticed my second router (SRV-01 in this scenario) would send ICMP redirects to the ISP router as it would see that the client (host on LAN1) and the upstream router (ISP router) are on the same LAN. This might not be desired as network policies implemented on SRV-01 could be circumvented.
Hope that helps.
MASQUERADE
/POSTROUTING
rules do not change where certain traffics go. Routes do. The problem is that you have a default route (or what's equivalent) that leads traffics into the pia
tunnel.
You will need to make use of policy routing for the replying traffics from the wireguard server:
# ip r add 192.168.1.1 dev eth0 table 123
# ip r add default via 192.168.1.1 table 123
# ip rule add iif lo ipproto udp sport 51820 lookup 123
The first command could be optional. Make sure you replace 192.168.1.1
and eth0
with the LAN IP of your router and the interface name of your Ethernet NIC correspondingly. (You can copy them from the output of ip r
, i.e. routes in the main table.) The number 123
is arbitrary. iif lo
limits the rule to UDP traffics with source port of 51820
from the host itself (but not such traffics from another host).
Best Answer
You should probably start with using
Table=off
in the wg-quick conf on both S and P. The value ofAllowedIPs=
will not cause changes to the routes / policy routing rules on them then.EDIT: Actually it should be fine to leave
Table=
untouched on P unless you needAllowedIPs=
of S on it to be0.0.0.0/0
instead of192.168.60.0/24
for some reasons, e.g. need traffics originates from itself to be routed S. You don't need to mess with the routes and routing rules on P yourself since even the prefix inAddress=192.168.60.2/24
should get the necessary route configured. The next paragraph probably does not apply to what you need -- although it might gives you some extra insights on how things work.I don't suppose you want to route traffics that originates from S itself to P, so you probably want the following ip rule instead:
If you really need want to route e.g. traffics other than the ssh and wireguard server replies to P, you can additionally have:
Note: you can't just match with
from 192.168.60.1
added in the first rule and omit the other two, because for non-replying traffics, the source address is often (if not always) chosen based on the decided route -- it's not set yet at this point.Note that the order of the command normally determines the priority, so make sure you add the "superset" rule before the "subset" rules, otherwise the latter will be overridden by the former.
Also it's best to keep
table 200
empty until all the desire rules are in position, otherwise remote access of the host could be cut off.Finally nexthop makes no sense in route to an L3 tunnel:
P.S. Make sure you didn't just allow IP forwarding in the firewall but also enable it with sysctl.