2.7.
VPNs Menu

2.7.1.
Virtual Private Networks (VPNs)

Virtual Private Networks or VPNs allow two networks to connect
directly to each other over another network such as the Internet.
All data is transmitted securely over an encrypted tunnel, hidden
from prying eyes.
Similarly, a single computer can also connect to another network
using the same facilities.
One of the protocols used to create VPNs is known as IPSec.

IPCop can easily establish VPNs between other IPCop servers.
IPCop can also inter-operate with just about any
VPN product that supports IPSec and standard encryption
technologies such as 3DES.
VPN connections in IPCop are defined as Net-to-Net or Host-to-Net.
This is 100% optional, so you may safely ignore this section
if you do not wish to make use of this feature.

Most modern operating systems have support for IPSec.
This includes Windows, Macintosh OSX, Linux and most
Unix variants.
Unfortunately, the tools needed to provide this support vary
greatly and may be difficult to set up.

2.7.1.1. Net-to-Net

Net-to-net VPNs link two or more private networks across the
Internet, by creating an IPSec “tunnel”.
In a net-to-net VPN, at least one of the networks involved must
be connected to the Internet with an IPCop firewall.
The other network can be connected to an IPCop firewall, or
another IPSec enabled router or firewall.
These router/firewalls have public IP addresses assigned
by an ISP and are most likely to be using Network Address
Translation, hence the term Net-to-Net.

If desired, a VPN can be created between wireless machines
on your BLUE network and an IPCop firewall.
This ensures that traffic on your BLUE network cannot be
intercepted with wireless sniffers.

2.7.1.2. Host-to-Net

A Host-to-Net connection is where IPCop is at one end of
the VPN tunnel and a remote or mobile user is on the other end.
The mobile user is most likely to be a laptop user with a
dynamic public IP address assigned by an ISP,
hence the terms Host-to-Net or Roadwarrior.

2.7.2. Methods of Authentication

It is necessary to have a pre-shared key/password/pass phrase or an
X.509 certificate before trying to
configure a Roadwarrior or Net-to-Net VPN connection.
These are methods of authentication, which identify the
user trying to access the VPN.
They will be required in the VPN configuration stage.

2.7.2.1. Pre-shared Key

The pre-shared key authentication method or PSK
is a very simple method that allows VPN
connections to be set up quickly.
For this method, you enter an authentication phrase.
This can be any character string — similar to a
password.
This phrase must be available for authentication on IPCop and
to the VPN client.

The PSK method involves fewer steps than certificate authentication.
It can be used to test connectivity of a VPN and to become
familiar with the procedure of establishing a VPN connection.
Experienced users may wish to progress straight to
generating a certificate of
authority before trying to configure a roadwarrior or
a net-to-net VPN connection.

The pre-shared key method should not be used with
Roadwarrior connections as all roadwarriors must use the
same pre-shared key.

Note

The clocks on either end of the IPCop VPN tunnel
should be up to date before configuring a VPN.

2.7.2.2. X.509 Certificates

X.509 certificates are a very secure way of connecting VPN
servers.
To implement X.509 certificates you must either generate or
setup up the certificates on IPCop or use another certification
authority on your network.

X.509 Terminology

X.509 certificates on IPCop and many other implementations
are manipulated and controlled by OpenSSL.
SSL, or the Secure Sockets Layer, has its own terminology.

X.509 certificates, depending on their type, may contain public and
private encryption keys, pass phrases and information about the
entity they refer to.
These certificates are meant to be validated by Certification
Authorities (Certificate Authorities) or CAs.
When used by web browsers, the CA certificates of major, pay for, CAs
are compiled into the browsers.
To validate a host certificate, the certificate is passed to the appropriate
CA to perform validation.
On private networks or unique hosts, the CA may reside on a local host.
In IPCop's case, this is the IPCop firewall, itself.

Certification requests are requests for X.509 certificates that are passed
to CAs.
The CAs in turn generate an X.509 certificate by signing the request.
These are returned to the requesting entity as X.509 certificates.
This certificate will be known to the CA, since it signed it.

