Re: Problem with routing decisions, and multihop

[/dev/rob0 <rob0@gmx.co.uk>]

> On 7/4/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> > On Monday 04 July 2005 10:07, I wrote:
> > > Are multiple "ip route get ip.add.re.ss" commands in sequence
> > > showing routes out the same interface?
> >
> > for X in `seq 10` ; do /sbin/ip route get $X.$X.$X.$X ; done

On Monday 04 July 2005 10:32, Lluis Batle wrote:
> No, everything is right in its output:
> 1.1.1.1 via 192.168.16.2 dev eth1  src 192.168.16.1
>     cache  mtu 1500 advmss 1460 metric10 64
> 2.2.2.2 via 192.168.17.2 dev eth2  src 192.168.17.1
>     cache  mtu 1500 advmss 1460 metric10 64

>>="masquerading.multi-eth" (misnamed: it does no masquerading)

>>NE1=192.168.16.0/28
>>NE2=192.168.17.0/28

Let's see, those are .0-.15 on the last quad.

>>NLOCAL=192.168.0.0/20

And this is 0.0 through 15.255 ... IOW, wrong, excluding both $NE1 and 
$NE2. Try 192.168.16.0/23. It would not hurt for you to brush up on 
TCP/IP and subnetting basics.

>> $IPTABLES -t nat -F PREROUTING
>> $IPTABLES -t nat -F POSTROUTING
>> $IPTABLES -t nat -F OUTPUT
>> $IPTABLES -t filter -F INPUT
>> $IPTABLES -t filter -F FORWARD
>> $IPTABLES -t filter -F OUTPUT
>> $IPTABLES -t filter -F keep_state >&/dev/null
>> $IPTABLES -t filter -X keep_state >&/dev/null
>> $IPTABLES -t nat -F keep_state >&/dev/null
>> $IPTABLES -t nat -X keep_state >&/dev/null

Could be rewritten as:
iptables -F ; iptables -X ; iptables -t nat -F ; iptables -t nat -X

>> $IPTABLES -t filter -N keep_state
>> $IPTABLES -t filter -A keep_state -m state \
>> --state RELATED,ESTABLISHED -j ACCEPT  
>> $IPTABLES -t filter -A keep_state -j RETURN
>> 
>> $IPTABLES -t nat -N keep_state
>> $IPTABLES -t nat -A keep_state -m state \
>> --state RELATED,ESTABLISHED -j ACCEPT 
>> $IPTABLES -t nat -A keep_state -j RETURN

1. IMO it's confusing to give chains the same name in different tables.
2. The RETURN rules are pointless. That's what happens at the end of a 
chain, anyway.
3. --state in -t nat? Is that possible? Does it work? Does it break 
anything?

> About the 16.x and 17.x addresses... yes, there are other routers,
> which make NAT (192.168.16.2 and 192.168.17.2) to internet.

This seems odd to me. I prefer to use external IP directly, for many 
reasons. It also eliminates other potential points of failure.

It's even more odd considering that you're doing DNAT on the already- 
NAT'ed Linux machine. Why not do the DNAT in the external routers? 
Also, those DNAT rules refer to other RFC 1918 netblocks.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header