RE: NAT (ipfw/natd) broken in latest -CURRENT

Yes, it appears to be arp-v2 related changes. I am suspecting the p2p 
link type and the fact the tunnel end points appear to be on-link with 
each other might be the problem.

I am investigating the problem right now ...

--Qing

> -----Original Message-----
> From: owner-freebsd-current_at_freebsd.org [mailto:owner-freebsd-
> current_at_freebsd.org] On Behalf Of Julian Elischer
> Sent: Wednesday, December 17, 2008 9:32 AM
> To: Joe Marcus Clarke
> Cc: Qing Li; Marko Zec; Kip Macy; freebsd-current_at_freebsd.org
> Subject: Re: NAT (ipfw/natd) broken in latest -CURRENT
> 
> Joe Marcus Clarke wrote:
> > Marko Zec wrote:
> >> On Wednesday 17 December 2008 10:34:54 Paolo Pisati wrote:
> >>> Joe Marcus Clarke wrote:
> >>>> I just upgraded my i386 -CURRENT box from November 14 to today,
> and
> >>>> now my SSH-over-PPP VPN tunnel no longer works.  I did some
packet
> >>>> captures, and it appears that NAT is no longer working.  If I
send
> >>>> a telnet packet from my client side over the PPP tunnel, I see
the
> >>>> SYN go out on the server side network properly translated.  The
> >>>> destination host ACKs correctly, but the ACK never goes back
> across
> >>>> the tunnel.  It's as if natd is no longer translating the packet
> on
> >>>> the inbound path.  Besides the upgrade, nothing has changed in my
> >>>> environment.
> >>> lately some work has been done on the vimage and routing tree
stuff,
> >>> thus your best bet  is to go back
> >>> some days and try again.
> >> Hi Joe,
> >>
> >> could you try building your kernel with options VIMAGE_GLOBALS and
> tell
> >> us whether this makes any difference - turning on VIMAGE_GLOBALS
> should
> >> revert certain aspects of virtualization changes that recently got
> >> merged into the tree.
> >
> > Thanks for the suggestion, but the results are the same.  I turned
on
> > -verbose on natd, and I see the ACK packet come back from the
> > destination, and natd is translating it correctly.  However, I never
> see
> > the ACK on the remote end of the tunnel.  It looks like a routing
> > problem at this point.  It's as if the kernel doesn't know on what
> > interface to encapsulate the reply packet.
> 
> the arpv2 changes seem to have somehow changed point-to-point routes
> so it may be related to that..
> I'll wait for Qing or Kmacy to check....
> 
> 
> >
> > Joe
> >
> >> Cheers,
> >>
> >> Marko
> >>
> >>
> >
> >
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-
> unsubscribe_at_freebsd.org"