Date: Sat, 3 Jan 2009 15:55:42 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: perryh@pluto.rain.com Cc: freebsd-net@freebsd.org Subject: Re: tun0 not responding to ping Message-ID: <20090103154232.P28770@sola.nimnet.asn.au> In-Reply-To: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2 Jan 2009, perryh@pluto.rain.com wrote: > 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<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 I don't know if this is relevant or not, but I've never seen a point to point interface use the same IP address on both ends of its link before. I noticed this before when you posed this on questions@ but not knowing anything about vpnc and very little about VPNs in general, I let it go. > $ 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 There it is again. Looks circular to me, but I may be way off base .. Nice diagrams :) cheers, Ian > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090103154232.P28770>