You will see that X.509 certificates and requests can be stored on
your hard drive in three different formats, usually identified by their
extensions.
PEM format is the default for OpenSSL.
It can contain all the information associated with certificates in printable
format.
DER format contains just the key information and not any extra X.509
information.
This is the default format for most browsers.
PEM format wraps headers around DER format keys.
PKCS#12, PFK or P12 certificates contain the same information
as PEM files in binary format.
Using the openssl command,
PEM and PKCS#12 files can
be transformed into their opposite number.

To use a certificate, you must import it into the other
side's CA, too.
The IPSec implementation on IPCop contains its own built in CA.
CAs may run on roadwarrior's machines, also.

If the roadwarrior's IPSec implementation does not have CA
capabilities, you can generate a certificate request, import it into IPCop
so that IPCop's CA can sign it, export the resulting certificate
and import it into the originating road warrior's IPSec software.

2.7.3.
Global Settings

Figure 2.29. VPN Global Settings

Enter the VPN server details, either its fully qualified domain name
or the public IP address of the red interface.
If you are using a dynamic DNS service, you should use your dynamic
DNS name here.

VPNs and Dynamic DNS

If your ISP changes your IP address, be aware that Net-to-Net VPNs
may have to be restarted from both ends of the tunnel.
Roadwarriors will also have to restart their connections in this case.

Enable the VPN on IPCop by selecting
Local VPN Hostname/IP
and click on the
Save
button.
The
VPN on Blue
option will only be visible if you have configured a BLUE
network interface card.
To enable a VPN over your BLUE wireless connection click on
the
VPN on BLUEEnabled:
check box and then click on the
Save
button.

2.7.4.
Connection Status and Control

2.7.4.1. Creating IPCop's Certificates

Figure 2.31. VPN Certificate Authorities window: Initial View

To create an IPCop's Certificate Authority or CA, enter your
CA's name in the
CA Name box.
The name should be different than the IPCop machine's
host name to avoid confusion.
For example, ipcopca for the CA and
ipcop for the hostname.
Then click on the
Generate Root/Host Certificates
button.

The Generate Root/Host Certificates
will appear.
Fill out the form and both a X.509 root and host certificate will be
generated.

Organization Name.
The organization name you want used in the certificate.
For example, if your VPN is tying together schools in a school
district, you may want to use something like
“Some School District.”

IPCop's Hostname.
This should be the fully qualified domain name of your IPCop.
If you are using a
dynamic DNS service,
use it.

Your E-mail Address.
Your E-mail address, so that folks can get hold of you.

The next three fields; department, city and state or province.
You can leave them out if you wish.

Your Department.
This is the department or suborganization name.
Continuing the school district example, this could be
XX Elementary School.

City.
The city or mailing address for your machine.

State or Province.
The state or province associated with the mailing address.

Country.
This pull down selection menu contains every ISO recognized
country name.
Use it to select the country associated with the certificate.

After completing the form, click on the
Generate Root/Host Certificates
button to generate the certificates.

If desired, you can generate several root and host certificates on a
single IPCop, and then export them to PKCS12 format files, encrypted
with a password.
You can then email them as attachments to your other sites.
Using the
Upload PKCS12 file
portion of this web page, you can upload and decrypt the certificates
on a local IPCop machine.

2.7.4.2.
Connection Type

Figure 2.32. VPN Connection Type Selection

Select either
Host-to-Net (Roadwarrior)
for mobile users who need access to the GREEN network
or
Net-to-Net
to allow users on another network access to your GREEN
network and to allow users on your GREEN network access
to the other network.

Choose the connection type you wish to create and click on
the Add button.

The next web page that appears contains two sections.
The Connection section will be different
depending on the connection type you are adding.
The Authentication section will be the same.

2.7.4.2.1. Host-to-Net Connection

Name.
Choose a simple name (lower case only with no spaces)
to identify this connection.

Interface.
Then select the IPCop network interface the road warrior will be
connecting on, either RED or BLUE.
Selecting the RED interface will allow the roadwarrior to connect
from the Internet.
Selecting the BLUE interface will allow the roadwarrior to connect
to the GREEN network from a local wireless network.

Local Subnet. Local Subnet defaults to your GREEN network.
If desired, you can create a subnet of your GREEN network to limit
roadwarrior access to your GREEN network.

