Li, Qing wrote: > 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 ... FYI, I just switched my config to do proxy arp with a LAN IP, and it works. My new ifconfig looks like: em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> ether 00:11:11:10:46:1e inet 172.18.254.236 netmask 0xffffff00 broadcast 172.18.254.255 inet6 fe80::211:11ff:fe10:461e%em0 prefixlen 64 scopeid 0x1 inet 172.18.254.237 netmask 0xffffffff broadcast 172.18.254.237 inet6 2003:a02::1 prefixlen 64 media: Ethernet 100baseTX <full-duplex> (100baseTX <half-duplex>) status: active tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1300 inet6 fe80::211:11ff:fe10:461e%tun0 prefixlen 64 scopeid 0x5 inet 172.18.254.237 --> 172.18.254.240 netmask 0xffffff00 Opened by PID 35867 My new netstat looks like: Destination Gateway Flags Refs Use Netif Expire default 172.18.254.1 UGS 0 31659 em0 127.0.0.1 link#3 UH 0 720 lo0 172.18.254.0/24 link#1 U 0 8 em0 172.18.254.237/32 link#1 U 0 8 em0 172.18.254.240 link#5 UH 0 1060 tun0 Joe > > --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" > _______________________________________________ > 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" > -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome_at_FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnomeReceived on Wed Dec 17 2008 - 17:19:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:39 UTC