From owner-freebsd-questions@FreeBSD.ORG Mon Dec 29 09:30:51 2008 Return-Path: Delivered-To: freebsd-questions@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC465106564A for ; Mon, 29 Dec 2008 09:30:51 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id AC8BA8FC12 for ; Mon, 29 Dec 2008 09:30:51 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id mBT9UpPx028389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 29 Dec 2008 01:30:51 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id mBT9UpEJ028388 for freebsd-questions@FreeBSD.org; Mon, 29 Dec 2008 01:30:51 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA21136; Mon, 29 Dec 08 01:27:03 PST Date: Mon, 29 Dec 2008 01:29:39 -0800 From: perryh@pluto.rain.com To: freebsd-questions@FreeBSD.org Message-Id: <49589883.lhmPNVeBMeI7aDqo%perryh@pluto.rain.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: vpnc connects, but does not work X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 09:30:51 -0000 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 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 mtu 1500 options=9 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 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8051 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 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