From owner-freebsd-net@FreeBSD.ORG Sat Jan 3 04:08:57 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81399106564A for ; Sat, 3 Jan 2009 04:08:57 +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 677058FC19 for ; Sat, 3 Jan 2009 04:08:57 +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 n033arD2062773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Jan 2009 19:36:53 -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 n033arce062769 for freebsd-net@freebsd.org; Fri, 2 Jan 2009 19:36:53 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA03745; Fri, 2 Jan 09 19:31:04 PST Date: Fri, 02 Jan 2009 19:33:31 -0800 From: perryh@pluto.rain.com To: freebsd-net@freebsd.org Message-Id: <495edc8b.yfwTDGtb9G/8NMur%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 Subject: tun0 not responding to ping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 04:08:57 -0000 Why would a local interface, reported as up in ifconfig, not respond to a ping of its own IP address? The tun0 reported below doesn't, and I have no idea how to debug it. (I've overwritten the two most- significant octets of its IP address, which is Class B, so as not to publicly identify the network to which I am attempting to connect.) $ 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 $ 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 $ 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 $ 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 In case it matters the tunnel was set up by the security/vpnc port, however my focus in this inquiry is on the expected behavior of the tun(4) driver, which is part of the base and therefore (I hope) on-topic here. Inquiries regarding vpnc on ports@ and questions@ have not yielded a solution. For background, the network geometry involved is: 192.168.200.0/8 +---------------------+---------------------+ | | | 192.168.200.254 192.168.200.95 192.168.200.61[xl0] +-----------------+ +-----------------+ +-----------------+ | Netgear router | | Windows | | FreeBSD | | | | Cisco VPN client| | vpnc | +-----------------+ +-----------------+ +-----------------+ 71.111.59.66 ZZZ.ZZZ.233.6 ZZZ.ZZZ.233.42[tun0] | | | +-----------------+ | DSL modem | | | +-----------------+ [works] [does not work] | | | -- Internet -- | | | YYY.YYY.127.228 +-----------------+ | | | Cisco 3000 | < - - - - - - - - - - - - - - - -+ +-----------------+ ZZZ.ZZZ.2.13 | ZZZ.ZZZ.0.0/16 +---------------------+---------------------+ (and no, I am not trying to have both the Windows client and the FreeBSD client connected at the same time, although that ought to work -- the Cisco will supposedly allow up to 4 concurrent connections from the same LAN using the same credentials). I think the tunnel's data flow should be something like: +---------------+---------------+ | application (ping, ssh, etc.) | | to (say) ZZZ.ZZZ.11.220 | +---------------+---------------+ ^ [socket] v +----------+----------+ | kernel TCP/IP stack | +----------+----------+ ^ [routing] v +--------+--------+ | tun0 interface | <-- ping packets to ZZZ.ZZZ.233.42 looped | ZZZ.ZZZ.233.42 | <-- back here, all else passed to vpnc +--------+--------+ ^ | v +--------------+--------------+ | userspace vpnc daemon | | [encapsulation/encryption] | | to YYY.YYY.127.228 | +--------------+--------------+ ^ [socket] v +----------+----------+ | kernel TCP/IP stack | +----------+----------+ ^ [routing] v +-------+-------+ | xl0 interface | | 192.168.200.61| +-------+-------+ ^ 192.168.200.0/8 v +--------+--------+ | 192.168.200.254 | | Netgear router | | 71.111.59.66 | +--------+--------+ ^ DSL/Internet v +--------------+--------------+ | YYY.YYY.127.228 | | Cisco 3000 | | [decapsulation/decryption] | | ZZZ.ZZZ.2.13 | +--------------+--------------+ ^ ZZZ.ZZZ.0.0/16 v ZZZ.ZZZ.11.220