From owner-freebsd-net@FreeBSD.ORG Sat Jan 3 09:02:30 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76E4E106566C for ; Sat, 3 Jan 2009 09:02:30 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id D020D8FC18 for ; Sat, 3 Jan 2009 09:02:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n0392OGF073483; Sat, 3 Jan 2009 20:02:25 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 3 Jan 2009 20:02:24 +1100 (EST) From: Ian Smith To: perryh@pluto.rain.com In-Reply-To: <495f15da.kLIW2g4L+3rMjCXS%perryh@pluto.rain.com> Message-ID: <20090103185837.K28770@sola.nimnet.asn.au> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> <20090103154232.P28770@sola.nimnet.asn.au> <495f15da.kLIW2g4L+3rMjCXS%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: tun0 not responding to ping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 09:02:30 -0000 On Fri, 2 Jan 2009, perryh@pluto.rain.com wrote: > Ian Smith wrote: uucp .. how quaint :) > ... > > > tun0: flags=8051 mtu 1412 > > > inet6 fe80::2b0:d0ff:fe28:ad4f%tun0 prefixlen 64 scopeid 0x4 > > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.233.42 netmask 0xffffffff > > > Opened by PID 24635 > > > > I don't know if this is relevant or not, but I've never seen > > a point to point interface use the same IP address on both ends > > of its link before. > > I don't know either, nor whether -- and if so how -- it could keep > tun0 from responding to a ping of its own IP address. It looks like > the same issue described, for a different way of connecting to a > Cisco 3000 from FreeBSD, here: > > http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn.pdf "You don't have permission to access /~flemej/fbsd-cisco-vpn.pdf on this server." Nor http://www.cs.rpi.edu/~flemej .. so I can't consult that, but as I said, I know next to nothing about VPN configuration anyway. > If I am understanding the article correctly, the 3000 does something > unexpected in the course of setting up the P2P connection. However: > > * Since the FreeBSD config is completely different, I don't know > to what extent the w/a described there would be applicable. > > * Supposing that tun0 does need to be readdressed as > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.2.13 netmask 0xffffffff > > -- where ZZZ.ZZZ.2.13 is the address of the Cisco box on > ZZZ.ZZZ.0.0/16 -- I'm not at all clear on how a w/a should get > that internal address in the general case. (I got it by running > a traceroute from an inside machine to a working VPN-connected > Windows system, after not finding anything in the vpnc logs.) Beyond me .. I don't even know what a w/a is, but I'm pretty sure ppp is going to need a remote address, and a route to it. > * Since vpnc is supposed to have been written specifically to > connect with Cisco 3000's and similar, I'd have expected it to > somehow take care of the 3000's quirks rather than needing a > separate w/a, although I don't know enough about either tun(4) > or P2P to understand the details. Usually you can ping either end; ping is the same as ping localhost, ping is, well, that. With both the same, I'm not too surprised that ppp can't figure out which end you want to talk to? We ran ppp for 10 years on a dialup link but these days for pppoe using mpd, but the routing should come to about the same, given that here it's our default route. ng0: flags=88d1 mtu 1492 inet xxx.yyy.zzz.227 --> xxx.yyy.1.33 netmask 0xffffffff Destination Gateway Flags Refs Use Netif Expire default xxx.yyy.1.33 UGS 0 24390 ng0 [..] xxx.yyy.1.33 xxx.yyy.zzz.227 UH 1 0 ng0 xxx.yyy.zzz.227/32 lo0 US 0 2 lo0 This is a 5.5 system, in case different presentation might mislead. HTH, Ian