Subject: Re: Truly bizarre problem with GRE tunnel.
To: None <current-users@NetBSD.org>
From: David Young <firstname.lastname@example.org>
Date: 07/21/2006 13:40:02
On Mon, Jul 03, 2006 at 12:10:30PM +0200, Lars-Johan Liman wrote:
> I'm responding to my own message from 2005-12-03 here. I didn't get
> very far last time, although Christos did his best and deserves my
> warmest appreciation.
> "For external reasons" this issue resurfaced on my stack. I did some
> more debuggning today, and came to the following somewhat odd
> If I don't have packet filtering turned on, and set up a routing entry
> in the kernel, that routes certain packets into the GRE tunnel, that
> works fine, *BUT*, if I turn on the packet forwarding engine in ipf
> using "express forwarding", then it breaks. The way it breaks is that
> the packet length field and the header checksum in the _INNER_ packet
> are byte swapped.
> In the attached tcpdump file I use 188.8.131.52/28 on the inside, and
> I ping from host 184.108.40.206. In the "router" i route 220.127.116.11
> explicitly to 192.168.101.2 (address inside remote end of tunnel). The
> first two pings succeed.
> Then I add the following to my /etc/ipf.conf:
> pass in on fxp0 to gre0 from 18.104.22.168/28 to any
> (note the "to gre0" which is the express forwarding).
> The two following pings never arrive at the destination, because the
> remote tunnel endpoint discards them, due to the issues above.
> I would call this a bug, and I would appreciate if someone with IP
> stack clue/interface driver clue/ipf clue could spend a cycle or two
> to figure out why there is a difference.
I guess it is a coincidence, but one of my Google SoC students observes
packet corruption using pf+gif. His rule uses "route-to," pf's equivalent
to ipf's "to" directive. He is still investigating.
David Young OJC Technologies
email@example.com Urbana, IL * (217) 278-3933