vpnc connects, but does not work
perryh at pluto.rain.com
perryh at pluto.rain.com
Mon Dec 29 09:30:51 UTC 2008
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 at 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
More information about the freebsd-questions
mailing list