OpenVPN

OpenVPN

Introducing OpenVPN

One of the most commonly used open source SSL VPNs is OpenVPN, which uses TAP and TUN virtual drivers. TUN (network TUNnel) simulates a network layer device and it operates with layer 3 packets like IP packets. TAP (network tap) simulates a link layer device and it operates with layer 2 packets like Ethernet frames. TUN is used with routing, while TAP is used for creating a network bridge. For Linux version 2.4 or later, these drivers are already bundled with the kernel. OpenVPN tunnels traffic over the UDP port 5000. OpenVPN can either use the TUN drivers to allow the IP traffic; OpenVPN can also use the TAP drivers to pass the Ethernet traffic. OpenVPN requires configuration to be set in the configuration files. OpenVPN has two secure modes. The first OpenVPN mode is based on SSL/Tls security using public keys like RSA, and the second is based on using symmetric keys or pre-shared secrets. RSA certificates and the keys for the first mode can be generated by using the openssl command. Details about these certificates or the private keys are stored in our *.cnf files to establish vpn connection.

The .crt extension will denote the certificate file, and .key will be used to denote private keys. The SSL-VPN connection will be established between two entities, one of which will be a client, which can be your laptop, and the other will be a server running at your office or lab. Both these computers will have .conf files, which define the parameters required to establish an SSL-VPN connection.

Open VPN: The Pros and Cons of SSL VPN

SSL VPN is one way to transfer the information since a web browser can be used to establish an SSL VPN connection. Since SSL VPN is clientless, it will result in cost savings and can be configured to allow access from corporate laptops, home desktops, or any computer in an Internet cafe. SSL VPNs also provide support for authentication methods and protocols, some of which include:

  • Active Directory (AD)
  • Lightweight Directory Access Protocol (LDAP)
  • Windows NT LAN Manager (NTLM)
  • Remote Authentication Dial-In User Service (RADIUS)
  • RSA Security’s RSA ACE/Server and RSA SecurID

Many SSL VPNs also provide support for single sign-on (SSO) capability. More sophisticated SSL VPN gateways provide additional network access through downloadable ActiveX components, Java applets, and installable Win32 applications. These add-ons help remote users access a wide range of applications, including:

  • Citrix MetaFrame
  • Microsoft Outlook
  • NFS
  • Remote Desktop
  • Secure Shell (SSH)
  • Telnet

However, not all SSL VPN products support all applications.

SSL VPN can also block traffic at the application level, blocking worms and viruses at the gateway. SSL VPN is again not bound to any IP address. Hence, unlike IPsec vpn, connections can be maintained as the client moves. SSL VPN differs from IPsec VPN in that it provides fine-tuned access control. By using SSL VPN, each resource can be defined in a very granular manner, even as far as a URL. This feature of SSL VPN enables remote workers to access internal web sites, applications, and file servers. This differs from IPsec VPN, since the entire corporate network can be defined n a single statement. SSL-based VPN uses Secure HTTP on TCP port 443. Many corporate network firewall policies allow outbound access for port 443 from any computer in the corporate network. In addition, since HTTPS traffic is encrypted, there will be limited restrictive firewall rules for SSL VPN.


As you know, SSL-based VPN offers a greater choice of client platforms and is easy to use. However, an organization that wants to be sure their communication channel is encrypted and well secured will never assume that any computer in an Internet cafe is trusted. This in turn requires a trust association with an untrusted client connection. To address the concern of an untrusted client, whenever a client from an untrusted platform connects to the VPN, a small Java applet is downloaded to the client that searches for malicious files, processes, or ports. Based on the analysis of the computer, the applet can also restruct the types of clients that can connect. This may sound theoretically feasible; to do it practically requires the mapping of policies of one anti-virus and anti-spyware tool into an endpoint security tool used by VPN. In addition, these applets are prone to evasion and can be bypassed. However, note it carefully; you also need to have administrative access to perform many of the operations like deleting temporary files, deleting cookies, clearing cache, and so forth. If you have administrative rights in an Internet cafe, you can assume that the system will be infected with keystroke loggers and sophisticated malicious remote access tools. [A good example would be Back Orifice.]

