Hello, On Sat, 1 Mar 2003, Tomasz Wrona wrote: > Rules related for this interfaces and traffic: This looks a bit strange, it is not needed: > # To be sure that traffic goes to proper gateway > 22: from 1.1.1.30 lookup 1 > 22: from 2.2.2.66 lookup 2 You already have link routes to these IPs in table main > ... > # This rules are unnecessary I think but used for diagnostics gateways > #by me. Yes, you don't need them: > 30: from all to 1.1.1.29 lookup 1 > 30: from all to 2.2.2.65 lookup 2 > > #Balance tables distributes traffic from LAN. Don't expect from Netfilter to use correctly the routing, you have to avoid using "iif" when playing with Netfilter. Just use "from XXX". > 70: from all iif eth1 lookup balance > > > # ip r l ta 1 > default via 1.1.1.29 dev eth2 > # ip r l ta 2 > default via 2.2.2.65 dev eth4 > # ip r l ta balance > default > nexthop via 1.1.1.29 dev eth2 weight 2 > nexthop via 2.2.2.65 dev eth4 weight 3 > > So. Everything works but I have observed some behaviour what > I can't understand.. I don't know what works but in theory it should not work, you don't have routes that restrict each ISP traffic through its gateway. May be in your case each of the ISPs allow spoofing. > What I expected was that trafic nated to 1.1.1.30 goes throught eth2 > and traffic nated to 2.2.2.66 goes throught eth4. Then specify it to be so: ip rule add prio 20 from 1.1.1.30/30 table 1 ip rule add prio 20 from 2.2.2.66/27 table 2 but you will need rules "from all to all" for proper default route selelection and source IP autoselection for the masquerading. The normal kernel can not give you this, you need other solutions, eg: http://www.ssi.bg/~ja/#routes dgd-usage.txt contains example for rules and routes you can use. > Unfortunatelly when become listening on eth4 with following command: > tcpdump -n -i eth4 src 1.1.1.30 > I can see trafiic which I am not expecting on this interface: > 1.1.1.30.3145 > 217.98.144.187.20: P 1608:2144(536) ack 1 win 16616 (DF) > 1.1.1.30.4282 > 212.77.100.17.5555: . ack 1889 win 17520 (DF) > > The simmilar is on eth2: > tcpdump -n -i eth2 src 2.2.2.66 > 2.2.2.66.6114 > 217.17.41.85.8074: P 58257:58281(24) ack 530714947 win 7506 (DF) > > Of course more packets have correct sources [1.1.1.30 for eth2 and > 2.2.2.66 on eth4] but I cant see the reason there are some missed > packets... > I did experiment and attached iptables DROP rule on POSTROUTING on > eth2 and eth4 interfaces to catch bad sourced packets but they didnt > catch anything what says for me this "bad" traffic didnt really go > through incorrect interfaces. May be it is the POST_ROUTING who is guilty for selecting wrong nexthop and you can not notice it, this mistake is visible on device output. > So that I am confused on this packet traversing.. Could someone explain > this behaviour ? Is it OK or I have missed something ? You can read about such issues, use the above URL > Regards, > tw > -- > > ----------- > ck.eter.tym.pl Regards -- Julian Anastasov <ja@xxxxxx>
