LARTC - Aug 2003 - Iptables Marking Output

Hi,

Can anyone help me with a problem I have
I have a problem with iptables and the MARK option.
I then want to ping a destination which is not in the routing
table by forcing the icmp protocol out over eth1 using iptables.
I have setup routing for two ethernet interfaces as follows

Table T1:
default via 172.21.1.11 dev eth1        

Table T2:
default via 172.21.1.11 dev eth1        

Table Main:
172.21.0.0/16 dev eth1                 
172.22.0.0/16 dev eth2

Rules Table:
32758 from all fwmark 1 lookup T1
32759 from all fwmark 2 lookup T2
32760 from all 172.21.1.12 lookup T1
32761 from all 172.22.1.12 lookup T2

IPTables Rule:
iptables -t mangle -A OUTPUT -p icmp -j MARK --set-mark 1

To test this: 
I ping a destination address that is not in my routing table e.g 164.20.1.2
I get Network Unreachable. I do not see the echo request in the trace 
of the eth1 messages. I had expected the mark to be set, causing the packet 
to be routed to gateway 172.21.1.11 with the source address set to 172.21.1.12.

I ping an address on my eth2 network and I can see the ping in the
trace of eth1 interface messages. So I can confirm that the MARK has been set 
and the packet has been routed to eth1. However it did not have eth1 source 
address set in the packet ?

So I read the IpTables Tutorial and find it contradicts itself

Section 3.1 table 3.2: suggests that the routing decision is made 
prior to the mangle happening. This appears to be what I can see happening.
Hence we can never find a route in our table and this would result in
Network Unreachable.

Section 6.2 table 6.1 suggests that the mangle of OUTPUT happens 
prior to the routing decision. I don''t think this is true because
otherwise
the Mark would be set to 1 and the frame would have been routed correctly
to 172.21.1.11. Also the theory is backed up by the fact that the ping on
eth2 was routed out eth2 but with an incorrect source address. The source 
address being added as a result of the routing decision.

Now I am very much a newcomer to routing so have probably misunderstood the 
entire principles. Could someone confirm if what I am trying to do is 
correct or if I have completely gone mad and missed the point. 
(which wouldn''t be the first time !)

Many thanks in advance

Paul.


-----------------------------------------
Email provided by http://www.ntlhome.com/


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

Hello Paul,


On Wed, 2003-08-20 at 20:55, paul.walling@ntlworld.com wrote:

<snip>
> So I read the IpTables Tutorial and find it contradicts itself
> 
> Section 3.1 table 3.2: suggests that the routing decision is made 
> prior to the mangle happening. This appears to be what I can see happening.
> Hence we can never find a route in our table and this would result in
> Network Unreachable.
> 
> Section 6.2 table 6.1 suggests that the mangle of OUTPUT happens 
> prior to the routing decision. I don''t think this is true because
otherwise
> the Mark would be set to 1 and the frame would have been routed correctly
> to 172.21.1.11. Also the theory is backed up by the fact that the ping on
> eth2 was routed out eth2 but with an incorrect source address. The source 
> address being added as a result of the routing decision.
This is an issue which I have been trying to resolve for some time  ...
you are correct that the routing decision is made prior to a packet
traversing OUTPUT, therefore your attempt to mark and route on locally
generated packets will not work.

two solutions exist:

(1) on the netfilter sight, you''ll find a patch from Cédric de Launois
which allows you to select the interface:

iptables -A POSTROUTING -t mangle -p icmp -j ROUTE --iface eth1


(2) you can mark in OUTPUT and then fiddle in the POSTROUTING chain:

iptables --append OUTPUT --table mangle --jump MARK --set-mark 0x2

iptables --append POSTROUTING --table nat --match mark --mark 0x2 \
   --jump SNAT --to-source 192.168.1.100


I have been dreaming of a new netfilter target called rt_lookup that
would force a route lookup using the all the packet characteristics as
it traverses the NAT table of the POSTROUTING chain -- regrettably, I
have not had the time to investigate whether it is even possible!

Ciao

Charles

> Now I am very much a newcomer to routing so have probably misunderstood the
> entire principles. Could someone confirm if what I am trying to do is 
> correct or if I have completely gone mad and missed the point. 
> (which wouldn''t be the first time !)
> 
> Many thanks in advance
> 
> Paul.
> 
> 
> -----------------------------------------
> Email provided by http://www.ntlhome.com/
> 
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


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