By using SSL VPN, a user can download sensitive files or confidential, proprietary corporate data. This sensitive data has to be deleted from the local computer when an SSL VPN is terminated. To ensure the safety of confidential data, a sandbox is proposed and used. A sandbox is used to store any data downloaded from a corporate network via SSL VPN. After the SSL VPN session is terminated, the data in the sandbox is securely deleted. After a session is terminated, all logon credentials require deletion as well. You know that SSL VPN can be established even from a cyber cafe. It might happen that a user can leave the system unconnected. To prevent such issues, periodic authentication is required in some systems. as SSL VPN works on the boundary of Layers 4 and 5, each application has to support its use. In IPsec VPN, a large number of static IP addresses can be assigned to the remote client using RADIUS. This in turn provides the flexibility to filter and control the traffic based on source IP address. In the case of SSL VPN, the traffic is normally proxies from a single address, and all client sessions originate from this single IP. Thus, a network administror is unable to allocate privileges using a source IP address. SSL-based VPN allows more firewall configurations as compared to IPsec VPN to control access to internal resources. Another cause of concern with SSL-based VPN is packet drop performance. IPsec will drop the malformed packet at the IP layer, whereas SSL will take it up the layer in the OSI model before dropping it. Hence, a packet will have to be processed more before it is dropped. This behavior of SSL-based VPN can be misused, used to execute DoS attacks, and if exploited, can result in a high capacity usage scenario.


External Links:

The official OpenVPN site

OpenVPN on Wikipedia

TUN/TAP on Wikipedia

OpenVPN DD-WRT Wiki

VPN Access Strategies

VPN accessA virtual private network (VPN) is exactly what it sounds like: the network connection you create is virtual, because you can use it over an otherwise public network. Basically, you take two endpoints for the VPN tunnel, and all traffic between these two endpoints will be encrypted so that the data being transmitted is private and unreadable to the system in between. Different VPN solutions use different protocols and encryption algorithms to accomplish this level of privacy. VPNs tend to be protocol independent, at least to some degree, in that the VPN configuration is not on a per-port basis. Rather, once you have established the VPN tunnel, all applicable traffic will be routed across the tunnel, effectively extending the boundaries of your internal network to include the remote host. In this article, we will examine some of the issues involved in implementing VPN access.

VPN Access: Network Design

One of your first considerations when planning to provide for VPN access is the network design. Because the VPN tunnel needs two endpoints, one will be the remote workstation. The other will be a specially configured device for that purpose. This is generally called a VPN concentrator, because it acts as a common endpoint for multiple VPN tunnels. [As noted previously in this blog, Soekris makes affordable VPN cards that offload the CPU of the the computing intensive tasks of encryption and compression.] The remote system will effectively be using the concentrator as a gateway into the internal network; as such the placement of the concentrator is important: in a highly secured environment, the concentrator is placed in a DMZ sandwiched between two firewalls, one firewall facing the Internet, and the other facing internally. While this type of arrangement is the most secure, it takes more hardware to implement.


Another way to place the VPN concentrator inside a DMZ is to use an additional interface on the firewall as the DMZ in a “one-legged” configuration. This saves you having to implement an additional firewall, but still provides some isolation between the concentrator and the rest of the internal network. If an attacker compromised a remote host who was VPNed into the concentrator or compromised the concentrator itself, they would still have a firewall between them and the internal network. The least preferable option is to place the concentrator inside the internal network. With this type of design, if the concentrator is compromised, the attacker would have full access to the internal network, with no firewalls to inhibit their activities. With any of these designs, you will have to permit the required ports through the firewall and forward them to your VPN concentrator in order to ensure VPN access.

VPN Access: Protocols

Another consideration in providing VPN access is the type of VPN protocol you want to use. IPsec is still the most widely deployed VPN technology for good reason. One is interoperability. As a widely used and tested standard, IPsec will work with virtually any modern firewall and operating system. The disadvantage of IPsec is that it can sometimes be difficult to configure properly, and there is zero margin for error on the configuration. Both ends have to se the same parameters for encryptions, hashing, and so forth, or the tunnel cannot be established. SSL is an increasingly popular choice for VPNs, largely because of its simplicity to implement.

