Here are some suggestions to improve the official documentation for OpenVPN on TrueNAS 12. I would also like to suggest some improvements to the user interface.
1. OpenVPN Server
- If you want to allow connections to your OpenVPN Server from the Internet or accross the Internet, you will need to allow traffic through your Internet gateway/router. Port forwarding of the OpenVPN protocol (UDP port 1194 by default, although the port and protocol can be changed in TrueNAS) to the TrueNAS server is required when a NAT is present. Clients will need an FQDN associated with your Internet gateway. This may be setup using DDNS.
- An OpenVPN server will need both a CA certificate and a OpenVPN server certificate signed by the CA certificate or intermediate certificates that are in turn based on the CA certificate. TrueNAS can generate CA certificates and OpenVPN server certificates. When generating certificates, OpenVPN Profiles can be selected to fill in some of the certificate fields correctly. When generating certificates, the 'Common Name' needs to be filled in (even though it is not marked as a required field)? The common name can be descriptive text (e.g. 'TrueNAS OpenVPN CA' and 'TrueNAS OpenVPN Server'). The 'Subject Alternate Names' field must contain one or more FQDNs (not IP addresses). The content of the CA certificate Subject Alternate Name is not important, but can be set to your domain name (e.g. example.com). The OpenVPN server certificate Subject Alternate Names field needs to contain all of the FQDNs by which clients will connect to the OpenVPN server (e.g. truenas.example.com (an alias for the TrueNAS server as seen on the Internet), example.com (the name of the Internet gateway into your network with OpenVPN port forwarded to your TrueNAS OpenVPN server) and truenas.local (The name of your TrueNAS server for users connecting from inside your private network)).
- Set a reminder in your diary before the expiry dates of your certificates. You will need to generate new certificates before these expire for OpenVPN to continue to operate correctly.
- The 'OpenVPN Server' 'Server' field and help is misleading. In particular if the server 'Topology' is set to SUBNET, the 'Server' field should be set to the base address of a private subnet that does not currently exist, either in your TrueNAS server network, or the networks of any of the clients connecting to your server. This is really important or routing between the server and clients will not work! For example if your TrueNAS server is on a 10.1.0.0/24 network and clients are connecting from various 192.168.#.0/24 networks, then select an otherwise unused subnet for the OpenVPN server to communicate with all of its clients (e.g. 10.254.0.0/24). I think the name of this field and help need to be improved.
- Enable 'TLS Crypt Auth Enabled' and click on the RENEW STATIC KEY button once before deploying any clients, if you know that all clients support this option. This option increases security by forcing the initial client to server negotiation to be encrypted with this static key, thus stopping opertunistic connections from unknown sources. Once this key is set, all clients will need to be reconfigured with updated configuration if the static key is changed. A warning to this effect needs to explain what to do if the key is changed.
- The DOWNLOAD CLIENT CONFIG button does not produce valid client configuration. The remote line in the configuration (e.g. remote "10.1.0.100") needs to be edited to the FQDN of the OpenVPN server as seen by the client, so that it can match an OpenVPN server certificate Subject Alternative Name. When the button is pressed, TrueNAS should ask for the user certificate and also provide a list of FQDNs from the OpenVPN server certificate Subnect Alternative Names so that the configuration can be generated correctly automatically.
Additional Parameters
- If you want traffic to be allowed from one client to another then add 'client-to-client' to the 'Additional Parameters' settings. This would be good to include as a checkbox.
- If you want clients to be able to access the whole of the network on which the TrueNAS server resides then 3 components need to be added:
2. OpenVPN Clients
OpenVPN clients can be configured to connect to a TrueNAS OpenVPN server using the (currently modified) client configuration downloaded from the server. However, for TrueNAS OpenVPN clients, the configuration needs to be imported manually.
Additional Parameters
- If you want other computers in the client's network to be able to access the OpenVPN server or OpenVPN server network further configuration is needed:
Troubleshooting
- If clients can ping the OpenVPN server but not the other way around, until a client starts pinging the server, then it is possible that a NAT between the client and server is closing the pinhole too quickly. Try adding 'keepalive 10 60' to the 'Additional Parameters' OpenVPN server settings to force clients to send keepalive messages to the server every 10 seconds with a timeout of 60 seconds. A keepalive option with explaination might be good to add to the settings page.
1. OpenVPN Server
- If you want to allow connections to your OpenVPN Server from the Internet or accross the Internet, you will need to allow traffic through your Internet gateway/router. Port forwarding of the OpenVPN protocol (UDP port 1194 by default, although the port and protocol can be changed in TrueNAS) to the TrueNAS server is required when a NAT is present. Clients will need an FQDN associated with your Internet gateway. This may be setup using DDNS.
- An OpenVPN server will need both a CA certificate and a OpenVPN server certificate signed by the CA certificate or intermediate certificates that are in turn based on the CA certificate. TrueNAS can generate CA certificates and OpenVPN server certificates. When generating certificates, OpenVPN Profiles can be selected to fill in some of the certificate fields correctly. When generating certificates, the 'Common Name' needs to be filled in (even though it is not marked as a required field)? The common name can be descriptive text (e.g. 'TrueNAS OpenVPN CA' and 'TrueNAS OpenVPN Server'). The 'Subject Alternate Names' field must contain one or more FQDNs (not IP addresses). The content of the CA certificate Subject Alternate Name is not important, but can be set to your domain name (e.g. example.com). The OpenVPN server certificate Subject Alternate Names field needs to contain all of the FQDNs by which clients will connect to the OpenVPN server (e.g. truenas.example.com (an alias for the TrueNAS server as seen on the Internet), example.com (the name of the Internet gateway into your network with OpenVPN port forwarded to your TrueNAS OpenVPN server) and truenas.local (The name of your TrueNAS server for users connecting from inside your private network)).
- Set a reminder in your diary before the expiry dates of your certificates. You will need to generate new certificates before these expire for OpenVPN to continue to operate correctly.
- The 'OpenVPN Server' 'Server' field and help is misleading. In particular if the server 'Topology' is set to SUBNET, the 'Server' field should be set to the base address of a private subnet that does not currently exist, either in your TrueNAS server network, or the networks of any of the clients connecting to your server. This is really important or routing between the server and clients will not work! For example if your TrueNAS server is on a 10.1.0.0/24 network and clients are connecting from various 192.168.#.0/24 networks, then select an otherwise unused subnet for the OpenVPN server to communicate with all of its clients (e.g. 10.254.0.0/24). I think the name of this field and help need to be improved.
- Enable 'TLS Crypt Auth Enabled' and click on the RENEW STATIC KEY button once before deploying any clients, if you know that all clients support this option. This option increases security by forcing the initial client to server negotiation to be encrypted with this static key, thus stopping opertunistic connections from unknown sources. Once this key is set, all clients will need to be reconfigured with updated configuration if the static key is changed. A warning to this effect needs to explain what to do if the key is changed.
- The DOWNLOAD CLIENT CONFIG button does not produce valid client configuration. The remote line in the configuration (e.g. remote "10.1.0.100") needs to be edited to the FQDN of the OpenVPN server as seen by the client, so that it can match an OpenVPN server certificate Subject Alternative Name. When the button is pressed, TrueNAS should ask for the user certificate and also provide a list of FQDNs from the OpenVPN server certificate Subnect Alternative Names so that the configuration can be generated correctly automatically.
Additional Parameters
- If you want traffic to be allowed from one client to another then add 'client-to-client' to the 'Additional Parameters' settings. This would be good to include as a checkbox.
- If you want clients to be able to access the whole of the network on which the TrueNAS server resides then 3 components need to be added:
- The TrueNAS server needs to allow routing between its OpenVPN subnet and its main interface subnet. Add a 'Tunables' RC setting of gateway_enable=YES.
- Add a push route to the TrueNAS server subnet (e.g. push "route 10.1.0.0 255.255.255.0") to the 'Additional Parameters' settings.
- The default gateway router for the TrueNAS subnet needs to be told where to send traffic back to the OpenVPN subnet. This is usually done by adding a static route to the router of the subnet for the TrueNAS server (e.g. 10.254.0.0/24 -> 10.1.0.100). Alternatively, other individual machines on the same subnet as the TrueNAS server that want to communicate with OpenVPN clients could add this static route to their configuration.
It might be nice to have a checkbox to add the first 2 options as 'Allow clients access to local subnet', with a note that further configuration is still required for point 3.
- Settings could be applied to all clients by adding something like the following to the 'Additional Parameters':
push "dhcp-option DNS 10.1.0.1"
push "dhcp-option WINS 10.1.0.100"
alternatively, the settings could be pushed to only some clients by adding the following to the 'Additional Parameters':
client-config-dir /mnt/truenas1pool/openvpn/ccd
where truenas1pool/openvpn is a ZFS filesystem you have configured. Further settings files are place in this ccd subdirectory per client. The names of the files in this subdirectory map to the client cetificate 'Common Name' field for each client certificate. For example /mnt/truenas1pool/openvpn/ccd/openvpn-user-andrew contains:
push "dhcp-option DNS 10.1.0.1"
push "dhcp-option WINS 10.1.0.100"
2. OpenVPN Clients
OpenVPN clients can be configured to connect to a TrueNAS OpenVPN server using the (currently modified) client configuration downloaded from the server. However, for TrueNAS OpenVPN clients, the configuration needs to be imported manually.
- Start by importing the OpenVPN server CA certificate. Add a new CA certificate and select 'Type' as 'Import CA'. Note that only the 'Certificate' needs to be imported. the 'Private Key' and 'Passphrase' fields should be blank.
- On the OpenVPN server, generate an OpenVPN client certificate using an 'Openvpn client certificate' Profile.
- Import this certificate into the TrueNAS client 'Certificates' by adding a new cerficate of 'Type' 'Import Certificate'. Both the 'Certificate' and 'Private Key' are required. The 'Passphrase' is only required if the 'Private Key' has been encrypted.
- Now configure the OpenVPN Client settings based on the settings on your OpenVPN server. In general the 'Additional Parameters' settings does not include settings as the server will push settings to the client.
Additional Parameters
- If you want other computers in the client's network to be able to access the OpenVPN server or OpenVPN server network further configuration is needed:
- The TrueNAS OpenVPN client needs to allow routing between its local subnet and the OpenVPN subnet used to communicate with the OpenVPN server. Add a 'Tunables' RC setting of gateway_enable=YES.
- The default gateway router for the TrueNAS OpenVPN client subnet needs to be told where to send traffic for the OpenVPN server via the OpenVPN client. This is usually done by adding static routes to the router of the subnet for the TrueNAS client (e.g. 10.254.0.0/24 -> 192.168.1.100 and 10.1.0.0/24 -> 192.168.1.100). Alternatively, other individual machines on the same subnet as the TrueNAS client that want to communicate with the OpenVPN server could add these static routes to their configuration.
It might be nice to have a checkbox to add the first option as 'Allow other machines on the local subnet access to OpenVPN server', with a note that further configuration is still required.
- The OpenVPN server will also need further configuration to add routing to the OpenVPN client subnet. On the OpenVPN server, in 'Additional Parameters' add:
route 192.168.1.0 255.255.255.0
client-config-dir /mnt/truenas1pool/openvpn/ccd
where truenas1pool/openvpn is a ZFS filesystem you have configured. Further settings files are place in this ccd subdirectory per client. The names of the files in this subdirectory map to the client cetificate 'Common Name' field for each client certificate. For example /mnt/truenas1pool/openvpn/ccd/openvpn-remote-office1 contains:
iroute 192.168.1.0 255.255.255.0
Additionally the default gateway router for the TrueNAS OpenVPN server subnet needs to be told where to send traffic to the OpenVPN client site network. This is usually done by adding static routes to the router of the subnet for the TrueNAS server (e.g. 192.168.1.0/24 -> 10.1.0.100). Alternatively, other individual machines on the same subnet as the TrueNAS server that want to communicate with the OpenVPN client subnet could add this static route to their configuration.
Troubleshooting
- If clients can ping the OpenVPN server but not the other way around, until a client starts pinging the server, then it is possible that a NAT between the client and server is closing the pinhole too quickly. Try adding 'keepalive 10 60' to the 'Additional Parameters' OpenVPN server settings to force clients to send keepalive messages to the server every 10 seconds with a timeout of 60 seconds. A keepalive option with explaination might be good to add to the settings page.
