Re: [LARTC] ipip and nexthdr

[Abraham van der Merwe <abz@frogfoot.net>]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]