tun0 not responding to ping

[perryh at pluto.rain.com]

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

  $ 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