Hi Thomas, We have the same problem. ;) You're right, it doesn't make any sense. Can anyone elaborate?? My setup is virtually identical to what Thomas has. However, I'm using IPMASQ on my outgoing connection, so I am able to see that the problem exists even without using SNAT. Something is borked... > Thomas Themel themel@xxxxxxxxxx > Tue, 28 Oct 2003 01:32:09 +0100 > > Hi, > > I'm currently trying to get a Linux machine to route all traffic coming > from a certain UID over a dedicated PPP interface. After going throught > the available documentation and experimenting a bit, I settled for the > following attempt: > > > # 62.46.87.104 - local PPP address > # 195.4.91.104 - PPP peer > ip route add 195.3.91.104 dev ppp0 src 62.46.87.104 table special > # local for DNS etc > ip route add 192.168.1.0/24 dev eth0 src 192.168.1.1 table special > ip route add default via 195.3.91.104 src 62.46.87.104 table special > ip rule add fwmark 3 lookup special > iptables -t mangle -A OUTPUT -m owner --uid-owner freenet -j MARK > --set-mar= k 3 > ip route flush cache > > This seems to work in a way. It correctly sends the packets generated by > that user out the ppp0 interface, but they don't get the correct source > address: > > | sophokles:~# sh -x description.txt=20 > | + ip route flush table aon> | + ip route add 195.3.91.103 dev ppp0 src 62.46.86.137 table aonc > | + ip route add 192.168.1.0/24 dev eth0 src 192.168.1.1 table aonc > | + ip route add default via 195.3.91.103 src 62.46.86.137 table aonc > | + ip rule add fwmark 3 lookup aonc > | + iptables -t mangle -A OUTPUT -m owner --uid-owner freenet -j MARK > | --set-mark 3 > | + ip route flush cache > | sophokles:~# tcpdump -ni ppp0 port 22 &=20 > | [1] 841 > | sophokles:~# tcpdump: listening on ppp0 > |=20 > | sophokles:~# nc iwoars.net 22 > | SSH-1.99-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 > |=20 > | sophokles:~# su - freenet > | freenet@sophokles:~$ nc iwoars.net 22 > | 01:25:17.044883 192.168.1.1.32848 > 217.160.110.113.22: SWE > | 1344336467:1344336467(0) win 5840 <mss 1460,sackOK,timestamp 2056533 > | 0,nop,wscale 0> (DF) > | 01:25:20.043828 192.168.1.1.32848 > 217.160.110.113.22: SWE > | 1344336467:1344336467(0) win 5840 <mss 1460,sackOK,timestamp 2059533 > | 0,nop,wscale 0> (DF) > | 01:25:26.042584 192.168.1.1.32848 > 217.160.110.113.22: SWE > | 1344336467:1344336467(0) win 5840 <mss 1460,sackOK,timestamp 2065533 > | 0,nop,wscale 0> (DF) > |=20 > | freenet@sophokles:~$=20 > > I've read on this list that owner-based policy routing is impossible > because the routing decision is made before the packet traverses the > OUTPUT chain. However, if this is true, then I don't understand how the > packet can go out via the correct interface unless there are separate > route lookups to determine the source address and outgoing interface. > > Could someone who knows please elaborate? > > I have also tried, unsuccessfully, to just mangle the source address > using an iptables SNAT rule, but even though that produces correct > network traffic, it seems to break something internally that keeps the > TCP handshake from completing: > > | sophokles:~# iptables -t nat -A POSTROUTING -j SNAT -o ppp0 > --to-source| 62.46.86.137 > | sophokles:~# su - freenet > | freenet@sophokles:~$ nc iwoars.net 22 > | 01:30:16.448930 62.46.86.137.32849 > 217.160.110.113.22: SWE > | 1656968486:1656968486(0) win 5840 <mss 1460,sackOK,timestamp 2356000 > | 0,nop,wscale 0> (DF) > | 01:30:16.516732 217.160.110.113.22 > 62.46.86.137.32849: S > | 2293250552:2293250552(0) ack 1656968487 win 32120 <mss > | 1460,sackOK,timestamp 313375234 2356000,nop,wscale 0> (DF) > | 01:30:19.448146 62.46.86.137.32849 > 217.160.110.113.22: SWE > | 1656968486:1656968486(0) win 5840 <mss 1460,sackOK,timestamp 2359000 > | 0,nop,wscale 0> (DF) > | 01:30:19.518099 217.160.110.113.22 > 62.46.86.137.32849: S > | 2293250552:2293250552(0) ack 1656968487 win 32120 <mss > | 1460,sackOK,timestamp 313375535 2356000,nop,wscale 0> (DF) > | 01:30:19.823023 217.160.110.113.22 > 62.46.86.137.32849: S > | 2293250552:2293250552(0) ack 1656968487 win 32120 <mss > | 1460,sackOK,timestamp 313375566 2356000,nop,wscale 0> (DF) > | [...] _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
