Subject: Re: Truly bizarre problem with GRE tunnel.
To: None <current-users@NetBSD.org>
From: David Young <email@example.com>
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 220.127.116.11/28 on the inside, and
> I ping from host 18.104.22.168. In the "router" i route 22.214.171.124
> 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 126.96.36.199/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
firstname.lastname@example.org Urbana, IL * (217) 278-3933