LARTC - Dec 2002 - ipip and nexthdr

After carefull reading (LARTC) and experimentation, I am in a dead
end...

 I am using several IPIP tunnels (linux ipip module, IP protocol 4).

 I''d like to filter packets going through these tunnes to different
classes, on the ingress device, based on source and destination IP
_INSIDE THE TUNNEL_.

 First I tried the nexthdr bit. As explained in LARTC, nexthdr jumps to
the next header in the packet, so I figured if it works for TCP, it
should also work for IP in IP, but it didn''t. 

 I looked at some ICMP echo request/reply packets with tcpdump dumping
packet contents in hex. 
The IP header is 20 bytes. I tried the following:

a.b.c.d is an IP inside the tunnel.

tc filter ... u32 match ip src a.b.c.d at nexthdr+0
I assumed this would go to the inner ip header, ip src will set the
correct offset. WRONG.
tc filter ... u32 match ip src a.b.c.d at nexthdr+12
This should point to the source address in the IP header, in the next
header = the tunnel.
WRONG. 

tc filter ... u32 match 0xaabbccdd 0xffffffff at 32 
CORRECT. this correctly matches the source ip inside the tunnel

I browsed a lot inside the source of tc (from iproute) but how nexthdr
works is still unclear to me.

However, I''d like to be able to make the filter selections with ip src,
ip dst sport, dport inside the tunnel, before decapsulation.


-- 
ing. Andrei Boros
mailto:andrei@srr.ro / +40-21-303-1870
Centrul pt. Tehnologia Informatiei
Societatea Romana de Radiodifuziune
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Hi Andrei!

Look in the mail archives. Somebody posted a solution for GRE tunnels last
week.
>  After carefull reading (LARTC) and experimentation, I am in a dead
> end...
> 
>  I am using several IPIP tunnels (linux ipip module, IP protocol 4).
> 
>  I''d like to filter packets going through these tunnes to
different
> classes, on the ingress device, based on source and destination IP
> _INSIDE THE TUNNEL_.
> 
>  First I tried the nexthdr bit. As explained in LARTC, nexthdr jumps to
> the next header in the packet, so I figured if it works for TCP, it
> should also work for IP in IP, but it didn''t. 
> 
>  I looked at some ICMP echo request/reply packets with tcpdump dumping
> packet contents in hex. 
> The IP header is 20 bytes. I tried the following:
> 
> a.b.c.d is an IP inside the tunnel.
> 
> tc filter ... u32 match ip src a.b.c.d at nexthdr+0
> I assumed this would go to the inner ip header, ip src will set the
> correct offset. WRONG.
> tc filter ... u32 match ip src a.b.c.d at nexthdr+12
> This should point to the source address in the IP header, in the next
> header = the tunnel.
> WRONG. 
> 
> tc filter ... u32 match 0xaabbccdd 0xffffffff at 32 
> CORRECT. this correctly matches the source ip inside the tunnel
> 
> I browsed a lot inside the source of tc (from iproute) but how nexthdr
> works is still unclear to me.
> 
> However, I''d like to be able to make the filter selections with ip
src,
> ip dst sport, dport inside the tunnel, before decapsulation.
-- 

Regards
 Abraham

Military secrets are the most fleeting of all.
		-- Spock, "The Enterprise Incident", stardate 5027.4

___________________________________________________
 Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks
 P.O. Box 3472, Matieland, Stellenbosch, 7602
 Cell: +27 82 565 4451 Http: http://www.frogfoot.net
 Email: abz@frogfoot.net