1OpenVPN
2Copyright (C) 2002-2022 OpenVPN 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