bin/39233: OpenSSH fails to initialize tun(4) tunnels correctly

[Taylor R Campbell <campbell%mumble.net@localhost>]

>Number:         39233
>Category:       bin
>Synopsis:       OpenSSH fails to initialize tun(4) tunnels correctly
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 28 02:00:01 +0000 2008
>Originator:     Taylor R Campbell <campbell%mumble.net@localhost>
>Release:        NetBSD 4.0_STABLE
>Organization:
>Environment:
System: NetBSD smalltalk 4.0_STABLE NetBSD 4.0_STABLE (RIAXEN3_DOM0) #2: Fri 
Jul 18 23:32:56 UTC 2008 
riastradh@smalltalk:/home/riastradh/netbsd/4/obj/sys/arch/i386/compile/RIAXEN3_DOM0
 i386
Architecture: i386
Machine: i386
>Description:

        After running `ssh -w 0:1' (the numbers don't matter; they just
        help me to keep from getting mixed up) to create a tun(4)
        tunnel over ssh, and after configuring the tun(4) interfaces
        appropriately on both machines, no packets actually get through
        the tunnel.
        
        `ssh -vvv' on NetBSD 4.99.70 (i.e. with OpenSSH 5.0) reveals
        from debugging messages that packets are being transmitted
        between the ssh end-points, but no packets get through the
        tun(4) interfaces.  I checked the routes for the end-points'
        point-to-point IP addresses, and they correctly indicate using
        the tun(4) interfaces.
        
        Ethernet tunnels, with `ssh -o Tunnel=ethernet', also don't
        work.  I believe in this case, the code in ssh/misc.c's
        tun_open will not correctly turn the tunnel interface into a
        broadcast interface from a point-to-point interface, since it
        doesn't use the TUNSIFMODE ioctl command described in the
        tun(4) man page.  It is not immediately obvious to me, however,
        why the point-to-point tunnels don't work.
        
        I tried creating tunnels between NetBSD 4.0_STABLE and NetBSD
        4.99.70, between NetBSD 4.0_STABLE and OpenBSD 4.3, and between
        NetBSD 4.0_STABLE and FreeBSD 7.0.  Also, I tried recompiling
        the kernel with `options GATEWAY' and setting the sysctl
        `net.inet.ip.forwarding' to 1, doubting whether these would
        have any effect.  None of these pairs or configurations worked.
        By contrast, I was able to successfully create tun(4) tunnels
        with ssh between OpenBSD 4.3 and FreeBSD 7.0.
        
        (My 4.0_STABLE kernel is currently configured as in XEN3_DOM0
        from netbsd-4, with cgd(4), VND_COMPRESSION, FFS_EI, and
        APPLE_UFS enabled.  My 4.99.70 kernel is currently configured
        as in XEN3_DOMU from -current (as of last week) with the same
        options enabled, and also putter(4) & PUFFS.  I can't imagine
        that any of these would affect tunnels, and I also initially
        tried the tunnels without any of these options set, but didn't
        get around to submitting a PR until now.)

>How-To-Repeat:

        In the local machine's sshd_config, set PermitTunnels to yes.
        In the remote machine's sshd_config, set PermitTunnels and
        PermitRootLogin to yes.  As root, ssh to root at the remote
        machine with
        
          local# ssh -w 0:1 <remote hostname>
        
        Then
        
          local# ifconfig tun0 10.0.2.2 10.0.2.1 netmask 0xffffff00
          remote# ifconfig tun1 10.0.2.1 10.0.2.2 netmask 0xffffff00
        
        Check the interface configurations:
        
          local# ifconfig tun0
          tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500
                  inet 10.0.2.2 -> 10.0.2.1 netmask 0xffffff00
        
        [Remote machine running OpenBSD]
          remote# ifconfig tun1
          tun1: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500
                  groups: tun
                  inet 10.0.2.1 --> 10.0.2.2 netmask 0xffffff00
        
        Check that the routes are correct:
        
          local# route get 10.0.2.1
             route to: 10.0.2.1
          destination: 10.0.2.1
           local addr: 10.0.2.2
            interface: tun0
                flags: <UP,HOST,DONE>
           recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu  
   expire
                 0         0         0         0         0         0         0  
       0 
        
          remote# route get 10.0.2.2
             route to: 10.0.2.2
          destination: 10.0.2.2
            interface: tun1
           if address: 10.0.2.1
                flags: <UP,HOST,DONE>
               use  hopcount       mtu    expire
                 0         0         0         0 
        
        Then watch no pings, or packets of any sort, get through.

>Fix:

        I haven't yet been able to test changes or debug this
        thoroughly, and sha'n't be able to until I figure out the
        NetBSD build system well enough to build locally modified
        OpenSSH subtrees.