On Sat, 8 Apr 2006 15:31:24 -0500 "Martin A. Brown" <martin-lartc@xxxxxxxxxxxxxx> wrote: > 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.... Ok. I have a working workaround now using fwmarks and a second ip on the server. That was a very good idea. Thnx! Bu so far so good. Now I'd like to get it working with 1 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. :) Ok, it's not a bug in the kernel, it's a bug in the docs :) [..] > 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. Hmm. You're right. I just need 1 extra table, not two. I just followed the docs in the lartc-howto, I'll have a closer look at their example there. I think that 1 extra table does the same job in that example http://www.lartc.org/lartc.html#LARTC.RPDB.MULTIPLE-LINKS > 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. Once again you're right. I accidently commented out the necessary "ip r f c" (flush cache) in the script, that's why it didn't work (immediately). But finally I resolved the problem using the CONNMARK. This is the setup I'm talking about: http://www.lucassen.org/divers/ar-test.pdf I don't know if this is the right way to do this, but it seems to work well. I mark all packets coming in to 192.168.201.3 through eth1 with mark 1: iptables -t mangle -A PREROUTING -i eth1 -d 192.168.201.3 \ -j CONNMARK --set-mark 1 I mark the return packets with the same mark: iptables -t mangle -A PREROUTING -i eth2 -s 10.0.2.1 \ -j CONNMARK --restore-mark A simple ip rule add fwmark 1 table t_eth1 ip r f c does the rest. I have now 1 ip address on the server and two routes to the internet. And 1 extra table instead of two ;-) Thnx for your help, R. -- ___________________________________________________________________ It is better to remain silent and be thought a fool, than to speak aloud and remove all doubt. +------------------------------------------------------------------+ | Richard Lucassen, Utrecht | | Public key and email address: | | http://www.lucassen.org/mail-pubkey.html | +------------------------------------------------------------------+ _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
