Date: Wed, 17 Dec 2008 09:32:15 -0800 From: Julian Elischer <julian@elischer.org> To: Joe Marcus Clarke <marcus@freebsd.org> Cc: Qing Li <qingli@freebsd.org>, Marko Zec <zec@icir.org>, Kip Macy <kmacy@freebsd.org>, freebsd-current@freebsd.org Subject: Re: NAT (ipfw/natd) broken in latest -CURRENT Message-ID: <4949379F.2070105@elischer.org> In-Reply-To: <49491BFA.5090605@freebsd.org> References: <1229476796.49670.7.camel@shumai.marcuscom.com> <4948C7BE.7070602@oltrelinux.com> <200812171148.38528.zec@icir.org> <49491BFA.5090605@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4949379F.2070105>