I'm currently working on a setup utilizing iptables + iproute2 to force traffic from the localhost to any destination on TCP/80 or TCP/443 out my physical Ethernet NIC while everything else flows out tun0 (with return traffic flowing back through the corresponding interfaces). I do not have split tunneling enabled in OpenVPN so all traffic is routing out tun0 prior to implementing the iptables + iproute2 rules/routes. The host operating system is FC20. Below are my configs: ip route flush cache ip route add default table novpn via 10.0.87.1 ip route add 10.0.87.0/24 dev p4p1 table novpn ip rule add fwmark 1 table novpn ip rule add from 10.0.87.16 table novpn iptables -t mangle -A OUTPUT -p tcp --dport 80 -j MARK --set-mark 1 iptables -t mangle -A OUTPUT -p tcp --dport 443 -j MARK --set-mark 1 iptables -t nat -A POSTROUTING -o p4p1 -j SNAT --to 10.0.87.16 I've got everything allowed outbound from the localhost and have opened up everything inbound while testing to no avail. With iptables logging rules I was able to verify that the outbound packets are being marked properly by iptables. Wireshark shows bidirectional traffic between the proper source and destination, but that's where it begins to get strange... The flow looks something like: <my_ip> SYN TCP/60079 -> <dest_ip> TCP/80 Seq=0 <dest_ip> SYN,ACK TCP/80 -> <my_ip> TCP/60079 Seq=0 <my_ip> SYN TCP/60080 -> <dest_ip> TCP/80 Seq=0 <dest_ip> SYN,ACK TCP/80 -> <my_ip> TCP/60080 Seq=0 It then bounces back and forth with TCP/60079 and TCP/60080 retransmissions for a while (all with a seq of 0) and eventually the far end sends a TCP RST which Wireshark identifies as being due to a packet being sent with a nonzero seq ID without the ACK bit being set. It seems like a TCP state issue, but despite reading everything I could find on the topic this one has me stumped. Hopefully it's something simple that I've missed. Any advice that you could lend would be greatly appreciated. Thanks! --JER -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
