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
> conclusion:
> 
> 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 192.71.80.160/28 on the inside, and
> I ping from host 192.71.80.163. In the "router" i route 192.71.80.70
> 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 192.71.80.160/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.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933