UDPv6 support (UDP/IPv6)

Hi ppl ...
As part of my master thesis _and_ community giveback y added UPDv6 support to openvpn-2.0_beta11, its working AFAITested, see attached README.IPv6 for details.

Output from my uoooooHAaaaAAA!! session:
"""

  [email protected]... openvpn-2.0_beta11-jjo # ./openvpn  --dev tun --proto udp6 \
		--remote fe80::240:5ff:feae:c851 --port 5010 --secret ../openvpn.key \
		--ifconfig 1.1.1.253 1.1.1.1

Tue Sep 21 17:30:39 2004 OpenVPN 2.0_beta11 i686-pc-linux [SSL] [LZO] [EPOLL] built on Sep 21 2004 Tue Sep 21 17:30:39 2004 TUN/TAP device tun0 opened
Tue Sep 21 17:30:39 2004 /sbin/ifconfig tun0 1.1.1.253 pointopoint 1.1.1.1
mtu 1500
Tue Sep 21 17:30:39 2004 UDPv6 link local (bound): [AF_INET6]:::5010
Tue Sep 21 17:30:39 2004 UDPv6 link remote: [AF_INET6]fe80::240:5ff:feae:c851:5010
Tue Sep 21 17:30:49 2004 Peer Connection Initiated with [AF_INET6]fe80::240:5ff:feae:c851%wlan0wds0:5000 Tue Sep 21 17:30:51 2004 Initialization Sequence Completed

:

[email protected]... jjo $ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=16.5 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=5.92 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 5.928/11.258/16.588/5.330 ms
"""

BTW ... I've broke some basic indentation rules in order to avoid enlarging diff size.

Patch attached, also available (GPL) under
http://www.irrigacion.gov.ar/juanjo/ipsec/

Best regards...

--
--Juanjo

PS: Sorry for not signing this message, I've broken my mutt setup recently,
you'll find signed MD5SUM @URL above..

# Juan Jose Ciarlante (JuanJo) jjo ;at; mendoza.gov.ar #
# GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key 66727177 #
# Key fingerprint: 0D2F 3E5D 8B5C 729E 0560 F453 A3F7 E249 6672 7177 #

# $Id: README.IPv6,v 1.1.2.5 2004/09/24 04:53:59 jjo Exp $ #

This README covers UDP/IPv6 ( --udp6 ) support for openvpn-2.0_beta11 Also, with address family "generalization" changes came local AF_UNIX socket support.

Available under GPLv2 from
http://www.irrigacion.gov.ar/juanjo/openvpn/

See "Examples" section below for usage.

* Working:
- upd6->upd6 (AF_INET6)
- upd4->upd6 bound (show correctly mapped address) but requires --float (to be fixed soon)
- unix-dgram->unix-dgram (AF_UNIX)
useful for implementing local proxies that can take full advantage of POSIX filesystem permissions ( more powerfull access mechanisms than inet, even for localhost)

* Examples: some succesfully tested command lines
BTW did you know that openvpn can succesfully negotiate to self with --remote localhost ? (VERY useful for fast testing)

- IPv6 "normal" usage (+succesfully tested tunnel traffic)

    server# openvpn --proto udp6 ...
      :
      Thu Sep 23 22:15:48 2004 Peer Connection Initiated with [AF_INET6]fe80::205:5dff:fef1:1ceb%wlan0wds1:5000
      :
    client# openvpn --proto udp6 --remote fe80::240:5ff:feae:c851 ...
      :
      Thu Sep 23 22:13:19 2004 Peer Connection Initiated with [AF_INET6]fe80::240:5ff:feae:c851%wlan0wds0:5000
      :

- IPv6 server, IPv4 client (more detailed)

    server# openvpn --proto udp6 ...
      :
      Thu Sep 23 22:28:36 2004 UDPv6 link local (bound): [AF_INET6][undef]:5000
      Thu Sep 23 22:28:36 2004 UDPv6 link remote: [AF_INET6][undef]
      Thu Sep 23 22:28:50 2004 Peer Connection Initiated with [AF_INET6]::ffff:10.55.14.253:5000
      Thu Sep 23 22:28:51 2004 Initialization Sequence Completed
      Thu Sep 23 22:28:56 2004 WARNING: Actual Remote Options ('... proto UDPv4 ... ') \
                               are inconsistent with Expected Remote Options ('... proto UDPv6 ...')

    client# openvpn  --remote 10.55.14.254 ...  ### same default as now: --udp
      :
      Thu Sep 23 22:26:11 2004 UDPv4 link local (bound): [AF_INET][undef]:5000
      Thu Sep 23 22:26:11 2004 UDPv4 link remote: [AF_INET]10.55.14.254:5000
      Thu Sep 23 22:26:21 2004 Peer Connection Initiated with [AF_INET]10.55.14.254:5000
      Thu Sep 23 22:26:21 2004 WARNING: Actual Remote Options ('... proto UDPv6 ...') \
                               are inconsistent with Expected Remote Options ('... proto UDPv4 ...')
      Thu Sep 23 22:26:22 2004 Initialization Sequence Completed

