Hello again, : > Does server have one or two IP addresses? Best solution? Use two : > IP addresses on server. : : Hmmm, one for ISP1 and one for ISP2? That would be a nice idea to : workaround this problem :-) Only way I have done this myself, although I recall somebody else on LARTC using connmark with nfmark and/or the ROUTE target to solve this problem using only a single IP. Perhaps the archive will help you here.... : > Try changing this (or adding another rule): : > : > ip rule add from 10.0.0.2 lookup table_eth1 : : Nope. I already tried that, but no way. : No. The packets are returned through ISP1. : : > If you would like to handle inbound traffic on both links, then add : > a secondary IP address to your server, and enter another DNAT rule : > which specifies another NAT mapping for the secondary IP. : : That's a very nice idea, but packets keep on entering the wrong : table (default), I think it's a bug somewhere in the kernel. While the kernel certainly has seen bugs before and will see more, I hope you don't mind if I continue to entertain a bit of skepticism on this point. :) : It only works when the ip is direct on the external interface of : the Linuxbox, but as soon as 1 tcp port is translated, the return : packets for that translated port get into the wrong (default) : table. : : Even when using fw marks it doesn't work. I mark all packets coming : from the servers second ip address with '1' and a simple : : ip ru a fwmark 1 table t_eth1 : : should do the job. But no way. Packets keep on getting out : through ISP1 (t_eth0). : : This is the real test: : : 10.0.2.1 is the server, 10.0.2.3 is its second ip. : 10.0.2.1 = external 10.1.3.100 : 10.0.2.3 = external 192.168.201.3 OK, got it! : # ip r s : 192.168.201.3 via 10.0.2.3 dev eth2 : 10.1.3.100 via 10.0.2.1 dev eth2 [ snipped main and ancillary routing tables except for unusual and possibly extraneous routes. ] Routing tables t_eth0 and t_eth1 look fine, although t_eth0 and main should be exactly the same. I believe your two host routes (for 192.168.201.3 and 10.1.3.100) are unnecessary and simply complicate your scenario. I still think your problem is in the RPDB and addressing of the packet at routing time. I do not believe (check the KPTD and its offspring [0] [1]) that the packet's source address has yet been rewritten. Think about this, and look at your RPDB: : # ip ru s : 0: from all lookup local : 32762: from all fwmark 0x1 lookup t_eth1 : 32764: from 192.168.201.2 lookup t_eth1 : 32765: from 10.1.3.101 lookup t_eth0 : 32766: from all lookup main : 32767: from all lookup default The addresses you have entered are the public side addresses. When the server transmits packets, these packets will have the 10.0.2.1 and 10.0.2.3 addresses for source addresses. The RPDB should include references to these private addresses instead of the addresses available on the public side. : btw: iproute2-ss06011, kernel 2.6.16.2, iptables 1.3.5 I hope this helps, and thanks for the detailed listing of your configuration. It's always helpful. Best of luck, -Martin [0] http://www.docum.org/docum.org/kptd/ [1] http://linux-ip.net/nf/nfk-traversal.eps http://linux-ip.net/nf/nfk-traversal.png -- Martin A. Brown --- Wonderfrog Enterprises --- martin@xxxxxxxxxxxxxx _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
