Date: Sat, 03 Jan 2009 13:13:24 -0800 From: perryh@pluto.rain.com To: smithi@nimnet.asn.au Cc: freebsd-net@freebsd.org Subject: Re: tun0 not responding to ping Message-ID: <495fd4f4.LnYmNJ/Km8Riy79x%perryh@pluto.rain.com> In-Reply-To: <20090103185837.K28770@sola.nimnet.asn.au> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> <20090103154232.P28770@sola.nimnet.asn.au> <495f15da.kLIW2g4L%2B3rMjCXS%perryh@pluto.rain.com> <20090103185837.K28770@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian Smith <nimnet.asn.au!smithi@agora.rdrop.com> wrote: > On Fri, 2 Jan 2009, perryh@pluto.rain.com wrote: > > Ian Smith <nimnet.asn.au!smithi@agora.rdrop.com> wrote: > > uucp .. how quaint :) Yep, but running over ssh since agora no longer has modems. How's that for a mix of ancient and modern technology? :) > > 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, That's odd. It worked from here as recently as 12/17. The article is FreeBSD interoperability with Cisco VPN Concentrator 3000 series James Flemer jflemer@alum.rpi.edu October 10, 2002 and the relevant excerpt -- after it describes a setup involving netgraph(4) and the mpd port -- is 3.4 Routing Unfortunately, this does not work completely. It successfully establishes the PPTP connection, but cannot send anything over it. The problem is that the PPTP implementation for the concentrator forces its end of the PPP link to have the same IP as the address of its public interface (192.168.0.2 in this network). This causes FreeBSD to have routing problems, because the default gateway becomes 192.168.0.2 (via ng0), but in order to use that tunnel it has to send GRE packets to 192.168.0.2. The solution to this is as follows. Once the PPTP link is up, you need to re-address the ng0 interface and then change your default route. In the example network, you have to execute the following commands (assuming we are assigned 10.0.2.42 for our side of the link): # ifconfig ng0 inet 10.0.2.42 10.0.0.2 netmask 0xffffffff # route delete default # route add default -interface ng0 What I see is a bit different -- both ends get the IP that's supposed to have been assigned to my end, rather than the Cisco end getting the Cisco's public IP -- but perhaps related. > but as I said, I know next to nothing about VPN configuration anyway. I suspect this problem has more to do with PPP, tun(4), and routing than with VPN's as such. vpnc does seem to be establishing the VPN connection. > > * 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. w/a = workaround. > Usually you can ping either end; ping <my end> is the same as ping > localhost That's what I expected. > ping <other end> 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? Maybe that's (part of?) the problem, although I would have thought that the local side would immediately respond to its own address, without even checking anything else. > 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<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1492 > inet xxx.yyy.zzz.227 --> xxx.yyy.1.33 netmask 0xffffffff Hmm. Maybe tun0 needs NOARP and/or SIMPLEX (but, as with the remote IP address, I'd have expected vpnc to configure the interface as required rather than needing help). > 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. This one is not all that much newer (6.1). One thing I notice, which seems odd, is the route to ng0's local IP address via lo0. Shouldn't the stack be able to communicate directly with a local ng (or tun) interface, just as it does with something like an xl0 (or lo0, for that matter)?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?495fd4f4.LnYmNJ/Km8Riy79x%perryh>