- IPv6 loopback

    alone# openvpn --proto udp6 --remote ::1 ...
      :
      Wed Sep 22 13:03:07 2004 Peer Connection Initiated with [AF_INET6]::1:5000
      :

- AF_UNIX toself

    alone# openvpn --proto unix-dgram --local /tmp/o.s --remote /tmp/o.s --dev tun  ...
      :
      Thu Sep 23 16:37:27 2004 Peer Connection Initiated with [AF_UNIX]/tmp/o.s
      :

- AF_UNIX between to diff instances

    peer1# openvpn --proto unix-dgram --local /tmp/o1.s --remote /tmp/o2.s
    peer2# openvpn --proto unix-dgram --local /tmp/o2.s --remote /tmp/o1.s
      :
      Wed Sep 22 12:49:03 2004 Peer Connection Initiated with [AF_UNIX]/tmp/o1.s
      :

* Main code changes summary:
- New sockaddr type (could have been sockaddr_storage but

    it lacks simple type overloading and maybe portability)
    union sockaddr_ovpn {
    	struct sockaddr addr;
    	struct sockaddr_in in;
    	struct sockaddr_in6 in6;
    #ifdef HAVE_SYS_UN_H
    	struct sockaddr_un un;
    #endif
    };
    
    typedef union sockaddr_ovpn sockaddr_ovpn_t;
    struct link_socket_addr
    {
    	sockaddr_ovpn_t local;
    	sockaddr_ovpn_t remote;
    	sockaddr_ovpn_t actual;
    };
    
    ... leads to simple type overloading: local.addr
    local.in, local.in6 ... etc

- several function prototypes moved from
sockaddr_in to sockaddr args type
- several new sockaddr functions:

    addr_copy(), addr_zero(), ...etc
    proto_is_udp(), proto_is_dgram(), proto_is_net()

* TODO:
- call socket() lately, after getaddrinfo() to decide IPv4 or IPv6 host (hence socket()) instead of needing -p {udp|udp6}
Not actually a big trouble, given that you _do_ setup both sides (keys, certs, etc), using udp or udp6 is actually another setup bit.
- Implement comparison for mapped addesses: server in dual stack listening IPv6 must permit incoming streams from allowed IPv4 peer (ie without --float).
- IPv6 with actual host resolution, currently only numerical (AI_NUMERICHOST)
- integrate both IPv4 and IPv6 addr resolution with getaddrinfo instead of venerable gethostbyname&friends, problem: portability across platforms, across libc versions? (dunno).

--
JuanJo Ciarlante jjo|at|mendoza.gov.ar
: :
. Linux IP Aliasing author .
. Modular algo (AES et all) support for FreeSWAN/OpenSWAN author .
:... plus other scattered free software bits in the wild ...:

Is there a use for AF_UNIX in a VPN driver?

Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

It stated in README file.. it allows the creation of local specialized proxys that can take full advantage of POSIX fileystem perm. semantics.

Currently I;'m working on a Jabber one 8))
regards...

--Juanjo

#  Juan Jose Ciarlante (JuanJo) jjo ;at; mendoza.gov.ar                     #
#  GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key 66727177 #
#   Key fingerprint: 0D2F 3E5D 8B5C 729E 0560  F453 A3F7 E249 6672 7177     #

As a clarification, AF_UNIX gets autoconf'd on sys/un.h presence (every AF_UNIX src section is #ifdef'd HAVE_SYS_UN_H) , but I'll make it selectable at configure time.

For IPV6 code, I followed Itojun's guidelines (RFC) , it _should_ compile and work on all platforms [last famous words]; I'll truly appreciacte feedback on this .

Regards...

--Juanjo

#  Juan Jose Ciarlante (JuanJo) jjo ;at; mendoza.gov.ar                     #
#  GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key 66727177 #
#   Key fingerprint: 0D2F 3E5D 8B5C 729E 0560  F453 A3F7 E249 6672 7177     #

Juanjo,

Great work on the IPv6 support! I see there are still a few TODO items, and of course the OpenVPN project itself is in the transition zone between the end of the 2.0 beta series and the start of 2.0 release candidates, so I think it would make sense to hold off on merging your contribution until after 2.0 final is released.

James

I must say that the thought of running a VPN over Jabber is deliciously subversive :)

