OpenVPN
Copyright (C) 2002-2023 OpenVPN Inc <sales@openvpn.net>
OpenVPN has been written to try to avoid features
that are not standardized well across different
OSes, so porting OpenVPN itself will probably be
straightforward if a tun or tap driver already exists.
Where special OS features are used, they are usually
bracketed with #ifdef HAVE_SOME_FUNCTION.
PLATFORM STATUS:
Tier 1 platforms - actively tested for every source commit, across
multiple operating system versions
* Windows 7 and newer
* Windows Server 2012 and newer
* Linux
* FreeBSD
* macOS
Tier 2 platforms - it worked at some point, but is not actively tested
on "latest OS, latest OS libraries" so might break if larger changes
are done on the platform side
* OpenBSD
* NetBSD
* DragonFly BSD
* Solaris
* AIX
For underlying CPU architecture, everything 32 bit or 64 bit (Intel, AMD,
ARM, PowerPC, SPARC*) should work fine. 16 bit Architectures are unlikely
to work.
PORTING GUIDELINE TO A NEW PLATFORM:
* Make sure that OpenSSL will build on your
platform.
* Make sure that a tun or tap virtual device
driver exists for your platform. See
http://vtun.sourceforge.net/tun/ for examples
of tun and tap drivers that have been written
for Linux, Solaris, and FreeBSD.
* Make sure you have autoconf 2.50+ and
automake 1.6+.
* Edit configure.ac, adding platform specific
config code, and a TARGET_YOUROS define.
* Add platform-specific includes to syshead.h.
* Add an #ifdef TARGET_YOUROS to the do_ifconfig()
function in tun.c to generate a correct "ifconfig"
command for your platform. Note that OpenVPN
determines the ifconfig path at ./configure time.
* Possibly add an ifconfig_order() variant for your OS so
openvpn knows whether to call ifconfig before
or after tun/tap dev open.
* Add an #ifdef TARGET_YOUROS block in tun.c and define
the open_tun, close_tun, read_tun, and write_tun
functions. If your tun/tap virtual device is
sufficiently generic, you may be able to use the
default case.
* Add appropriate code to route.c to handle
the route command on your platform. This
is necessary for the --route option to
work correctly.
* After you successfully build OpenVPN, run
the loopback tests as described in INSTALL.
* For the next test, confirm that the UDP socket
functionality is working independently of the
tun device, by doing something like:
./openvpn --remote localhost --verb 9 --ping 1 --dev null
* Now try with --remote [a real host]
* Now try with a real tun/tap device, you will
need to figure out the appropriate ifconfig
command to use once openvpn has opened the tun/tap
device.
* Once you have simple tests working on the tun device,
try more complex tests such as using TLS mode.
* Stress test the link by doing ping -f across it.
* Make sure that packet fragmenting is happening
correctly by doing a ping -s 2000 or higher.
* Ensure that OpenVPN on your platform will talk
to OpenVPN on other platforms such as Linux.
Some tun/tap driver implementations will prepend
unnecessary stuff onto the datagram that must be
disabled with an explicit ioctl call if cross-platform
compatibility is to be preserved. You can see some
examples of this in tun.c.
* Try the ultimate stress test which is --gremlin --reneg-sec 10
in TLS mode then do a flood ping across the tunnel
(ping -f remote-endpoint) in both directions and let
it run overnight. --gremlin will induce massive
corruption and packet loss, but you win if you
wake up the next morning and both peers are still
running and occasionally even succeeding in their
attempted once-per-10-seconds TLS handshake.
* When it's working, submit your patch to
<openvpn-devel@lists.sourceforge.net>
and rejoice :)
Mini Shell