[LARTC] Re: source routing does not work with extra ip addresses

[LARTC] Re: source routing does not work with extra ip addresses

[richard lucassen]

On Sat, 8 Apr 2006 15:31:24 -0500
"Martin A. Brown" <martin-lartc@wonderfrog.net> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc