www.fridu.net

OpenVPN is based on the Secured Socket Layer (SSL) which sits on top of the IP stack. With OpenVPN you can select variousauthentication methods and encryption algorithms. It can also provide data stream compression.

In most of configuration, we will have a main site which will act as the VPN Server and either fixed remote site with interconnected LAN and/or roaming mobile users.

We assume that LAN interconnection is done at IP level while Roaming users are connected via a bridged Ethernet. 

The general configuration could be as described bellow. 

The addressing plan will reflect a traditional architecture.

• The main office is using a private addressing plan 10.11.100.xxx.
• The remote office used an independent private plan 10.12.100.xxx
• The roaming users share the same plan as the main office via a bridge Ethernet connection. It must be noticed that roaming users will also have an IP address to connect to the internet which is in an other plan.
• The DMZ is using the plan 10.10.100.xxx
• The VPN is using the plan 10.8.0.xxx which is completly invisible to all users.
• The external IP router  gets its address from the ISP.  The use of a fixed IP address is simpler but not required. OpenVPN will work with a dynamic  address which is linked to a fixed fully qualified internet URL via a dynamic DNS.

At the main site where the OpenVPN server will reside, we need to forward one incoming port. This minimum forward requirement is not an error, it's one of the powerful function of OpenVPN. Your OpenVPN server does not need a public address visiblity but only an incoming port forwarded from one public address on the internet.

Even if any value can be used, we advise you to use the port 443 as it's very likely to be open in any place where your roaming users will travel. It will also pass through HTTP proxy which are common on company LAN. Port 563, the backup ssl port, should be a acceptable alternative. The requirement for the client is only an outgoing port connectivity. For remote office LAN interconnection the port selection is under your direct control and any value can be used.

Please note that if you Internet Public server provides HTTPS pages then you cannot use the port 443 (except if you have multiple public IP address).

At the remote sites which will use IP LAN interconnection, we will favour a minimum client configuration option. The proposed concept use a Linux gateway per remote site which will provides all the needed services even when the DSL link will be down (it will happen once in a while with DSL links).

A set of minimum services must be provided at the remote sites. It must be noticed that this set is light enough to be implemented directly a OpenWRT compatible device. At fridu.org we are running OpenVPN server and clients on small Linksys-WAG54G.

• OpenVPN Client
• HTTP transparent proxy (squid+squid guard) with a force redirect on all outgoing HTTP, HTTPS and FTP traffic.
• Firewall which will block all incoming and outgoing traffic except http-proxy,ssl and OpenVPN
• DHCP server
• DNS server

If the remote server has enough power (a full Linux server), it is interesting to provide other services by this single remotely maintainable server:

• File server ideally with automatic replication on main site (OpenAFS, Coda, Novell FSF , ...)
• SubVersion or CVS replicate server for R&D site.
• Printer server (CUPS)
• Login / autentication server. LDAP with its integrated replication is the most appropriate to the job.
• VoIP gateway (Asterisk)

 
Roaming users will use Ethernet bridge interconnection. At fridu.org we favour this solution because it will work with every application (e.g; discovery protocols and video conference multicast)  and it suppress the requirement to manage many small sub networks in order to achieve connectivity toward the roaming users (e.g. to active a VNC support session).

In that model your main open questions will be relative to security and default routing.

• Do you want to use the Main server DHCP in order to give to your roaming user the same MAC address than when present in the office ? If you want to do so, you will need to make sure that the tap0 interface created on the remote PC will use the same MAC adress as the default interface used at the office (in general eth0). In that model you can push many parameter via the DHCP options (e.g. automount) and the Internet traffic will be routed via the OpenVPN server.
• Do you prefer to allocate an isolated range of IP address via theOpenVPN server ? In that model you have less control of the remote configuration (OpenVPN let you push some special options but less than a full dhpc server). The Internet traffic will not be routed by the OpenVPN server which is advisable is you use a DSL connection at the server side.