You are not logged in.

#1 2020-04-04 21:23:24

cryzed
Member
Registered: 2010-05-11
Posts: 14

Route traffic past a VPN

I am trying to create a setup where I can use a VPN (which does not allow forwarding ports through it) and still serve content on port 80 "past" the VPN, through the normal gateway. To elaborate a bit:

[user@host ~]$ ip route
0.0.0.0/1 via 10.15.255.34 dev tun0 
default via 192.168.178.1 dev eth0 proto dhcp src 192.168.178.30 metric 1024 
10.0.0.0/12 via 10.15.255.34 dev tun0 metric 1 
10.15.255.34 dev tun0 proto kernel scope link src 10.15.255.33 
128.0.0.0/1 via 10.15.255.34 dev tun0 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.19.0.0/16 dev br-90ed1fd8f366 proto kernel scope link src 172.19.0.1 
172.22.0.0/16 dev br-06d26011cac1 proto kernel scope link src 172.22.0.1 
185.253.97.6 via 192.168.178.1 dev eth0 
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.30 
192.168.178.1 dev eth0 proto dhcp scope link src 192.168.178.30 metric 1024 

The 2 routes 0.0.0.0/1 and 128.0.0.0/1 come from OpenVPN and cover the whole IPv4 address space with a higher specificity than the default route and cause all outgoing traffic (assume IPv6 is disabled) to be redirected through `tun0`, the VPN interface. I opened and forwarded port 80 in my router for this device. I then start nginx "# systemctl start nginx" in the default configuration. I can reach this server through LAN (192.168.178.30 in this case) obviously, and I can even reach this server through WAN now -- but only as long as I'm connected to the same VPN endpoint that the server is connected to. As soon as I don't go through the same VPN endpoint and try to connect to the server, I can see that the traffic arrives through eth0 (forwarded from the router) from the correct IP, but outgoing packets don't leave through eth0 back to the source IP, instead they go through tun0. So what's happening to my understanding:

A (client) contacts B (server) through the router gateway. B answers A through the VPN gateway. I assume that these packages with a completely different source address are just discarded by the client -- at least that's what it looks like here. I can connect/send packages to the server but I never get a response -- or rather the response comes from the wrong IP so the browser loads the page forever.

So I've been looking at various answers on Stack Overflow/Serverfault that had a similar problem, for example this one: https://serverfault.com/questions/34511 … -interface. There they recommend marking outgoing packets from tun0 with destination port 80 with an identifier and then rerouting all such marked packets over a different routing table, with only a single default route in it (that goes through eth0, the interface I want this packet to actually be sent from). I've followed all the steps outlined and this and similar guides, but I keep checking with `tcpdump 'tcp port 80' -i tun0/eth0 -n` and can clearly see that when there's ingress traffic on eth0 it still attempts to send the reply over tun0. So obviously my routing is off/or there's something off with the prioritization for the routing.

Has someone tried something like this before and can possibly give me some advice on this? To summarize: I want to receive incoming traffic on some ports and send traffic back over these ports, bypassing the VPN routing.

Offline

#2 2020-04-04 23:47:02

cryzed
Member
Registered: 2010-05-11
Posts: 14

Re: Route traffic past a VPN

I solved the problem, it was an oversight of me: in all of the threads dealing with this topic, people usually want to route traffic based on the destination port: i.e. "I want all outgoing traffic to port 80 to be routed via interface X". What I wanted was slightly different, I actually wanted to do the routing based on my source port (i.e. 80), not the client's destination port. So this worked for me:

# ip route add default via 192.168.178.1 table 1
# ip rule add fwmark 1 table 1
# iptables -t mangle -A OUTPUT -p tcp --sport 80 -j MARK --set-mark 1

Offline

Board footer

Powered by FluxBB