3. Brief How-to ….. OpenVPN and Site-to-Site Tunnels.

OpenVPN can be implemented either Site-to-site or client-server model. I will take example configurations of both models.

If you want to implement site-to-site configuration, the best way is to use static-keys instead of PKI. Using static keys, you can have your VPN tunnel up and running in a jiffy.

First, decide which Operating systems will be used for implementing VPN endpoints on your network. According to OS, download the OpenVPN software from these locations;

Linux: http://openvpn.net/download.html

I would recommend using Mathias Sundman’s “OpenVPN GUI for windows” for its sheer simplicity.

Windows: http://openvpn.se/download.html

Example of using static keys to create a site-to-site VPN:

In this example, a VPN tunnel will be created with a server endpoint of 10.33.66.1 and a client (peer) endpoint of 10.33.66.2. Encrypted communication between peers will occur over UDP port 1194, the default OpenVPN port.

First generate a static key using this command;

openvpn --genkey --secret static.key

Copy the static key to both peers over some secure channel. Heck, use a pen drive if you are paranoid and have access to both peers physically.

Copy the static key file in “config” directory of OpenVPN installation.

Create a configuration file named “server.ovpn” in the config directory of OpenVPN, and type this in the file;

dev tun

ifconfig 10.33.66.1 10.33.66.2

secret static.key

Now create a “client.ovpn” file in config directory of second peer which will effectively become a client for the server you created just now. Put the following in the client file;

remote remoteserverip

dev tun

ifconfig 10.33.66.2 10.33.66.1

secret static.key

The IP address of remote server will come in place of “remoteserverip” in the remote directive of client.ovpn.

Now start OpenVPN executables using these ovpn files that we created. If you get “Initialization Sequence Completed” in the window, most of your work is done. Now ping the other end of tunnel. If ping succeeds, you are done!

Always make sure that you have UDP port 1194 (or any port/transport protocol over which you plan to create a tunnel) open through the network. This may require manually opening the ports at the firewalls/routers at both ends.
If you want to access the networks behind the endpoint servers, there are two options. Either you use routing (TUN) mode or bridging (TAP) mode on your OpenVPN machines. For some obscure reasons if you want to allow non-routable protocols to be tunneled (like NetBIOS) then you will have to use OpenVPN in TAP mode. Bridging ensures that your VPN endpoints make a long reach Ethernet over your WAN.

If you decide that you want to use a routed (TUN) mode, then you must enable IP forwarding on the OpenVPN machine. The virtual interface can be made external interface and local area connection can be designated internal. It will basically become a router and you can do everything with this box that you could with Linux/windows based router.

Next: Creating OpenVPN tunnels for Clients-to-site scenario….

Read on in Part IV

Previously:

1. SSL VPNs and Using OpenVPN : What is an SSL VPN
2. SSL VPNs and OpenVPN – Part II : Why OpenVPN?

2. Why OpenVPN

Here, in this article, I will lay down the emphasis on one important Open-Source SSL VPN software written by James Yonan and contributed by several others, which proposes security without the inherent complexity of IPsec AND using a trusted design of client component and VPN server.

Usually VPNs require end points which are trusted. The server and client are machines with elevated levels of trust as VPN components are installed on known machines which participate in corporate network according to security policy. Additionally, it is made sure that authentication credentials are pre-installed (in a secure way) on both of these devices so that each endpoint could authenticate each other.

SSL Remote Access connections nee. SSL Gateway clients, allow users to connect to VPN servers irrespective of the machine. The client can be any machine in cybercafe or public terminal. This brings us to two severe security issues. One, we break the trust model. The server and client no longer share the authentication credentials using secure channel.

Two, users connect from machines that are not subject to corporate security policies. Even if the user manages to start SSL session with SSL gateways, they are doing all their input and output on an unknown insecure machines that might as well be worm clearinghouses.

The propensity of a public machine loaded with keystroke loggers and remote management tools that allow the attacker to sniff passwords and collect session data is very high. Untrusted Clientless VPNs on an arbitrary machine is the weakest link in a security chain.
OpenVPN adheres to secure computing practices with a software component installed on the endpoints.

From the OpenVPN website:

“OpenVPN is a full-featured SSL VPN which implements OSI layer 2 or 3 secure network extension using the industry standard SSL/TLS protocol, supports flexible client authentication methods based on certificates, smart cards, and/or username/password credentials, and allows user or group-specific access control policies using firewall rules applied to the VPN virtual interface.
OpenVPN is not a web application proxy and does not operate through a web browser.”

Another reason: OpenVPN is FREE. And works on Linux like OS’s AND Windows.

Next: we will learn how to implement a VPN Tunnel using OpenVPN.

Read on in Part III

Previously:
1. SSL VPNs and Using OpenVPN : What is an SSL VPN

Requirement: To connect to a VPN server in a different country.

Situation: A country which has proxies at every gateway.

Issues: VPN based on IPSec is fussy when it comes across networks which are NAT’ted/ proxied. The Security Parameters Indexes don’t match and clients do not get connected.

Objective: To connect VPN server in a corporate network using some flexible VPN which I can run on any port/transport protocol so as to bypass the port/protocols/applications restriction.

Using these factors I came to conclusion that I needed SSL VPN solution. The following article explains the SSL VPN nuances and advantages of using them in certain situations.

Contents:

1. What is an SSL VPN
2. Why OpenVPN
3. brief How-to (site-to-site and client to site)
4. Nutshell

1. What is an SSL VPN

For a very long time, people in information security have thought IPSec is THE VPN and SSL is for secure online banking. While SSL has traditionally been used for Web site security purposes, SSL’s applications reach wider than just web proxying and application security.

Traditional SSL VPN started off with products that were more like SSL gateways instead of true VPNs. These products cannot be really termed as VPN but more like “Secure Remote Application Access”.

They thrive on a management facade called “Clientless VPN”. A VPN that can be established with any web browser without installing a software component sure promise less pain for users and administrators alike, but it comes with certain caveats that we will talk about later.

In the past, IPSec has been used as THE technology to create a VPN Site-to-site or site-to-client tunnel. IPSec has since long enjoyed widespread implementation because of its monopoly on function, although it has received its fair share of criticism for being too complex, and tightly coupled with Operating System.

IPSec came out in November 1988 with a series of RFC’s defining the protocols necessary to create VPNs. This RFC (2401-2412) represented a backbone of IPSec technologies. While IPSec does provide for a framework to establish a secure tunnel, it comes with a lot of complexity. Since complexity and security is inversely proportional, there are so many things with IPsec that may go wrong with wrong implementation. Thoroughly understanding everything and grappling with issues like Nat-T is something not everyone would be comfortable with.

Apart from that, IPSec being coupled tightly with Operating System doesn’t induce a sense of security. Any program integrated with kernel is against secure computing architecture. A wrong implementation or a security breach could take down the whole system.

Understanding the fact that IPSec is complex, industry started moving towards SSL based Remote Access solutions which may not be as secured as we want them to be. It’s because of the fact that a lot of these solutions push web browser as the client which can be used at any machine. The issue of ANY machine connecting to central site may not be very desirable as machines in cybercafes or public terminals do not form a part of control domain. Its desirable to run your upper layer protocols over SSL because it’s widely implemented and allowed in majority of packet filters.

Yeah…..but WHY OpenVPN??

Read on in Part II

Hi….

It is a nice idea. I hope we all can put up some stuff, something that we are interested in and something that will get our grey cells working.

Maybe someday …. just maybe…this will evolve into an idea….a killer app!