[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Still no success: two router one host



On Thursday 15 January 2004 12:45, Leonardo Boselli wrote:

> I follewed your suggestion but still no success ...
> any attempt to contact from outside g.f.e.246 fails.
> of course if i unconnect also eth0 i cannot access anything, unless i
> set an ad-hoc route on eth1.
> But i need to be accessible on both addresses.

Something is wrong with your routing rules (or perhaps firewall rules?).

> If i try to connect from outside without success i can see that my
> packet arrives but are not answered on either port.

Most obvious reasons why your machine wouldn't respond (that I can think of):

- firewall rules that are blocking them
- lack of a default route (and not necessarily the default route in the main
  routing table)

> I tried also to add the option from adv-iproute howto for load
> balancing, using ip route slist table main is shown correctly , but not
> honoured.

I have not experimented with load balancing but I don't believe that would 
interfere with the routing rules I gave you.

> I begin to fear that the kernel I have (a plain 2.22 from debian) is not
> ok ?

Look at the file how your kernel was compiled, I'm not running any 2.2 based 
kernels anymore and I'm not certain that Debian's 2.2 kernel included 
advanced routing support (though I'd be very surprised if they didn't).  Look 
for kernel options CONFIG_IP_ADVANCED_ROUTER=y and 
CONFIG_IP_MULTIPLE_TABLES=y ... you should be able to see those options in 
the  /boot/config-2.2.X-whatever file included with your kernel.

> Where am i wrong ?

Not sure.  If you post your rules and routes I can probably help you out:

  ip rule list
  ip route list table 5    #  5 just as an example
  ip route list table 10  # 10 just as an example

Here are rules and routes from one such firewall that I manage (names and 
addresses changed to protect the innocent):

    someone@somewhere:~$ ip rule list
    0:      from all lookup local
    100:    from all to 192.168.0.0/24 lookup main
    100:    from all to 192.168.1.0/24 lookup main
    100:    from all to 10.10.10.0/24 lookup main
    100:    from all to 159.99.99.192/27 lookup main
    100:    from all to 216.129.212.0/24 lookup main
    200:    from 192.168.1.11 lookup wiznet
    200:    from 192.168.1.20 lookup wiznet
    200:    from 192.168.1.30 lookup wiznet
    200:    from 192.168.1.194 lookup sprint
    200:    from 192.168.1.197 lookup sprint
    200:    from 192.168.1.199 lookup sprint
    200:    from 10.10.10.165 lookup wiznet
    300:    from 159.99.99.192/27 lookup sprint
    300:    from 216.129.212.0/24 lookup wiznet
    32766:  from all lookup main
    32767:  from all lookup default

    someone@somewhere:~$ ip route list table sprint
    default via 159.99.99.193 dev eth3

    someone@somewhere:~$ ip route list table wiznet
    default via 216.129.212.1 dev eth3

Routing rules are traversed in order, first matching rule results in a routing 
decision and no further rules are consulted.  Here is a description of the 
logic in these rules:

rules 0, 32766 and 32767 are there by default and implement normal routing 
behaviour, I'll skip discussing those.

Rules with priority 100 make sure that all traffic destined for local 
addresses just looks up the main routing table (I like to call main the 
"normal" routing table).

Rules with priority 200 are to make sure that SNATed traffic is sent to the 
correct routing table.  This firewall runs shorewall; shorewall DNATs 
appropriate incoming traffic to various DMZ services, responses from these 
machines must be directed to the correct routing table or it will just exit 
on the default route (since SNAT happens POSTROUTING).  IIRC you're 
installing these rules on a host so rules like this shouldn't be necessary 
for you.

Rules with priority 300 ensure that all outgoing traffic not caught by a 
previous rule is sent to the correct routing table based on it's source 
address.

In this case the routing tables are named sprint and wiznet for convenience 
(those are names of upstream ISPs).  If you wish to name your routing tables 
rather than refer to them by number use /etc/iproute2/rt_tables

-- 
Fraser Campbell <fraser@wehave.net>                 http://www.wehave.net/
Georgetown, Ontario, Canada                         Debian GNU/Linux



Reply to: