On Wed, Oct 2, 2013 at 6:12 PM, James Harper <james.harper@bendigoit.com.au> wrote:
Did you actually try putting it in the OUTPUT chain? I have rules for that on my router and it is definitely working (just checked with tcpdump).
I just tried this now.
Chain OUTPUT (policy ACCEPT 4504 packets, 857K bytes) pkts bytes target prot opt in out source destination 170 27734 MARK tcp -- any any anywhere anywhere tcp dpt:openvpn MARK set 0x4aa
So this time the packets are actually getting marked, but they still go out over the wrong interface. It looks like because the routing decision has already been made, it doesn't bother to look up the routing tables.
What kernel? It is definitely working for me.
# uname -r 3.2.0-53-generic
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? -- Marcus Furlong