mirror of
https://github.com/openbsd/ports.git
synced 2026-06-18 07:24:23 +02:00
jca
61cc31416e
Hardcoding --daemon is necessary so that openvpn goes into the background by default, whatever the admin sets in openvpn_flags or their config file. So document how to pass an optional argument to --daemon, which is mainly useful when you're running multiple instances (eg IPv4 vs IPv6 and/or UDP vs TCP). Since there's another ambiguity in the cli arguments parsing, explicitely tell users to use --config before the config file. Setting only "openvpn_flags=/config/file" in rc.conf.local cannot work because the file name would be misinterpreted as the optional argument to --daemon. Ambiguity pointed out by and argued with kn@ who proposed a different approach. "I think that's fine" sthen@
101 lines
3.4 KiB
Plaintext
101 lines
3.4 KiB
Plaintext
+-----------------------------------------------------------------------
|
|
| Running ${PKGSTEM} on OpenBSD
|
|
+-----------------------------------------------------------------------
|
|
|
|
Compatibility with older OpenVPN releases
|
|
-----------------------------------------
|
|
OpenVPN 2.6 has compression disabled by default and may need
|
|
'--allow-compression asym' to work against a server which has
|
|
compression enabled.
|
|
|
|
Using the openvpn rc script
|
|
---------------------------
|
|
|
|
# rcctl enable openvpn
|
|
# rcctl set openvpn flags '--config /etc/openvpn/server.conf'
|
|
|
|
To avoid ambiguity in options handling, always explicitly
|
|
specify --config before the path to your configuration file.
|
|
|
|
To handle multiple openvpn instances see EXAMPLES in rcctl(8).
|
|
|
|
The openvpn rc script always passes --daemon before the user-selectable
|
|
flags. This breaks the effets of 'daemon <custom-progname>' in
|
|
configuration files. To work around this, you can pass an optional
|
|
<custom-progname> at the start of the user-selectable flags:
|
|
|
|
# rcctl set openvpn flags 'openvpn-custom --config /etc/openvpn/custom.conf'
|
|
|
|
Using an /etc/hostname.* file without persist-tun
|
|
-------------------------------------------------
|
|
OpenVPN normally re-creates the tun/tap interface at startup.
|
|
This has been reported to cause problems with some PF configurations
|
|
(especially with queueing), if you run into problems with this then
|
|
OpenVPN should be started from the hostname.* file, e.g.:
|
|
|
|
# cat << EOF > /etc/hostname.tun0
|
|
up
|
|
!LD_LIBRARY_PATH=${LOCALBASE}/lib:/usr/lib ${TRUEPREFIX}/sbin/openvpn \
|
|
--daemon --config ${SYSCONFDIR}/openvpn/server.conf
|
|
EOF
|
|
|
|
(Or use hostname.tap0 for a layer-2 connection).
|
|
|
|
Using an /etc/hostname.* file with persist-tun
|
|
----------------------------------------------
|
|
When the persist-tun option is used, the tun(4) or tap(4) interface can
|
|
be configured before OpenVPN is started, just like any other interface.
|
|
|
|
The example below configures a point-to-point link between two sites
|
|
accross an OpenVPN tunnel. Site-1 has tunnel end point 10.1.1.1 and
|
|
local network 192.168.0.0/24. Site-2 has tunnel end point 10.1.1.2
|
|
and local network 192.168.1.1/24. The sites connect their local
|
|
networks via the tunnel.
|
|
|
|
Site-1:
|
|
# cat << EOF > /etc/hostname.tun0
|
|
inet 10.1.1.1 255.255.255.255 NONE
|
|
dest 10.1.1.2
|
|
!/sbin/route add -host 10.1.1.1 127.0.0.1
|
|
!/sbin/route add -net 192.168.1.1/24 10.1.1.2
|
|
EOF
|
|
|
|
Site-2:
|
|
# cat << EOF > /etc/hostname.tun0
|
|
inet 10.1.1.2 255.255.255.255 NONE
|
|
dest 10.1.1.1
|
|
!/sbin/route add -host 10.1.1.2 127.0.0.1
|
|
!/sbin/route add -net 192.168.0.0/24 10.1.1.1
|
|
EOF
|
|
|
|
In this case, there is no need to configure an IP address on the tun
|
|
interface from the OpenVPN configuration file. The tun interface will
|
|
become active when OpenVPN starts using it.
|
|
|
|
A suitable OpenVPN configuration file for site-1 might look as follows:
|
|
|
|
daemon
|
|
dev tun0
|
|
persist-tun
|
|
proto udp
|
|
local site-1.example.com
|
|
remote site-2.example.com
|
|
secret /etc/openvpn/secret.key
|
|
ping 10
|
|
ping-restart 60
|
|
|
|
Running OpenVPN in chroot
|
|
-------------------------
|
|
OpenVPN can run as an unprivileged user inside chroot when the
|
|
persist-tun, persist-key, and persist-local-ip options are used.
|
|
Note that persist-local-ip requires that OpenVPN is listening on an
|
|
interface with a static IP address. To chroot OpenVPN, use the following
|
|
as part of your configuration file:
|
|
|
|
persist-tun
|
|
persist-key
|
|
persist-local-ip
|
|
user _openvpn
|
|
group _openvpn
|
|
chroot /var/empty
|