tun0 not responding to ping
perryh at pluto.rain.com
perryh at pluto.rain.com
Sat Jan 3 13:14:36 PST 2009
Ian Smith <nimnet.asn.au!smithi at agora.rdrop.com> wrote:
> On Fri, 2 Jan 2009, perryh at pluto.rain.com wrote:
> > Ian Smith <nimnet.asn.au!smithi at 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 at 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)?
More information about the freebsd-net
mailing list