[CUWiN-Dev] CUWiN routers tunnel "home" through NATs

David Young dyoung at pobox.com
Thu Sep 14 15:49:19 CDT 2006


I have some routers on the Urbana testbed phoning home like the little
E.T.'s they are.  I use GRE over UDP tunnels (a feature I recently added
to NetBSD) to tunnel back and forth through NAT routers that come between
CUWiN routers and the Internet.  This means that soon we can reach all
routers for diagnostic/upgrade purposes from the CUWiN office, including
the "pod" that surrounds my house, the "pod" on Elm east of Vine, etc.
Yay!

I have put my UDP tunnel daemon, utd, on the CUWiN routers.  It runs in
"client mode" and automatically creates tunnels.  At my office, I have
made an old UltraSPARC workstation into a tunnel concentrator; it runs
utd in "server mode."  Below is the present configuration of the ethernet
and the tunnels on my tunnel concentrator. :-)

hme0: flags=8a63<UP,BROADCAST,NOTRAILERS,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        capabilities=3c00<TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        enabled=0
        address: 08:00:20:f9:60:ee
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 64.198.255.12 netmask 0xfffffff0 broadcast 64.198.255.15
gre66: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,LINK2,MULTICAST> mtu 1476
        tunnel inet 64.198.255.12,2525 --> 70.225.175.231,17336
        inet 192.168.49.1 -> 192.168.49.70 netmask 0xffffff00
gre67: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,LINK2,MULTICAST> mtu 1476
        tunnel inet 64.198.255.12,2525 --> 64.198.255.14,15859
        inet 192.168.49.1 -> 192.168.49.71 netmask 0xffffff00
gre68: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,LINK2,MULTICAST> mtu 1476
        tunnel inet 64.198.255.12,2525 --> 70.225.175.231,18859
        inet 192.168.49.1 -> 192.168.49.72 netmask 0xffffff00

The 'tunnel inet' lines tell us what address/port pairs are at the
end of the tunnel.  Note that because of NAT, the tunnel on the CUWiN
router may not precisely agree with the tunnel on the concentrator.
E.g., this tunnel interface, which is on a router that sits on my desk,
corresponds with gre67, above:

gre392: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,LINK2,MULTICAST> mtu 1476
        tunnel inet 10.0.246.46,65533 --> 64.198.255.12,2525
        inet 192.168.49.71 -> 192.168.49.1 netmask 0xffffff00

A NAT router at a gateway node is translating 10.0.246.46,65533 to
64.198.255.14,15859.

My tunnel concentrator assigns addresses to the CUWiN routers out of
the private subnet 192.168.49/24.

There is not yet any easy way to map a gre instance or 192.168.49.x
address to a particular router in Urbana.  There is more than one way
to do it, including running hslsd on the tunnel interfaces.

Hmm.  Experimenting, I see that the concentrator can ping6 the all-hosts
multicast on any gre---e.g., ping6 ff02::1%gre68---and get a reply from
both itself and the router at the other end of the tunnel.  The router's
IPv6 number will suffice to identify it:

% ping6 ff02::1%gre68
PING6(56=40+8+8 bytes) fe80::a00:20ff:fef9:60ee%gre68 --> ff02::1%gre68
16 bytes from fe80::a00:20ff:fef9:60ee%gre68, icmp_seq=0 hlim=64 time=0.317 ms
16 bytes from fe80::202:6fff:fe20:b23f%gre68, icmp_seq=0 hlim=64 time=97.621 ms(DUP!)

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933


More information about the CU-Wireless-Dev mailing list