OpenVPN is an SSL/TLS based virtual private network solution. It uses the industry standard SSL/TLS protocol to create the encrypted tunnel which can transmit packets of OSI layer 2 or 3. Pay attention to not confuse OpenVPN which many vendors call SSL VPN. Most of them only claim to be a real SSL VPN, instead they actually are just application level gateways to tunnel only application streams of certain services through an encrypted tunnel without implementing a whole VPN, which in fact is a site-to-site tunnel. As a real SSL VPN, OpenVPN has the ability to tunnel all your traffic from OSI layer 2 on, so even ARP traffic can be transmitted to the remote endpoint.
The main advantage of this type of VPN is the ease of use. Since OpenVPN is an application on both sides of the tunnel, it runs of course in user-space instead of kernel space. Therefore it does not even need modifications of the kernel and furthermore minimizes the opportunity for catastrophic failure which is certainly higher for software which runs in kernel space. This makes the whole A LOT easier to introduce in a network. In fact wherever you manage to establish a normal TCP or UDP connection, like from a browser to a server, you can use OpenVPN. There is no need for NAT traversal or the like. We strongly encourage you to use OpenVPN instead of IPSec if you can choose. The only argument which comes to our mind for using IPSec is interoperability to other vendors.
Figure 8.4. Figure of a VPN used OpenVPN as mixed VPN constisting of roadwarrior and net-to-net in hub-and-spoke topology
OpenVPN is implemented within Endian Firewall as an OpenVPN server and a client. You have these two possibilities splitted to the two administration interface pages OpenVPN Server and OpenVPN gateway2gateway client. Basically the OpenVPN server opens a virtual interface (the interface name begins with tap), whose function is to send bits to the OpenVPN server instead to the wire. The tap interface joins the GREEN bridge, so each connected client is from the sight of the other machines behind GREEN also directly part of the GREEN network. For the OpenVPN server it makes no difference at all if the client connects as Net-to-Net or as roadwarrior (Net-to-Host) and it makes no difference if there are connected one, two or many clients.
Another advantage in front of IPSec is the fact that the OpenVPN server uses acts like a switch (hub-and-spoke). Communication between the VPN endpoints is possible and communication between the connected OpenVPN clients keep within the tunnel and the server process. It must not leave the tap interface on the servers side and therefore must not be decrypted and then re-encrypted on the server.
As mentioned before, OpenVPN web interface is split into two parts. The OpenVPN Server and the Openvpn gateway2gateway client menu, which you can select on top of the page directly after the title Virtual Private Networking. If you like to create a simple tunnel from one EFW to another, simlpy choose one as server and configure it through the OpenVPN server page. The other act's as client and should be configured using the client page. On the clients side there is certainly no need to start the server. If you have one side with dynamic IP's, use that one as client, since the client establishes the connection and may reconnect if the ip address changes. If you have NAT between the endpoints on the clients side, there is no problem at all. If you have NAT on the server side, simply forward the UDP port 1194 to the EFW.
The following describes the OpenVPN Server admin interface which you can find by clicking on the OpenVPN Server tab on top of the page.
This box contains common configuration for the OpenVPN server.
- OpenVPN Server enabled
Tick this on if you like to enable the OpenVPN server on this machine.
- block DHCP responses coming from tunnel
Since the virtual tap device of the openvpn server joins the GREEN bridge, broadcast packets of your GREEN zone will pass the tunnel. This includes DHCP requests from your workstations. If the client on the other side is in bridge mode, DHCP responses will return from it if the remote side has a DHCP server running. This may cause problems, if you do not want the remote DHCP server to assign ip addresses to your local workstations within GREEN. Tick this on if you like to block the responses. Pay attention, this will not block the DHCP responses which come from your local DHCP and go to the remote network! You need to block them on the remote side.
- IP Pool
Fill in the start and end ip address of an ip range from GREEN network which you like to assign to the OpenVPN clients connecting to this server. Note that with Net-to-Net topology, only the remote EFW will get an IP from this range and not the workstations behind.
- Download CA Certificate
With this link you can download the CA Certificate which is needed by each openvpn client in order to be able to connect.
Below the global settings box, you will find the possibility to manage accounts which can connect to the OpenVPN server.
All known users will be listed within a table. Each line has the following action icons which will apply for the respective user:
- Enabled icon
If this appears as a ticked on checkbox, the user is enabled and can connect. Click on it to disable or enable the user. Note that disabling an already connected user does not kick it, it just refuses reconnecting.
- Trash can icon
Click on it to remove the account.
- Yellow pencil icon
Click on it to edit the respective account. This will open a new page which will be described later in Add Account.
Below, you will find a single button, Add Account, which allows you to add a new Account. This button will open a new page which will be described later within Add Account.
If you create a new account, you find the following configuration fields:
- Username
Fill in the username to be created
- Password
Choose a password for the new account.
- Verify Password
Fill in the same password as above. This is only for verification purposes in order to ensure that you typed the password correctly.
- IP Remote network
This is not needed if the remote client which uses to connect with this new account, is in bridge mode. Otherwise you need to specify the network address of the remote GREEN network in order to let the Endian Firewall create correct routing entries on both sides.
- Remote Network Mask
Fill in the netmask of the remote client if it is configured to be in routing mode.
- use internet connection of the firewall
Tick this on of you like to have the remote client to create routing entries in order to direct all the traffic of the remote side through the VPN tunnel to this EFW, where it can leave the RED interface. You normaly want this on roadwarriors in order to enforce security policy, otherwise the remote certainly has its own internet connection and a possible intruder may come in through the VPN and compromise the local GREEN network. Basically this option does the following on the remote side:
Creates a host route which sends all traffic with our RED ip address as destination to the ip address which is used as default gateway.
Removes the default route entry.
Creates a new default route entry with our GREEN ip address as gateway.
- set blue
Tick this on if you like to automatically let the remote client create routing entries which allows all workstations on the remote side to access our BLUE zone.
- set orange
Tick this on if you like to automatically let the remote client create routing entries which allows all workstations on the remote side to access our ORANGE zone.
The following is below the box Users which are allowed to connect to openvpn and shows you all currently connected users.
The table shows you the following information:
- User
Username connected to the server.
- Assigned IP
The ip address which has been assigned to the client by the server. This ip address belongs to the GREEN ip range configured above.
- Real IP
The real public IP address of the connected client.
- RX
The data volume which has been received through this tunnel.
- TX
The data volume which has been transmitted through this tunnel.
- Connected since
The timestamp when the client has connected.
- Uptime
The amount of time the respective client is already connected.
The following actions can be performed on each connected user:
- Kill
Kills the connection immediately. The user can reconnect and this will happen since the openvpn client on the remote side will automatically reconnect as soon as it recognizes the disconnect, which will take up to a couple of minutes.
- Ban
Bans the user. In fact this deactivates and then kicks the user in a row. The user cannot reconnect.
This section describes the configuration of the OpenVPN client shipped within Endian Firewall. With the client, you can have the Endian Firewall to connect to a remote OpenVPN server. Normally you will use this if you would like to create a Net-to-Net connection to another EFW. A client configuration needs the following information in order to successfully connect to a remote OpenVPN server:
Username
Password
CA Certificate of the remote server.
You will get the CA certificate from the server if you push the Download CA Certificate link on Openvpn Server configuration page on the remote Endian Firewall of course. This is needed to add an additional random information which one must have. In this manner it is not possible for an attacker only to gather the username and the password. He/she also needs the certificate in order to be able to connect.
This page lists gives reports the status of the respective configured tunnels. You will notice that this page reloads every five seconds in order to update the status display if the status of some clients changes.
The following describes the displayed configuration items of each client and your action possibilites:
- Status
Displays the connection status of the respective tunnel. The following values do exist:
- closed
The tunnel is closed. There is no connection to the remote host.
- connected
The tunnel to the remote host is established and working.
- connecting...
The client is actually connecting to the remote host.
- resolve error
The client could not resolve the remotes hostname. Probably the hostname does not exist or you have a problem with your DNS resolver.
- invalid ca cert
The CA certificate is invalid. Maybe you supplied the wrong certificate. Another possibility could be that the date on your host is wrong, so that the certificate is not yet valid.
- authentication failed
The client could not authenticate to the remote host. You may supplied the wrong username or password.
- Remote Address
The remote host where the client should connect to.
- Options
Displays configuration options if they are set. Possibly values are:
- bridged
The client is in bridged mode.
- drop DHCP
The client blocks DHCP responses coming from the tunnel.
- Remark
Optional connection description.
- Action
To edit an existing tunnel, click on its yellow pencil icon. The VPN tunnel values will be displayed in the add vpn tunnel settingssection of the page.
To remove an existing tunnel, click on its trash can icon. You will be asked if you really want to remove the tunnel, and if you choose Yes, the tunnel configuration will be removed.
To enable or disable a rule - click on the Enabled icon (the checkbox in the Action column) for the particular entry you want to enable or disable. The icon changes to an empty box when a tunnel is disabled. Click on the checkbox to enable it again
Below you find a single button Add tunnel configuration, which allows you to create a new client configuration in order to connect to a remote Endian firewall or another sort of OpenVPN server.
If you push the button Add tunnel configuration you will reach this page.
In order to create a new tunnel configuration you need to provide the following information:
- Connect to
IP address or public host name (FQDN) of the remote Endian Firewall (or other OpenVPN server).
- Username and Password
Username and password of the OpenVPN account created on the remote host.
- Bridged/routed
The OpenVPN client can run in routed mode or bridged mode. The difference is in which OSI layer the client will act. If you specify bridged mode, the clients virtual tap device will join the bridge of the GREEN zone (br0). As member of the bridge, all traffic created within the GREEN network will also be passed through the tunnel to the remote side. This includes ARP traffic and other protocols which are below TCP. In this manner, the tunnel acts like a switchport. You can use this for example if you need to be able to browse the remotes Microsoft Windows servers. But pay attention, this option does not scale well and sends much unneeded traffic through the tunnel! Use it only if you really need it. In order to access hosts on the remote side you certainly must use the same GREEN network address on both sides, since in fact those two GREEN networks will really be part of the same physical network.
With routed mode the clients tap device will remain alone and will not join the GREEN bridge. The device will have obtain an IP address assigned by the remote OpenVPN server which selects it from the IP pool configured on the remote OpenVPN server. The two GREEN zones are splitted and the two networks will be routed. This all happens within a higher OSI layer. In order to make this work, you need to have different GREEN network addresses, since the two networks in this mode are not the same and need to be distinctable. You also need to specify your local GREEN network and network mask on the remote OpenVPN server in order to let the client set the needed route.
- block DHCP responses coming from the tunnel
If you selected routed mode, this does not interest at all. Otherwise, if you have selected bridge mode, the virtual tap device of the openvpn client joins the GREEN bridge. Therefore broadcast packets of your GREEN zone will pass the tunnel. This includes DHCP requests from your workstations. Since the server on the other side is also part of his GREEN bridge, DHCP responses will return from it if the remote side has a DHCP server running. This may cause problems, if you do not want the remote DHCP server to assign ip addresses to your local workstations within GREEN. Tick this on if you like to block the responses. Pay attention, this will not block the DHCP responses which come from your local DHCP and go to the remote network! You need to block them on the remote side.
- Remark
An optional connection description.
- CA certificate
Endian Firewall OpenVPN server CA certificate. You get this certificate by pressing the Download CA Certificate link on the remote OpenVPN server configuration page.
- CA certificate
you can paste your CA certifcate content (text) in this box or...
- upload CA file
...you can upload the CA certificate file.
- Save
Click "save" to add your configuration.
Situation: you have three branch offices with three Endian Firewall and you need to connect the offices in a unique network as star topology (hub-and-spoke) with encrypted tunnels.
Note
The clocks on either end of the EFW VPN tunnel should be up to date before configuring a VPN, otherwise the connection may not be established if the CA certificate is not yet valid because of a wrong clock.
Configure Endian Firewall OpenVPN server
One of the three Endian firewall must act as OpenVPN server (the hub):
Go to the OpenVPN server section ()
Set an IP address range which will be used to assign an internal (GREEN) IP address to the other two Endian Firewall.
Tick on the Enabled box.
Now add 2 user, office1 and office2 (one for each Endian Firewall that will be connected to our Endian Firewall OpenVPN server) pressing on add new user button in the Users which are allowed to connect to openvpn section.
Supply information to the add new user form items. In this case we assume that it is enough to use routed mode. You need to specify the GREEN network address and network mask of the respective branch office. (office1 and office2).
Repeat step 4 and 5 for the second user.
Ok. The Endian Firewall in the office0 is ready to receive VPN connection from the other offices.
Download the CA certificate file by pressing the link Download CA Certificate. You will need this file on both of the other Firewalls, but pay attention to keep this file private.
Configure the Endian Firewall OpenVPN gateway2gateway client
Now we have to configure the Endian Firewall in the office1 and in the office2.
Go to the office1 Endian Firewall web interface, to the Openvpn gateway2gateway client section ().
Push the button add vpn tunnel.
Supply the following information:
: insert the office0 Endian Firewall RED interface IP address, or the fully qualified host name (Eg. office0.endian.it)
: the username created on office0 Endian Firewall (see "Configure Endian Firewall OpenVPN server" point 4 and 5) (in this case: office1)
: the password for the user
Routed: in this case it probably would be better to choose routed.
: insert a connection description (optional)
: click on the Browse button and choose the file which you saved before within step 8.
Click on save button.
Repeat step 1 to 4 for the office2 Endian Firewall.
If all is ok, the page VPN > OpenVPN Server > Openvpn gateway2gateway client within your office1 and office2 firewall should show you this:
and the office0 Endian Firewall should show you the following within the VPN > OpenVPN Server page:
With this configuration your workstations within office1 and office2 should be able to reach the GREEN network of your office0.
In order to connect to the Endian Firewall OpenVPN server you can choose from a list of free projects which implement an openvpn client with a graphical user interface. One you can find on Mathias Sundman's OpenVPN GUI site. You can also download openvpn from the OpenVPN Homepage, which does provide it as sourcecode or packaged Microsoft Windows Installer. Each major Linux distributions should have it packaged and it has also been ported to other unix derivates.
As next you need a valid and most notably Endian Firewall compatible configuration file. The OpenVPN server on the Endian Firewall:
runs as server of course, so your openvpn installation must act as client (--client) in order to successfully establish a connection.
listens on the standard port 1194 (--port 1194).
uses the UDP protocol (--proto udp).
encapsulates ethernet 802.3, therefore uses tap devices (--dev tap).
uses static key mode (--auth-user-pass).
uses fast LZO compression (--comp-lzo).
Example 8.1. An example command line to start openvpn on your roadwarrior
openvpn --client --pull --comp-lzo --nobind --dev tap --ca /path/to-the-ca-certificate.pem --auth-user-pass --remote your.remote.efw
Example 8.2. An example configuration file for openvpn on your roadwarrior
client proto udp remote your.remote.efw resolv-retry infinite nobind persist-key persist-tun ca path-to-the-ca-certificate.pem auth-user-pass comp-lzo
Download the CA certificate using the appropriate link on the OpenVPN server configuration page and copy the certificate file to the location to which you point with the --ca parameter.