Once you have chosen a design and VPN technology, you need to consider the administrative ramifications of offering remote access. Some level of training will be required. At the very least, they may require training to use the VPN software. It is a good idea to educate your users on good security habits as well. A determination will also need to be made as to whether remote users are allowed to use their own personal computers and/or laptops, or if they must use a company-provided computer for remote access. The former option carries with it many risks. When a remote user connects their personal computer to the corporate network, they may have spyware, a virus, or any number or potentially damaging conditions present on their system. Due to the fact that you probably do not have any administrative access to their systems, you may have no way to secure the personal systems even if you wanted. This is why most companies require that only corporate resources be allowed to connect to the company network.

VPN Access: Hardware

One last consideration for VPN access is hardware selection. Normal workplace desktop applications place very little strain on even a remotely modern processor. The same is not true when it comes to VPN connections. A single VPN connection requires little overhead and rarely impacts the remote user’s system unless it is especially underpowered. For the VPN concentrator, however, it will handle the encryption and decryption of multiple connections, in addition to managing the volume of network data that will be accessed through it. For this reason, if you anticipate more than just a couple of VPN connections to be used simultaneously, you will want to test and evaluate your hardware needs.


Internal Links:

pfSense VPN: Part One

pfSense VPN: Part Two

pfSense VPN: Part Three (PPTP)

External Links:

An Overview of VPN Concentrators at YouTube (from CompTIA’s Network+ certification training)

How the VPN Concentrator Works at networkingtechnicalsupport.blogspot.com

Remote Access Options

remote accessSooner or later, odds are good that you will either want or need the ability to work remotely. Providing remote access must be undertaken very cautiously, because as soon as you allow an employee to connect to the corporate network, you have to some degree extended your network boundary to their workstation. This means your network’s security is now only as good as the security of the remote user’s system or network. In some cases, this borders on no security at all. This is why remote access must only be granted after careful consideration and planning. While the different types of remote access have different levels of security risk, all types of remote access have some common planning and configuration steps.

Remote Access: VPNs

The first step is to determine what type of remote access is appropriate. A virtual private network (VPN) extends a private network across a public network, such as the Internet. It enables a computer to send and receive data across shared or public networks as if it were directly connected to the private network, while benefiting from the functionality, security, and management policies of the private network. This generally provides the greatest level of functionality, but also poses the greatest risk. If the remote system is compromised, an attacker is effectively inside your corporate network. While there are steps you can take to mitigate these risks, they may be time-intensive and effort-intensive. To plan, configure and properly secure a VPN solution is the most involved choice of the various remote access solutions you could provide.

Remote Access: Remote Desktop Software

Another option is to provide remote desktop functionality. This would allow a remote user to see and use the desktop of a system at work. A remote desktop acts as if the user is at work, while a VPN acts as if the user’s computer is at work. This type of solution is slightly easier to implement, because you can typically isolate the traffic that needs to be permitted through the firewall to a single TCP port. Many of the same risks exist, however, in that if an attacker manages to gain access to an internal desktop remotely, it is usually easy for them to move information out of the network or otherwise cause mischief. Another key consideration with this type of solution is that you need to have a computer at home and a computer at work. With the VPN option, youonly need to use one system, so if the user has a laptop, it can be used while they work remotely. There are several options for remote desktop functionality: LogMeIn (which is no longer free), TeamViewer (free for home users), and Symantec’s PcAnywhere, to name but a few.


Remote Access: Remote Shell

The last and least functional option is that of a remote shell. Because most users do not operate extensively (or even at all) in a console environment, this type of remote access is generally most suitable for network administration personnel. While it may be impossible for typical users to operate their systems without a GUI, many network tasks and most firewall administration tasks can be permormed with only terminal access. Because the widely-used Telnet protocol sends all data unencrypted, any sensitive tasks should only be performed using a secured protocol such as secure shell (SSH), or Telnet over a Secure Internet Protocol (IPsec) tunnel.

External Links:

VPN at Wikipedia

© 2013 David Zientara. All rights reserved. Privacy Policy