On Wed, Oct 2, 2013 at 7:25 PM, James Harper <james.harper@bendigoit.com.au> wrote:
Are you using tcpdump to determine that the packets are going out over the wrong interface?
For the last test I only checked with lsof and conntrack:
# lsof -i -n | grep openvpn openvpn 21972 nobody 4u IPv4 129321 0t0 TCP 115.146.92.84:51520->172.26.10.100:openvpn (ESTABLISHED)
# conntrack -d 172.26.8.100 -L tcp 6 431995 ESTABLISHED src=115.146.92.84 dst=172.26.10.100 sport=51520 dport=1194 src=172.26.8.100 dst=115.146.92.84 sport=1194 dport=51520 [ASSURED] mark=0 use=2 conntrack v1.0.0 (conntrack-tools): 1 flow entries have been shown.
But now using tcpdump, I see that packets ARE leaving via eth1. But there is only outgoing packets, no incoming packets at all. Whereas on the default gateway device, packets are only incoming, no outgoing packets. The openvpn tunnel seems fine with that. So I need to change the source address of the packets for it to come back on the correct interface?
Yes that's exactly what you need to do, or the other end will just reply with the original (wrong) destination address.
Something like:
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
you can use -j SNAT if you want to explicitly specify the source address (eg because you have several), but MASQUERADE should suffice.
Just got to test this today and it didn't seem to work. From the openvpn logs, I was getting the following: Wed Oct 9 13:49:06 2013 us=596232 TCP: connect to [AF_INET]172.26.8.100:1194 failed, will try again in 5 seconds: Connection timed out Although tcpdump showed the packets were now only using the non-default interface as they should. To get it working I also needed to do the following to disable reverse packet filtering, or to enable "loose" mode: echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter or echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter echo 2 > /proc/sys/net/ipv4/conf/eth1/rp_filter And it seems "all" doesn't enable it for all interfaces, as I thought it would. You need both the above lines to get this working. Regards, Marcus. -- Marcus Furlong