RE: [LARTC] ipchains iproute2 and port based routing

["Marco Balle" <mb@monster-server.de>]

Hi Martin!

Thanks for your feedback.

Okay, i will try to go step by step.


> : ipchains -A input -p icmp -s 192.168.0.0/24 -m 2
> : ip ru add fwmark 2 table 10
> : ip route add default via x.x.x.x dev eth2 table 10
> : ipchains -A forward -s 192.168.0.0/24 -j MASQ
>
>You don't write a rule to allow explicitly for the returning echo-reply
>packets.  If you have a default policy of DENY on your input chain,
then
>the packet can appear on eth2 (see your tcpdump below) but still be
>denied.

I made every new try a ipchains -F  -  there was no other chain(s).


>If you want to make sure that the policy never gets called (easier to
see
>if packets are hitting the last rule than if they are hitting the chain
>policy):
>
>  ipchains -A input -i eth2 -j DENY -l
>
>Now you'll have a chain that logs the packets and has a counter--this
will
>make it easier to see if ipchains is part of the problem.

Okay, it seems there is a problem. In this DENY chain I get after every
ping 4 more packets (one ping - 4 tries).
It seems ipchains deny the incoming icmp packets on eth2. But why?
I tried also to specify the source ip with some other chains, and it is
the packet, that comes from the host 62.154.89.102 - exactly the packet
I am waiting for.

A ipchains -nML shows a open masq connection to the host, I ping'd:

IP masquerading entries
prot expire   source               destination          ports
ICMP 00:57.85 192.168.0.31         62.154.89.102        512 (61009) -> 8


>Now that strikes me as very odd.  I don't have an easy answer for this
>one...unless you started the ping like this:
>
>  ping -i 5 L-EB1.L.DE.net.dtag.de

I used the ip address.


> : And anything else: if I delete the rule fwmark 2 table 10, the
client
> : (192.168.0.31) shows during a ping to outside:
> : 192.168.0.1 (ip of eth0): no route to host
>
>What does "ip rule show" tell you after you have removed the above
rule?

0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup 253

Yes, it is okay - if I delete the rule, the network could not be
reached, because I have no default route ( also in the table main). 
It was only a _simple_ test to see if ip rules works. 
With this rule:

0:      from all lookup local
32765:  from all fwmark        2 lookup 10
32766:  from all lookup main
32767:  from all lookup 253

there is a timeout. It shows me, the marking of packets works and the ip
rules can see the marked packets.


>By the way, you are using "ip route flush cache" every time you make
>changes to the routing tables/RPDB, right?

Yes, i do.


---- cut ---- your next Mail ---- cut ----

>Aigh!  I think I may have spotted the problem.
>
>Your routing table number 10 doesn't know anything about 192.168.0.0/24
>does it?
>
>Make sure that each routing table has routes for the destinations it is
>supposed to be able to reach!
>
> : ipchains -A input -p icmp -s 192.168.0.0/24 -m 2
> : ip ru add fwmark 2 table 10
> : ip route add default via x.x.x.x dev eth2 table 10
> : ipchains -A forward -s 192.168.0.0/24 -j MASQ
> : * x.x.x.x is the default gateway!

Well, if I look into the rules table I see:

0:      from all lookup local
32765:  from all fwmark        2 lookup 10
32766:  from all lookup main
32767:  from all lookup 253

Okay! If I start the ping, the icmp packet comes into the input chain
with source address ex. 192.168.0.31 (my local host).
(ipchains -A input -p icmp -s 192.168.0.0/24 -m 2)
ipchains looks: 
- is the source address in network 192.168.0.0/24? Yes.
- is a icmp packet? Yes. 
Okay it will be marked with 2.

Now the ip rules number 32765 (all fwmark 2 lookup 10) see it and
activates routing table 10.

The routing table 10:
default via x.x.x.x dev eth2
x.x.x.x is the gateway.

Okay, it goes out on eth2 to the gateway - to the target host. It
answers a icmp packet. It arrives on eth2.

Not it is going hot :)
Normaly it should do the following:


Comes into the input chain. Ipchains looks:

- is the source address in network 192.168.0.0/24? No.

The source address it _not_ in the net 192.168.0.0/24, so it will not be
marked.

Now it is ip rules turn:

0:      from all lookup local
32765:  from all fwmark        2 lookup 10
32766:  from all lookup main
32767:  from all lookup 253

okay, not local, not marked with 10 - is comes into the main routing
table!

And this is the main routing table:
217.5.98.39 dev ppp0  proto kernel  scope link  src 80.131.187.122
n.n.n.n/28 dev eth2  proto kernel  scope link  src y.y.y.y
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.1
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1

n.n.n.n/28 is the net and y.y.y.y the ip address of eth2

In the main routing table, there is the net 192.168.0.0/24, so it should
go on!

But okay. This is not the problem.

It seems, ipchains DENY this packet. But why?


Here a ipchains -L:

Chain input (policy ACCEPT):
target     prot opt     source                destination
ports
-          icmp ------  192.168.0.0/24       anywhere              any
->   any
DENY       all  ----l-  anywhere             anywhere              n/a
Chain forward (policy DENY):
target     prot opt     source                destination
ports
MASQ       all  ------  192.168.0.0/24       anywhere              n/a
Chain output (policy ACCEPT):

The deny chain, is your chain to monitor :)
Without it (the deny chain) it is exactly the same siduation.

Wth denys ipchains this incoming packet on eth2?


Marco




_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/