0

Firstly: I know could do this the easy way with SSH but I want to learn how to route.

I want to route packets back through the same tun0 interface from which they came into my system.

I can do it for single routes.

This works:

sudo ip route add 74.52.23.120 metric 2 via 10.8.0.1

But i'd have to add them manually for each request that came down the pipe

I've taken the blue pill and followed the http://lartc.org/howto/lartc.netfilter.html:

Netfilter & iproute - marking packets tutorial

But it's oriented towards redirecting OUTGOING packets based upon markers

What I want is for a packet that comes in via tun0 not to be dropped which is what's happening right now, running scappy or suchlike to receive packets it doesn't seem to be receiving anything.

Watching in wireshark I see the initial SYN packets coming in on the tun0 interface but that's as far as it gets without a static route as shown above.

Am I nuts?

Bryan Hunt
  • 321
  • 4
  • 14
  • Could you please specify what you mean with "route packets back through the same tun0 interface from which they came?" What do you want to do? why do you want to route this back? This is a public ip, what have it to do with your vpn? – Thomas Berger Jun 30 '11 at 18:22

1 Answers1

1

Apparently, you have some kind of forwarding configuration through your VPN and want to prevent split routing paths for traffic reaching your host through the VPN. In this case, your request packet is probably not dropped (at least not by your host), the reply is simply routed out through another interface (presumably the one your default route points to).

What you certainly do not need in this scenario is dynamic creation / teardown of routes. You have taken the right track by using netfilter for marking packets. The main difference to the examples given in the LARTC guide would be that you would need to use the CONNMARK instead of the MARK target - it would mark incoming and outgoing packets belonging to a connection with the defined mark. Something like iptables -t mangle -A INPUT -i tun0 -j CONNMARK --set-mark 555 With that done, you could use ip rule add fwmark 555 lookup <your_secondary_routing_table> to get the replies routed the same way the original requests came in. Your setup is slightly similar to routing setups for more than one ISP, so reading some configuration examples should put you on the right track, if you are not there already.

BTW: you could achieve a similar effect much more easily if you would let your remote VPN endpoint at 10.8.0.1 simply masquerade the TCP/UDP connection requests to its own IP address (iptables -t nat -A POSTROUTING -o tun0 -d <your_servers_address> -j MASQUERADE). This way, you would only ever need one static route - the one to the remote VPN endpoint which you will have set up automatically with OpenVPN.

the-wabbit
  • 40,737
  • 13
  • 111
  • 174
  • Hi, I'm going to post the full solution. One other thing that you need to do is with sysctl: sysctl -e -w net.ipv4.conf.tun0.rp_filter=0 – Bryan Hunt Jul 01 '11 at 16:52
  • Oh yeah, also I didn't know about CONNMARK, I'm going to have to try that out. – Bryan Hunt Jul 01 '11 at 16:53
  • Masquerading, although simpler is not ideal as it would hide the real IP addresses of incoming connections from my application. That's why I went down this much more convoluted approach. – Bryan Hunt Jul 04 '11 at 11:01
  • This is right - if you need logging of client IP addresses which is a common feature request with SMTP or HTTP servers or are fingerprinting connections using [p0f](http://en.wikipedia.org/wiki/P0f), masquerading will not help you much. We need to solve similar problems to forward SMTP connections to a main MX. To reduce rule complexity, we decided against CONNMARK and use the `ip rule from table ` syntax instead - works just as well, but may be unsuitable where you forward to the public address instead of the VPN interface address. – the-wabbit Jul 04 '11 at 16:54