tun0 not responding to ping

[Ian Smith]

On Sat, 3 Jan 2009, perryh at pluto.rain.com wrote:
 > 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? :)

I like it ..

 > >  >   http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn.pdf
 > >
 > > "You don't have permission to access /~flemej/fbsd-cisco-vpn.pdf
 > 
 > That's odd.  It worked from here as recently as 12/17.

Thanks for mailing it.  It's at http://smithi.id.au/fbsd-cisco-vpn.pdf 
(100K) for now, if anyone else is interested.

 >                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.

Had a quick look at http://www.unix-ag.uni-kl.de/~massar/vpnc/ but don't 
get whether it, or you, are configuring ppp?  ie, does vpnc make or mess 
with /etc/ppp/ppp.conf?  Or otherwise invoke ppp directly itself?

You can do pretty much like the above by invoking an /etc/ppp/ppp.linkup 
script.  Here you're not using the tunnel as your default route anyway, 
but you could perhaps fix the addressing with ifconfig, though a quick 
refresher skim through ppp(8) shows a way/s to force the remote ppp to 
supply its IP address if it's otherwise recalcitrant.  Or if you know 
it, you can force it by an appropriate 'set if_addr' address/mask.

Have you considered using mpd for this instead?  It comes with PPTP 
example configs, and while some syntax has changed from then (2002, 
maybe mpd 3) to now (mpd 5 .. I'm still using 4.1) it might be more 
straightforward to setup, and mav@ is around here and ever helpful ..

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

Have another dig through CONTROLLING IP ADDRESS in ppp(8) (set if_addr), 
which appears to include a case where remote is reluctant to supply its 
address.  And then, it may not matter - as long as it's not the same as 
your end - if you're using 'route add <whatever> -interface ppp0' but 
that's really in the realm of guesswork, treat with due suspicion ..

 > w/a = workaround.

Ah!

 > > 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.

I don't know whether it would even get to ppp, past the routing; point 
to point without two points being a bit, er, pointless :)  Also, any 
routes you add via that link specify the far (not near) end as gateway, 
with then a single host route for the far end via the near, as below.

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

I've not seen ppp use those options, just mpd, but I dunno.  Seems vpnc 
is generating your ppp.conf?  I've no idea what it's doing here, sorry, 
nor whether such a VPN requires proxy ARP to work.  If so, ppp can do.

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

I wondered about that too, but that it works fine has been good enough. 
Perhaps it has something to do with the fact that ng0 is really working 
over another physical ethernet interface? (here, xe0 to an ADSL bridge)

I'm out of ideas, so hopefully some of the Cogniscenti will chime in, if 
they're not all still sunning themselves in the Bahamas, or Cairns ..

cheers, Ian