= Setup notes for the OpenVPN SMF service integration
== Multiple-instance support
To create additional SMF instances for additional OpenVPN configuration
files, run the following commands (as the `root` or a user with the RBAC
privileges needed to do this setup):
----
:; VPNCFG=mywork-client
:; pfexec svccfg -s openvpn add $VPNCFG
:; pfexec svcadm refresh openvpn:$VPNCFG
----
NOTE: The service template assumes all system-level connection config files
(and additional files they might pull by relative paths) are all located
under `/etc/openvpn/` directory as `$VPNCFG.conf`; initial logging is set up
to write into `/var/log/openvpn/$VPNCFG/log` by default, and then the location
may be specified by the `config_file` contents. In any case, make sure the
specified location exists and is writable by the service user account.
If you want the tunnel just occasionally (not up by default every time you
boot), do not forget to run it as a temporarily-enabled service (also this
requires less RBAC privileges needed to the user account that would start
or stop the tunnel service):
----
:; pfexec svcadm enable -ts openvpn:$VPNCFG
----
Inspect the results with:
----
:; svcs -p openvpn:$VPNCFG
:; tail -f /var/svc/log/*openvpn:$VPNCFG.log &
----
== Firewall considerations
In order for tunneled traffic to actually pass, you may have to allow it in
your (custom) IPFilter config, usually `/etc/ipf/ipf.conf`, by preemptively
adding lines like these (scale by the amount of TUN and/or TAP tunnels you
expect active at the same time), e.g.:
----
pass in quick on tun0
pass out quick on tun0
pass in quick on tun1
pass out quick on tun1
pass in quick on tun2
pass out quick on tun2
pass in quick on tun3
pass out quick on tun3
pass in quick on tap0
pass out quick on tap0
pass in quick on tap1
pass out quick on tap1
pass in quick on tap2
pass out quick on tap2
pass in quick on tap3
pass out quick on tap3
----
...and restarting the service:
----
:; pfexec svcadm restart ipfilter
----
If the remote OpenVPN server for your client is on some non-standard ports,
or if your local OpenVPN server instance listens on some non-standard ports,
and your firewall config is strict, you might have to allow that traffic in
the firewall rulesets too.
Alternately you might research and use scripting hooks in openvpn config files.
== OpenVPN in local zones
You can run an openvpn router in a local zone with exclusive IP stack, using
the tun/tap device drivers (kernel modules) installed in the global zone and
passed into the local zone.
This may require some additional privileges and setup steps for that zone;
if it does not work "out of the box" for you, try changing the zone manifest
according to:
----
...
----
== Special privileges for the OpenVPN daemon
You might also want to enable some permissions in the service manifest below,
or per-instance, for example if you want one to listen on privileged ports, or
to `chroot()` the daemon, or to use configuration files and device nodes owned
by another user. Remember that under SMF a `root` is not always almighty!
Specific use-cases will require different privilege sets, but all or most of
the list below had been useful in different non-triial deployments:
----
----
Have fun running your copy of OpenVPN on OpenIndiana!