L2TP/IPTABLES: Routing ETH0 default traffic
Hey y’all,
I have my L2TP Client on my Raspi CM4 setup.
It should function as a VPN Gateway. It connects to my home network and enables clients connected to eth0 to reach devices at home.
In this case, I am using eth2 (my phone via USB tethering) to connect to the internet, to make sure no NAT issues or similar are occuring.
I can traceroute to our FritzBox (Router) which is sitting before the l2tp server (which is running on pfsense), meaning all of my home network is reachable through the tunnel.
<pre style="background-color:#ffffff;">
<span style="color:#323232;">vpngw:~# traceroute 192.168.178.1
</span><span style="color:#323232;">traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
</span><span style="color:#323232;"> 1 192.168.1.251 (192.168.1.251) 46.765 ms 46.553 ms 51.218 ms
</span><span style="color:#323232;"> 2 192.168.178.1 (192.168.178.1) 61.878 ms 61.784 ms 66.704 ms
</span>
There is also no issue to get to pfsense itself (192.168.1.251) (curl/ping).
Current interfaces on vpn gateway:
<pre style="background-color:#ffffff;">
<span style="color:#323232;">vpngw:~# ip addr
</span><span style="color:#323232;">1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
</span><span style="color:#323232;">2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
</span><span style="color:#323232;"> link/ether d8:3a:dd:07:da:4a brd ff:ff:ff:ff:ff:ff
</span><span style="color:#323232;"> inet 10.1.9.1/24 brd 10.1.9.255 scope global eth0
</span><span style="color:#323232;"> valid_lft forever preferred_lft forever
</span><span style="color:#323232;">3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
</span><span style="color:#323232;"> link/ether d6:eb:d2:ac:7a:c0 brd ff:ff:ff:ff:ff:ff
</span><span style="color:#323232;">4: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
</span><span style="color:#323232;"> link/ether d8:3a:dd:07:da:4b brd ff:ff:ff:ff:ff:ff
</span><span style="color:#323232;">5: vpnbridge: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
</span><span style="color:#323232;"> link/ether 52:12:ec:25:25:ee brd ff:ff:ff:ff:ff:ff
</span><span style="color:#323232;">9: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
</span><span style="color:#323232;"> link/ether 72:31:7f:86:2d:7e brd ff:ff:ff:ff:ff:ff
</span><span style="color:#323232;"> inet 172.20.10.2/28 brd 172.20.10.15 scope global dynamic noprefixroute eth2
</span><span style="color:#323232;"> valid_lft 84939sec preferred_lft 74139sec
</span><span style="color:#323232;">11: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1410 qdisc pfifo_fast state UNKNOWN group default qlen 3
</span><span style="color:#323232;"> link/ppp
</span><span style="color:#323232;"> inet 192.168.10.1 peer 192.168.1.251/32 scope global ppp0
</span><span style="color:#323232;"> valid_lft forever preferred_lft forever
</span><span style="color:#323232;">
</span>
The iptables running on the vpn gateway:
<pre style="background-color:#ffffff;">
<span style="color:#323232;">vpngw:~# iptables -L -t nat
</span><span style="color:#323232;">Chain PREROUTING (policy ACCEPT)
</span><span style="color:#323232;">target prot opt source destination
</span><span style="color:#323232;">REDIRECT udp -- anywhere anywhere udp dpt:l2f redir ports 7331
</span><span style="color:#323232;">
</span><span style="color:#323232;">Chain INPUT (policy ACCEPT)
</span><span style="color:#323232;">target prot opt source destination
</span><span style="color:#323232;">
</span><span style="color:#323232;">Chain OUTPUT (policy ACCEPT)
</span><span style="color:#323232;">target prot opt source destination
</span><span style="color:#323232;">
</span><span style="color:#323232;">Chain POSTROUTING (policy ACCEPT)
</span><span style="color:#323232;">target prot opt source destination
</span><span style="color:#323232;">MASQUERADE all -- anywhere anywhere
</span>
And the current routes:
<pre style="background-color:#ffffff;">
<span style="color:#323232;">vpngw:~# ip route
</span><span style="color:#323232;">default via 172.20.10.1 dev eth2 proto dhcp src 172.20.10.2 metric 209
</span><span style="color:#323232;">10.1.9.0/24 dev eth0 proto kernel scope link src 10.1.9.1
</span><span style="color:#323232;">172.20.10.0/28 dev eth2 proto dhcp scope link src 172.20.10.2 metric 209
</span><span style="color:#323232;">192.168.0.0/16 via 192.168.1.251 dev ppp0
</span><span style="color:#323232;">192.168.1.251 dev ppp0 proto kernel scope link src 192.168.10.1
</span>
(These routes may not be correct, as in some were added due to trial and error, and therefore do not have any function)
IPTables has to redirect the 1701 L2TP port due to my routers settings, it just blocks those ports. Therefore I am running everything over Port 7331 and am rewriting this on my pfsense back to 1701. I have added the 3rd Route (192.168.0.0/16 over 192.168.1.251) to make my home devices reachable.
What I want to achieve: Clients connect on eth0 (10.1.9.0/24) can access the firewall and more local devices running at my house. However, they cannot connect to the internet. In my case, this does not need to happen over the L2TP VPN. This is why I left the default ip route on the vpn gateway, hoping all other traffic would just flow over the WAN of the gateway instead of through ppp0.
I currently dont have traceroute on the client (connected on eth0 with ip 10.1.9.10), so I cannot do one there. However, this is one from the vpngw with eth0’s ip as a source address:
<pre style="background-color:#ffffff;">
<span style="color:#323232;">vpngw:~# traceroute -s 10.1.9.1 192.168.178.1
</span><span style="color:#323232;">traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
</span><span style="color:#323232;"> 1 192.168.1.251 (192.168.1.251) 35.315 ms 46.007 ms 45.905 ms
</span><span style="color:#323232;"> 2 192.168.178.1 (192.168.178.1) 55.449 ms 61.238 ms 61.131 ms
</span><span style="color:#323232;">
</span><span style="color:#323232;">vpngw:~# traceroute -s 10.1.9.1 1.1.1.1
</span><span style="color:#323232;">traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
</span><span style="color:#323232;"> 1 172.20.10.1 (172.20.10.1) 0.851 ms 0.707 ms 0.820 ms
</span><span style="color:#323232;"> 2 * * *
</span><span style="color:#323232;"> 3 * * *
</span><span style="color:#323232;"> 4 * * *
</span><span style="color:#323232;"> 5 * * *
</span><span style="color:#323232;"> 6 * * *
</span><span style="color:#323232;"> 7 * * *
</span><span style="color:#323232;"> 8 * * *
</span><span style="color:#323232;"> 9 * * *
</span><span style="color:#323232;">10 * * *
</span><span style="color:#323232;">11 * * *
</span><span style="color:#323232;">12 * *^C
</span>
As you can see, it cannot reach 1.1.1.1. The gw without any source address can reach it:
<pre style="background-color:#ffffff;">
<span style="color:#323232;">vpngw:~# traceroute 1.1.1.1
</span><span style="color:#323232;">traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
</span><span style="color:#323232;"> 1 172.20.10.1 (172.20.10.1) 3.731 ms 3.493 ms 3.334 ms
</span><span style="color:#323232;"> 2 * * *
</span><span style="color:#323232;"> 3 * * *
</span><span style="color:#323232;"> 4 * * *
</span><span style="color:#323232;"> 5 * * *
</span><span style="color:#323232;"> 6 * * *
</span><span style="color:#323232;"> 7 one.one.one.one (1.1.1.1) 31.162 ms 29.583 ms 32.708 ms
</span><span style="color:#323232;"> 8 one.one.one.one (1.1.1.1) 29.658 ms 29.678 ms 29.651 ms
</span><span style="color:#323232;"> 9 one.one.one.one (1.1.1.1) 36.693 ms 35.672 ms 36.714 ms
</span><span style="color:#323232;">10 one.one.one.one (1.1.1.1) 38.520 ms 44.091 ms 37.902 ms
</span><span style="color:#323232;">11 one.one.one.one (1.1.1.1) 62.050 ms 61.541 ms 48.789 ms
</span><span style="color:#323232;">12 one.one.one.one (1.1.1.1) 48.346 ms 60.115 ms 54.037 ms
</span><span style="color:#323232;">13 one.one.one.one (1.1.1.1) 53.662 ms 59.044 ms 58.985 ms
</span>
Whats the solution here? I am sure I missed some information about my routes. I left the default route, shouldn’t the kernel route the incoming traffic to 1.1.1.1 from clients connected to eth0 over this? Do I have to define how to handle returning traffic (e.g. the packets are routed correctly, but the response is not arriving back at the client at eth0)?
Thanks for your help!