Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Dec 2008 01:29:39 -0800
From:      perryh@pluto.rain.com
To:        freebsd-questions@FreeBSD.org
Subject:   vpnc connects, but does not work
Message-ID:  <49589883.lhmPNVeBMeI7aDqo%perryh@pluto.rain.com>

next in thread | raw e-mail | index | archive | help
I have installed vpnc to connect to an employer's Cisco VPN
system, and it seems to make the connection, but after connecting
I can't ping the tun0 interface nor anything beyond it.  The
symptom seems to resemble what is described in the Routing section
of http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn.pdf, but since that
is using a completely different setup on the FreeBSD side I have no
idea whether the remedy described there is applicable (nor, if it
is, how to determine the addresses to use in this case).

Does this look at all familiar, or does anyone have any ideas for
how to go about debugging it?  I didn't find anything that seemed
applicable in recent ports@ or questions@ archives, and an earlier
inquiry on ports@ did not produce a solution.  (I have XX'd out
potentially-sensitive material in the following.)

  # /usr/local/sbin/vpnc
  Enter password for XXX@XXX.XXX.com:
  Connect Banner:
  | *** XXX, Inc. Authorized Use Only ***

  add host YYY.YYY.127.228: gateway 192.168.200.254
  add net ZZZ.ZZZ.0.0: gateway ZZZ.ZZZ.233.42
<snipped 56 other "add net" lines, all with the same
 gateway address, none to any ZZZ.ZZZ address until:>
  add net ZZZ.ZZZ.57.128: gateway ZZZ.ZZZ.233.42
  add net ZZZ.ZZZ.57.133: gateway ZZZ.ZZZ.233.42
  VPNC started in background (pid: 24776)...

The addresses in those last two "add net" lines seem to be the
nameservers:

  $ cat /etc/resolv.conf
  #@VPNC_GENERATED@ -- this file is generated by vpnc
  # and will be overwritten by vpnc 
  # as long as the above mark is intact
  nameserver ZZZ.ZZZ.57.128
  nameserver ZZZ.ZZZ.57.133
  search XXX.com

which leads me to wonder whether they really ought to be "add host"
-- for that matter it's not clear they're needed at all since they
should be covered by the "add net ZZZ.ZZZ.0.0" -- but I guess that
may not make much difference when I can't even ping my own gateway
(tun0) address :(

  $ ping ZZZ.ZZZ.233.42
  PING ZZZ.ZZZ.233.42 (ZZZ.ZZZ.233.42): 56 data bytes
  ^C
  --- ZZZ.ZZZ.233.42 ping statistics ---
  4 packets transmitted, 0 packets received, 100% packet loss

  $ ping ZZZ.ZZZ.57.128
  PING ZZZ.ZZZ.57.128 (ZZZ.ZZZ.57.128): 56 data bytes
  ^C
  --- ZZZ.ZZZ.57.128 ping statistics ---
  10 packets transmitted, 0 packets received, 100% packet loss

  $ ping ZZZ.ZZZ.57.133
  PING ZZZ.ZZZ.57.133 (ZZZ.ZZZ.57.133): 56 data bytes
  ^C
  --- ZZZ.ZZZ.57.133 ping statistics ---
  27 packets transmitted, 0 packets received, 100% packet loss

  $ ifconfig -a
  xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          options=9<RXCSUM,VLAN_MTU>
          inet6 fe80::2b0:d0ff:fe28:ad4f%xl0 prefixlen 64 scopeid 0x1
          inet 192.168.200.61 netmask 0xffffff00 broadcast 192.168.200.255
          ether 00:b0:d0:28:ad:4f
          media: Ethernet autoselect (10baseT/UTP)
          status: active
  plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT> mtu 1500
  lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
          inet6 ::1 prefixlen 128
          inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
          inet 127.0.0.1 netmask 0xff000000
  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

Meanwhile I _can_ ping YYY.YYY.127.228, which I guess is the
concentrator's public IP address:

  $ ping YYY.YYY.127.228
  PING YYY.YYY.127.228 (YYY.YYY.127.228): 56 data bytes
  64 bytes from YYY.YYY.127.228: icmp_seq=0 ttl=116 time=53.226 ms
  64 bytes from YYY.YYY.127.228: icmp_seq=1 ttl=116 time=52.982 ms
  64 bytes from YYY.YYY.127.228: icmp_seq=2 ttl=116 time=53.130 ms
  ^C
  --- YYY.YYY.127.228 ping statistics ---
  3 packets transmitted, 3 packets received, 0% packet loss
  round-trip min/avg/max/stddev = 52.982/53.113/53.226/0.100 ms

Traceroute to YYY.YYY.127.228 produces the same 14-hop result whether
connected or disconnected (modulo the need to use "traceroute -n"
while connected:  since vpnc has replaced /etc/resolv.conf with one
specifying only the corporate nameservers, and I can't reach them
because the link doesn't work, there is no name service while
connected).  Just like ping, traceroute to the tun0 IP address,
while connected, produced nothing:

  $ traceroute -n ZZZ.ZZZ.233.42
  traceroute to ZZZ.ZZZ.233.42 (ZZZ.ZZZ.233.42), 64 hops max, 40 byte packets
   1  * * *
   2  * * *
   3  * * *
   4  * * *
   5  * * *
  ^C

What seems truly bizarre is that, as noted above, I couldn't ping the
tun0 interface while connected even though ifconfig reported it as
up.  Shouldn't a local interface, reported as up, *always* respond to
a ping of its own IP address?

  $ netstat -r -n
  Routing tables

  Internet:
  Destination        Gateway            Flags    Refs      Use  Netif Expire
  default            192.168.200.254    UGS         0  2209723    xl0
<snip lines corresponding to snipped "add net" lines above>
  127.0.0.1          127.0.0.1          UH          0        2    lo0
  ZZZ.ZZZ            ZZZ.ZZZ.233.42     UGS         0        0   tun0
  ZZZ.ZZZ.57.128/32  ZZZ.ZZZ.233.42     UGS         0       19   tun0
  ZZZ.ZZZ.57.133/32  ZZZ.ZZZ.233.42     UGS         0       18   tun0
  ZZZ.ZZZ.233.42     ZZZ.ZZZ.233.42     UH         59       20   tun0
  YYY.YYY.127/27     ZZZ.ZZZ.233.42     UGS         0        0   tun0
  YYY.YYY.127.96/27  ZZZ.ZZZ.233.42     UGS         0        0   tun0
  YYY.YYY.127.224/27 ZZZ.ZZZ.233.42     UGS         0        0   tun0
  YYY.YYY.127.228    192.168.200.254    UGHS        0      106    xl0
  192.168.200        link#1             UC          0        0    xl0
  192.168.200.254    00:09:5b:a1:c8:9e  UHLW        3  4318078    xl0   1148
  192.168.200.255    ff:ff:ff:ff:ff:ff  UHLWb       1        3    xl0



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49589883.lhmPNVeBMeI7aDqo%perryh>