Skip to content
- What is the difference between LAN-to-LAN (or site-to-site) VPNs and host-to-LAN VPNs?
The LAN-to-LAN Virtual Private Networks are encrypted connections via Internet that connect geographically distinct networks. These connections are used by companies with offices dispersed territorially and the use of dedicated data communication links would be too expensive.
The host-to-LAN VPNs instead connect individual clients in a encrypted manner to a LAN. This need is ever-increasing alongside the use of firewalls that block the external use of the most sensitive services within company intranet: by using host-to-LAN VPNs an employee who is off site can avail of all relevant intranet services as if physically connected.
- What does VPN Passthrough and IPSec NAT-T mean?
Often the protocol used to compose VPNs, for example IPSec, encrypts the payload of IP packets and authenticate them via a checksum on the header. A router that applies the NAT or PAT on packets must be able to inspect payload content, since the TCP/UDP ports are located here and are used to track connections in the NAT table. Obviously, if the payload is encrypted this is not possible. On the other hand, the NAT/PAT routers change packet headers, since they must translate the source/destination addresses. This ensures the authentication of IPSec fails.
VPN Passthrough techniques are a solution to these problems for use of VPNs on networks subject to NAT and port forwarding, also found in more economical router ranges. There is no standard for these methods and they can vary from one router model to another.
NAT Traversal or for short NAT-T, instead represents a standard and solves the aforementioned problems by encapsulating the packets already encrypted by IPSec in a UDP tunnel on port 4500. NAT Traversal, in contrast to the various VPN Passthroughs, is applied on two endpoints of the VPN (e.g. Road Warrior and gateway VPN). ZeroShell, if enabled, can negotiate the use of NAT-T with the L2TP/IPSec client.
- I have noticed that ZeroShell creates the VPN LAN-to-LAN using a tunnel encrypted with SSL which encapsulates the Ethernet frames instead of using the more widely known IPSec protocol. Why is this?
Because IPSec encapsulates IP packets only, while the other layer 2 protocols of the ISO/OSI model are not transported from one LAN to another. The idea of encapsulating the Ethernet frames inside a SSL tunnel leads us to thinking of site-to-site VPNs as a virtual network cable, which using Internet connects two remote stations in data link layer. Since we are dealing in fact with an Ethernet connection, with characteristics similar to that of a cable that connects two local switches, any protocol can be transported, including VLAN 802.1q.
- If the ZeroShell site-to-site VPNs are in fact similar to an Ethernet connection, can I bridge one or more VPNs with one or more Ethernet interfaces?
Yes, you can. The result is like a virtual level 2 switch which extends via Internet, however its ports seem to belong to the same virtual switch, even if thousands of kilometres apart.
- My company is composed of a head office with a very fast Internet connection and peripheral offices that connect to the Internet using slower ADSL lines. I would like the peripheral offices to connect to head office using a site-to-site VPN, but the slowness of the ADSL lines is creating a bottleneck. Could I merge multiple ADSL connections to increase the bandwidth and reliability?
Yes, you can by using the ZeroShell VPN Bonding function. For each ADSL connection you then create a Virtual Private Network with the head office and merge them in one bond interface. The traffic will be distributed in Round-Robin on the VPN composing the bond and by doing so the bandwidth is increased in proportion to the number of ADSL lines used. Lastly, remember that other than load balancing of the Virtual Private Network, the VPN bonds also ensure fault tolerance so that if one of the connections fails, the traffic is re-balanced in a few seconds on the remaining working connections.
- ZeroShell implements the Virtual Private Network LAN-to-LANs by encapsulating Ethernet frames inside an authenticated and SSL encrypted tunnel using host X.509 certificates. However, must I use a ZeroShell box on both the VPN endpoints?
No, for site-to-site VPNs ZeroShell uses open source OpenVPN software and therefore any system which supports this software (Linux, Windows, Mac OS X, FreeBSD, NetBSD, OpenBSD and Solaris), and is appropriately configured can work as a VPN gateway compatible with ZeroShell.
- I see that OpenVPN can be configured to use TUN devices or TAP devices. What are they? Which of the two devices is used by ZeroShell?
The TUN/TAP devices are drivers that enable processes that run in userspace, writing and reading from the /dev/net/tun character device, to communicate with the kernel and emulate the network interfaces. In particular, the TUN devices create point-to-point network interfaces, while the TAP devices create Ethernet network interfaces. Obviously ZeroShell, that encapsulates the Ethernet frames, configures OpenVPN to use the TAP devices.
- ZeroShell implements the Host-to-LAN Virtual Private Networks using standardised L2TP/IPSec protocol. Why is OpenVPN not used in this case?
For Host-to-LAN Virtual Private Networks, in which the VPN gateway must connect the so-called Road Warrior clients, off site users wish to access their LAN resources as if they were physically connected. ZeroShell prefers to use standard protocol such as L2TP/IPSec because for the majority of operating systems it doesn’t require installation on third party software clients. OpenVPN would instead require installation of an external client. In fact, it is most probable that future releases of ZeroShell will allow the use of OpenVPN as a Host-to-LAN gateway.
- I configured Windows XP to create a VPN L2TP/IPSec towards a ZeroShell VPN gateway. However, when I try to activate the VPN, Windows XP gives me the message that there is no certificate to establish the IPSec connection. What does it depend on?
L2TP/IPsec protocol is a combination of two protocols: the first is the well-known IPSec used to establish a encrypted IP tunnel between the client and the VPN gateway; the second is L2TP (Layer 2 Tunnel Protocol) protocol which is encapsulated in the first and transports user data. L2TP is authenticated with a username and password (Kerberos 5) belonging to the user who wants to establish a connection. Instead, IPSec, to mutually authenticate the client machine and the VPN gateway, requires both to have an X.509 and the relative private keys. Note that a certificate for a Windows client isn’t a personal user certificate as the certificate must belong to the computer account and is therefore stored by the administrator.