tun0 not responding to ping

[Ian Smith]

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 :)

 > ...
 > >  >   tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> 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 <my end> is the same as ping 
localhost, 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?

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

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