Remark. Remark allows you to add an optional remark
that will appear in the IPCop VPNs connection window for this
connection.

Enable.
Click on the
Enable
check box to enable this connection.

Edit advanced settings when done.
Click on the
Edit advanced settings when done
check box if you need to modify IPCop's default settings for
IPSec.

2.7.4.2.2. Net-to-Net Connection

Name.
Choose a simple name (lower case only with no spaces)
to identify this connection.

IPCop side.
Choose an
IPCop side,right
or
left,
that will be used in the IPSec configuration files to identify this
IPCop's side of the connection on this machine.
Remember, the side makes no difference.

Local Subnet. Local Subnet defaults to your GREEN network.
If desired, you can create a subnet of your GREEN network to limit
roadwarrior access to your GREEN network.

Remote Host/IP.
Enter the static Internet IP address of the remote network's
IPSec server.
You can also enter the fully qualified domain name of the remote
server.
If the remote server is using a dynamic DNS service, you may have
to restart the VPN if its IP address changes.
There are several scripts available on the IPCop news groups
that will do this for you.

Remote subnet.
Enter the remote network's network address and
subnet mask in the same format as the
Local Subnet
field.
This network must be different from the
Local Subnet
since IPSec sets up routing table entries to send IP
packets to the correct remote network.

Remark.
The Remark field allows you to add an optional
comment that will appear in the IPCop VPNs connection window for this
connection.

Enable.
Click on the
Enable
check box to enable this connection.

Edit advanced settings when done.
Click on the
Edit advanced settings when done.
check box if you need to modify IPCop's default settings for
IPSec.

2.7.4.3.
Host-to-Net Connection

Figure 2.33. VPN Host-to-Net Connection Input

Name.
A simple name (lowercase only, with no spaces) to identify this
connection.

Section to be written...

2.7.4.4.
Net-to-Net Connection

Figure 2.34. VPN Net-to-Net Connection Input

Note on IPSec Terminology

IPSec uses the terms
right and
left for the two sides of a connection or
tunnel.
These terms have no real meaning.
IPSec will orient itself based on network addresses and routes.
Once it determines which network connection, left or right, to use to
get to the other side of a connection, all other right or left parameters
follow.
Many folks use left for the local side of a connection and right
for the remote side.
This is not necessary.
It is best to think of the terms as “side 1” and
“side A” of an old LP record.

Name.
A simple name (lowercase only, with no spaces) to identify this
connection.

IPCop side.
Section to be written...

Section to be written...

2.7.4.5.
Authentication

The second section of the web page deals with authentication.
In other words, this is how this IPCop will make sure the tunnel
established by both sides of the interface is talking to its opposite
number.
IPCop has made every effort to support both PSKs and X.509
certificates.
There are four mutually exclusive choices that can be used to
authenticate a connection.

Use a Pre-Shared Key.
Enter a pass phrase to be used to authenticate the other side
of the tunnel.
Chose this if you wish a simple Net-to-Net VPN.
You can also use PSKs while experimenting in setting up a VPN.
Do not use PSKs to authenticate tunnels to roadwarriors.

Upload certificate request.
Some roadwarrior IPSec implementations do not have their
own CA.
If they wish to use IPSec's built in CA, they can generate
what is called a certificate request.
This is a partial X.509 certificate that must be signed by CA to
be a complete certificate.
During certificate request upload, the request is signed and the
new certificate will become available on the VPNs main web page.

Upload a certificate.
In this case, the peer IPSec has a CA available for use.
Both the peer's CA certificate and host certificate must
be uploaded.

Generate a certificate
.
In this case, the IPSec peer will be able to provide an X.509
certificate, but lacks the capacity to even generate a certificate
request.
In this case, complete the required fields.
Optional fields are indicated by blue dots.
If this certificate is for a Net-to-Net connection, the
User's Full Name or System Hostname
field may need to be the Internet fully qualified domain name
of the peer.
The optional organization name is meant to isolate different portions
of an organization from access to IPCop's full GREEN network
by subnetting the Local Subnet in the connection
definition portion of this web page.
The
PKCS12 File Password
fields ensure that the host certificates generated cannot be intercepted
and compromised while being transmitted to the IPSec peer.