What is it?
In greater details:
Proxy with Antivirus
WiFi Access Point
NIS and LDAP
A VPN Host-to-LAN router by using OpenVPN
The purpose of this document is to describe how to configure an OpenVPN Gateway for the Host-to-LAN Virtual Private Network. The sections in which the how-to is divided are the followings:
Zeroshell was able to act as VPN gateway for the Host-to-LAN connections already starting with its first release. However, only the L2TP/IPSec VPNs were supported. This combination of tunnels, the first (IPSec) authenticated by the IKE with X.509 certificates and the second (L2TP) authenticated with username and password credentials against the local Kerberos 5 KDC, has showed its limits soon. Many of the issues of L2TP/IPSec, which have been solved by using OpenVPN, are listed below:
To avoid the problems related to the use of L2TP/IPSec, starting with the release 1.0.beta7 of Zeroshell, it is possible use configure OpenVPN to act as VPN gateway for the Roadwarrior's connections. Notice that, Zeroshell was already using OpenVPN to make possible Site-to-Site VPN either in routed or bridged mode and with the possibility to transport the 802.1q VLANs across Internet. The stability and the flexibility demonstrated in the LAN-to-LAN VPNs has pushed in the direction of using this software also for the Host-to-LAN ones.
- It is not possible to avoid deploying a X.509 certificate and the related private key to any VPN client. This problem can be resolved building a PKI (Public Key Infrastructure) to sign and manage X.509 certificates. Zeroshell has the X.509 Certification Authority module, but in any case, its management could take too time for some organizations
- After the X.509 authentication, it is not possible to avoid the second authentication with username and password. This double authentication, in some cases, could be considered a time waster, specially when the certificate is stored on a Smart Card and to unlock the private key, the PIN code is already needed;
- The L2TP/IPSec VPN clients are not easily configurable also in the case in which the Operating System includes native support for such type of VPN;
- Either the client reaches Internet across a NAT router or the VPN server has a private IP address, the IPSec protocol has some authentication problems due to the fact that, the NAT Gateway alters the IP headers. The solution to this type of problems consists either in the use on the NAT routers of unstandardized VPN pass-through techniques or in the NAT-T (NAT Traversal) which allow to encapsulate the IPSec packets in UDP flow (port 4500). The NAT-T is a standardized protocol, but the VPN clients need to negotiate the use of it with the VPN gateway only when there is actually a NAT device between them.
The advantages in the use of OpenVPN in Roadwarrior VPN are:
The OpenVPN service is quite and easily configurable by using the web interface (look at the image);
In addition to the X.509 client authentication which requires that any user has a personal certificate and the related private key, by using OpenVPN it is possible to be authenticated with username and password either against an external RADIUS server or against an external and the local Kerberos 5 KDC (look at the note *). The last capability makes possible the authentication of the users of a Microsoft Active Directory Domain.
As you can see from the document OpenVPN client configuration for Windows, Linux, Mac OS X and Windows Mobile for Pocket PC, an OpenVPN GUI is installable on the most used operating systems;
- When OpenVPN is configured to use the TAP devices (that are software Ethernet Interface), it encapsulates Ethernet frames in the SSL encrypted tunnel. The advantage in the use of an Ethernet VPN is that, in addition to the routed mode in which the VPN gateway acts as a layer 3 router, it is possible to bridge the physical Ethernet Interfaces with the VPN ones. In this manner, not only the IP protocol can be sent across the VPN, but also other layer 3 protocols such as SPX/IPX NetWare, AppleTalk and NetBeui.
Because in bridged mode, the Ethernet broadcast is also forwarded across the VPN, it is possible to use, for the remote VPN clients, the same DHCP server used for then LAN.
In last analysis, the approach of OpenVPN appears robust, because not only uses strongest cryptographic algorithms available in the OpenSSL libraries, but also the developers are careful about the quality of the code. This makes OpenVPN a secure and stable software by reducing the presence of security holes.
OpenVPN web interface. Click on the image to enlarge it.
The default VPN Host-to-LAN configuration makes starting the service as easy as possible. In fact, in order to connect to Zeroshell in VPN, simply click the Enabled flag in the [VPN]->[Host-to-LAN (OpenVPN)] section (see illustration) to start the openvpn process which listens for incoming connections. For quick client setup, use the zeroshell.ovpn setup file available in the download section. Parameters specified in this client setup file reflect the VPN gateway default configuration and only the IP address and hostname to be connected to need be changed. For further information on VPN client setup, see the following How-To.
Default configuration features, along with the reasons for this choice, are listed below. Taking a look at the illustration which corresponds to the initial OpenVPN configuration may be useful as a summary.
At this point, having taken a look at the initial VPN Host-to-LAN configuration, we will now see how to adjust Zeroshell behavior to our needs. It is immediately obvious that OpenVPN software has an extremely flexible configuration thanks to its numerous settings but that the Zeroshell web interface only permits a limited number of them to be edited. In the attempt to get around the problem, the configuration page includes a Command Line Parameters field where settings can be directly entered in the openvpn process.
OpenVPN lets you select the UDP or TCP transport protocol in which the SSL encrypted tunnel is encapsulated. Zeroshell uses TCP by default since it rapidly renegotiates the connection if VPN is down for connectivity problems. With UDP on the other hand, when service is down, client and server only retry the connection after a certain number of seconds set by the --ping-restart n parameter. However, it should be noted that when TCP is used as tunnel transport for connections which, in turn, can be either TCP or UDP, there is a greater overheard then when UDP is used. The reason for this is found in the fact that TCP, as a connection-oriented protocol, runs integrity controls if VPN encapsulation is redundant, since data integrity is newly controlled for the flows that cross VPN. However, it has been seen that this overhead is negligible and potential performance with TCP is nearly the same as those with UDP. Another determinant factor in using TCP was the consideration of the fact that TCP ports are must less frequently blocked on firewalls than UDP ones.
- In addition to the protocol, the port on which client connections are accepted can also be selected. By default, Zeroshell uses port 1194 since this is the one officially assigned by IANA to OpenVPN.
Authentication is set so that only the usernames and passwords of local Zeroshell users are authenticated. Authentication with X.509 digital certificates or to remote RADIUS or Kerberos 5 servers is not intuitive enough to be included in the default configuration.
Since client authentication with X.509 is disabled by default, the OpenVPN server requires a certificate in order to establish an encrypted channel with VPN clients. By default, this certificate is the one automatically generated by Zeroshell at first startup.
By default, Zeroshell runs OpenVPN in routing mode with IP addresses in subnet 192.168.250.0/255.255.255.0, and default gateway and DNS 192.168.250.254 (itself). Additionally, the source NAT is enabled by default to avoid having to set static routes or enable RIP version 2 protocol on routers to reach clients connected in VPN.
Lastly, LZO compression and traffic encryption are enabled. However, these two features cannot be set by the web interface and, therefore, cannot be disabled.
Using the Authentication selection box (see illustration) the authentication method can be selected using username and password only, X.509 digital certificate or both. For authentication with username and password, different sources can be used to verify credentials. Zeroshell selects the correct authentication provider based on the domain indicated in the username, which must be in username@domain format. If the user does not indicate the domain, Zeroshell uses the default domain whose settings are described later and which initially match the local user database. Authentication sources can be Kerberos 5 servers, Kerberos realm in cross authentication (trust relationship) with local KDC or external RADIUS servers. The illustration below shows how to configure authentication domains.
Authentication sources for OpenVPN. Click the image to enlarge.
Click on the button [+] in the Password Authentication frame to open a form used to configure the authentication domain.
Kerberos 5 domain
This is a Kerberos 5 realm. Enter the name in the Domain Name field and select either External Kerberos 5 Realm or Trusted Kerberos 5 Realm. In the first case, credentials are simply verified attempting to acquire a TGT (Ticket Granting Ticket) for the user. In the second case, in addition to TGT acquisition, acquiring a valid service ticket is also attempted exploiting the trust relationship between local Zeroshell REALM and the external one. It is obvious that this second case offers a higher level of security due to verifying the authenticity of the external Kerberos server, but requires more expert configuration since the trust relationship needs to be set on both Zeroshell and the external KDC.
Remember that in this phase, only the domain name is specified but not the authority Kerberos servers for this realm. The way that Zeroshell knows which KDC to contact to verify the credentials of the remote user who wants to connect in VPN is set in the form activated by [Kerberos 5]->[Realms]. Here, the external realm with the list of relevant Kerberos servers can be added or automatic discovery that assumes DNS use of SRV records specific for Kerberos can be enabled.
If you want to permit Microsoft Active Directory domain users to be authenticated on OpenVPN, simply remember that a Kerberos server is running on each Windows 2000/2003 domain controller able to authenticate users. Therefore, simply state the Active Directory domain as External Kerberos 5 Realm and add the realm with the list of Domain Controllers in form [Kerberos 5]->[Realms]. Since Active Directory DNS manage SRV records for Kerberos, automatic discovery can be simply enabled instead of stating the Domain Controllers.
Lastly, in the Password Authentication frame, note that Automatically authorize any trusted Kerberos 5 Realm is flagged. If enabled, all users in realms that have a cross authentication relationship can be authenticated in VPN without having to add each of these domains as described above.
If users must be authenticated from an external RADIUS server, the domain name must be entered and RADIUS Proxy Domain selected. Since OpenVPN uses the proxying mechanism to query local FreeRADIUS which sorts authentication requests to the authority RADIUS, first check that it is running and add the external RADIUS server to the proxy server list found in [RADIUS]->[Proxy]. The external RADIUS server Shared Secret must be specified in this list.
Remember the the @domain part of the username may need to be eliminated according to the external RADIUS server configuration when requesting authentication. In this case, when adding the RADIUS server in [RADIUS]->[Proxy], disable the No Strip flag.
If you want to delegate a RADIUS server to directly meet or delegate another server for any RADIUS authentication request that is not under the explicitly defined domains, add a Default RADIUS by selecting Default in the Realm Type box.
Lastly, as with Kerberos 5 authentication, the Password Authentication frame includes an Automatically authorize any Proxy RADIUS Domain flag When this flag is enabled, proxy authentication is attempted even if the domain is not explicitly authorized.
Having seen the server side configuration for authentication with username and password, it should be noted that the auth-user-pass option must be defined in the VPN client setup file or on the openvpn command line so that the VPN client requests credentials.
Authentication with X.509 digital certificates, where each user who wants to connect in VPN needs a digital certificate and relevant private key, can be requested with or without authentication with username and password according to whether X.509 Certificate + Password or Only X.509 Certificate is selected in the Authentication checkbox.
In the first case, if X.509 authentication is successful, a second authentication is run with Kerberos 5 or RADIUS as previously described. Generally, when this type of double authentication is used, the X.509 digital certificate is not the user's, but a host certificate assigned to the machine. This masks user identification (since several users can connect from the same system) and therefore the username and password are requested.
In the second case, personal certificates assigned to the user are used where the user is identified by the certificate's Common Name (CN field). This makes additional credential requests superfluous.
For a client certificate (whether personal assigned to the user or host assigned to the machine) to be recognized as valid by the OpenVPN gateway, two conditions must be met: the first is that the Certification Authority (CA for short) that signed the certificate is in the Zeroshell Trusted CAs file; second is that this CA is authorized to verify access in VPN.
To meet these two conditions, see the illustration below and complete the following steps:
Authentication configuration with digital certificates. Click the image to enlarge.
Click the [Authentication] button in the X.509 Configuration frame. As you can see, three Certification Authority certificates are loaded. Since all digital certificates signed by these CA are deemed authentic, only those corresponding to the checked Certification Authority are authorized for VPN connection. In our case, these are certificates issued by the Zeroshell example CA.
Click the [Trusted CAs Manager] button and import the certificate from the Certification Authority you want to authorize in the form in PEM format (Base-64 encryption) If you have a Certificate Revocation List (CRL) for revoked certificate publication, you can load it following the same CA import procedure. Thanks to CRL, revoked certificates will not have access to VPN gateway.
Returning to the OpenVPN X.509 Authentication form, you can see that the newly imported CA is considered a reliable certification source. To authorize VPN connections to clients that have a certificate issued by this Certification Authority, simply check the control box and click [Save] to save.
Starting with the Zeroshell release 1.0.beta7, you can see that the VPN99 virtual interface is automatically created and configured during startup. This is a TAP device meaning an Ethernet software interface with which OpenVPN hook up to the SSL encrypted tunnel and permits Kernel management as if it were any other type of Ethernet card. This means that this interface can be assigned an IP address and appropriately configure routing or make it part of a bridge along with other Ethernet interfaces. Based on whether you opt for the first or second possibility (where VPN99 is a member of a bridge), VPN connections will be in routing or in bridging.
It is obvious that if Routed Mode is selected, the IP address assigned to the VPN99 interface must match the default gateway assigned to VPN clients. This need not be done manually since Zeroshell automatically assigns the IP address to VPN99 when the Virtual Private Network service is configured.
Lastly, it is important to note that the way OpenVPN is configured on Zeroshell, clients simultaneously connected in VPN are isolated from each other and therefore cannot communicate unless through the gateway. This choice was forced by the security criteria with which, for example, we want to prevent a VPN client from sharing his virtual interface and sniff traffic not addressed to him. However, if you believe that VPN clients should communicate with each other, simple add --client-to-client to the web interface Command Line Parameters text box. This setting will enable visibility in layer 2 by the openvpn process and not in the Kernel that permits clients to see each other. Since Kernel does not handle this communication, there is no hope of configuring the Firewall (Netfilter) to prevent any type of traffic between clients in the Virtual Private Network.
VPN statistics. Click the image to enlarge.
VPN log messages. Click the image to enlarge.
(*) The manner in which the users are authenticated depend on the OpenVPN server configuration. Zeroshell supports a multi-domain authentication system in which you have to configure the authentication source which can be a Kerberos 5 KDC (local, external and trusted) or an external RADIUS server. One of these authentication domains is set to be the default domain. The users of the default domain do not need to specify the username in the form of username@domain (ex. firstname.lastname@example.org). Notice that the domain name is not case sensitive, because if the domain is configured to be a Kerberos V realm, it is automatically converted to uppercase.