But I cringe when I think of the potential complexification in the sockets code.

We are already moving in the direction of having lots of transport layer options (i.e. TCP, UDP, IPv4, IPv6, HTTP, Socks). Now we're talking about local unix sockets and Jabber! Maybe it's time to formally codify a transport layer driver model, i.e. a pluggable architecture. Then people can add new drivers to their heart's content, while OpenVPN itself will conveniently interact with a generalized abstraction of the model.

James

Thanks, Jim ...

Indeed, some of them may require code flow changes, mainly because of:
DNS may return A or AAAA records, iff we _require_ to specify --udp|--udp6 (which I think is wise given you DO know/coordinate you r peer's setup), these "ambiguities" disappear.

Agreed.

I've finished ./configure [ --disable-ipv6] [ --enable-unix-sockets ]; tested compilation for the 4 combinations, and testbed runs too. Expect new patch for tomorrow

Regards..

--Juanjo

#  Juan Jose Ciarlante (JuanJo) jjo ;at; mendoza.gov.ar                     #
#  GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key 66727177 #
#   Key fingerprint: 0D2F 3E5D 8B5C 729E 0560  F453 A3F7 E249 6672 7177     #

yeahhh

Totally agreed, in fact my 1st thought was to try to abstract proxys code paths, but I left for new now the of the impact.

My patch has a lot of work in this direction (functions like proto_is_dgram... addr_copy, etc ); you know my first approach was to thinks AF_UNIX as http/socks, but later I concluded that if we DONT require openvpn to specify destination to the proxy entity its not a proxy, its a (tunneled) pee; in the JAbber case , this could be an _already_ connected, _already_ configured destination JID not even known to openvpn, ... for openvpn its just another channel (socket).

Indeed , AF_INET , AF_INET6 and AF_UNIX are mostly "siblings" from the connection pointo of view.

Count on me for that ... hope I can resist the temptation 8)))

Regards

--Juanjo

#  Juan Jose Ciarlante (JuanJo) jjo ;at; mendoza.gov.ar                     #
#  GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key 66727177 #
#   Key fingerprint: 0D2F 3E5D 8B5C 729E 0560  F453 A3F7 E249 6672 7177     #

Done.

CHANGES.IPv6 excerpt:

* v0.2.2
- IPv6, unix-socket support selectable at configure-time (all 4 combinations tested)

    ./configure --disable-ipv6        (enabled by default)
    ./configure --enable-unix-sockets (disabled by default)
    (internal) USE_PF_INET6, USE_PF_UNIX from autoconf

- Change PROTO_x from #define to enum, to allow easier/cleanersupport for optional protocols
- Added IPV6_xxxx_HEADER_SIZE

Available (GPL) at
http://www.irrigacion.gov.ar/juanjo/openvpn/

Regards ..

--
--Juanjo

# Juan Jose Ciarlante (JuanJo) jjo ;at; mendoza.gov.ar #
# GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key 66727177 #
# Key fingerprint: 0D2F 3E5D 8B5C 729E 0560 F453 A3F7 E249 6672 7177 #

Hello all

In the file openvpn.nsi.in version 1.2.2.9, This is the most recent file in CVS
http://cvs.sourceforge.net/viewcvs.py/openvpn/openvpn/install-win32/openvpn.nsi.in?rev=1.2.2.9&view=markup
I found a bug, When you reinstall the same version openvpn the old tap driver isn't removed and you endup with 2 tap drivers installed and openvpn doesn't work. To fix it, just change the following in the nsi file:

At line 348 it says:
nsExec::ExecToLog '"$INSTDIR\bin\tapinstall.exe" remove TAP' But is must be
nsExec::ExecToLog '"$INSTDIR\bin\tapinstall.exe" remove ${TAP}'

At line 351 it says:
nsExec::ExecToLog '"$INSTDIR\bin\tapinstall.exe" remove TAPDEV' This must be
nsExec::ExecToLog '"$INSTDIR\bin\tapinstall.exe" remove ${TAPDRV}'

at line 353 TAPDEV must also be replaced bij ${TAPDRV}

I'm not shore how or if i'm able to change this in CVS, can one of you do this? Thnx

Grtz,Remco

Are you sure?

The TAP and TAPDEV strings are the actual names of previous TAP-Win32 hardware IDs which we want to delete before installing the new TAP-Win32 driver.

For example in OpenVPN 1.x, the hwid is "TAP". If we change the NSIS code to ${TAP}, now it will expand to "tap0801" which is the hwid for 2.0. So we won't be deleting the old instance any longer, which is what this code is supposed to be doing.

James

Hello James

Ok then I didn't read/understand the code correctly. Sorry for the mistake.

Grtz,Remco