1OpenVPN 2Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net> 3 4 OpenVPN has been written to try to avoid features 5 that are not standardized well across different 6 OSes, so porting OpenVPN itself will probably be 7 straightforward if a tun or tap driver already exists. 8 9 Where special OS features are used, they are usually 10 bracketed with #ifdef HAVE_SOME_FUNCTION. 11 12PLATFORM STATUS: 13 14 * Linux 2.2+ (supported) 15 * Solaris (supported) 16 * OpenBSD 3.0 (supported but pthreads are broken) 17 * Max OS X Darwin 18 * FreeBSD 19 * NetBSD 20 * Windows 21 * 64 bit platforms -- I have heard reports that 22 OpenVPN runs on Alpha Linux and FreeBSD. 23 * ARM -- I have heard of at least one case 24 where OpenVPN was successfully built and 25 run on the ARM architecture. 26 27PORTING NOTES: 28 29 * Make sure that OpenSSL will build on your 30 platform. 31 * Make sure that a tun or tap virtual device 32 driver exists for your platform. See 33 http://vtun.sourceforge.net/tun/ for examples 34 of tun and tap drivers that have been written 35 for Linux, Solaris, and FreeBSD. 36 * Make sure you have autoconf 2.50+ and 37 automake 1.6+. 38 * Edit configure.ac, adding platform specific 39 config code, and a TARGET_YOUROS define. 40 * Add platform-specific includes to syshead.h. 41 * Add an #ifdef TARGET_YOUROS to the do_ifconfig() 42 function in tun.c to generate a correct "ifconfig" 43 command for your platform. Note that OpenVPN 44 determines the ifconfig path at ./configure time. 45 * Add an ifconfig_order() variant for your OS so 46 openvpn knows whether to call ifconfig before 47 or after tun/tap dev open. 48 * Add an #ifdef TARGET_YOUROS block in tun.c and define 49 the open_tun, close_tun, read_tun, and write_tun 50 functions. If your tun/tap virtual device is 51 sufficiently generic, you may be able to use the 52 default case. 53 * Add appropriate code to route.c to handle 54 the route command on your platform. This 55 is necessary for the --route option to 56 work correctly. 57 * After you successfully build OpenVPN, run 58 the loopback tests as described in INSTALL. 59 * For the next test, confirm that the UDP socket 60 functionality is working independently of the 61 tun device, by doing something like: 62 ./openvpn --remote localhost --verb 9 --ping 1 --dev null 63 * Now try with --remote [a real host] 64 * Now try with a real tun/tap device, you will 65 need to figure out the appropriate ifconfig 66 command to use once openvpn has opened the tun/tap 67 device. 68 * Once you have simple tests working on the tun device, 69 try more complex tests such as using TLS mode. 70 * Stress test the link by doing ping -f across it. 71 * Make sure that packet fragmenting is happening 72 correctly by doing a ping -s 2000 or higher. 73 * Ensure that OpenVPN on your platform will talk 74 to OpenVPN on other platforms such as Linux. 75 Some tun/tap driver implementations will prepend 76 unnecessary stuff onto the datagram that must be 77 disabled with an explicit ioctl call if cross-platform 78 compatibility is to be preserved. You can see some 79 examples of this in tun.c. 80 * If your system supports pthreads, try building 81 with ./configure --enable-pthread and do a stress 82 test in TLS mode. 83 * Try the ultimate stress test which is --gremlin 84 --reneg-sec 10 in TLS mode (preferably with pthreads 85 enabled), then do a flood ping across the tunnel 86 (ping -f remote-endpoint) in both directions and let 87 it run overnight. --gremlin will induce massive 88 corruption and packet loss, but you win if you 89 wake up the next morning and both peers are still 90 running and occasionally even succeeding in their 91 attempted once-per-10-seconds TLS handshake. 92 * When it's working, submit your patch to 93 <openvpn-devel@lists.sourceforge.net> 94 and rejoice :) 95