tun0 not responding to ping
Ian Smith
smithi at nimnet.asn.au
Fri Jan 2 20:55:46 PST 2009
On Fri, 2 Jan 2009, perryh at 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
More information about the freebsd-net
mailing list