path: root/share/man/man8/vpn.8

.\" $OpenBSD: vpn.8,v 1.104 2005/06/07 09:09:50 jmc Exp $
.\"
.\" Copyright 1998 Niels Provos <provos@physnet.uni-hamburg.de>
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"      This product includes software developed by Niels Provos.
.\" 4. The name of the author may not be used to endorse or promote products
.\"    derived from this software without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.\" Manual page, using -mandoc macros
.\"
.Dd February 9, 1999
.Dt VPN 8
.Os
.Sh NAME
.Nm vpn
.Nd configuring the system for virtual private networks
.Sh DESCRIPTION
A Virtual Private Network (VPN)
is used to securely connect two or more subnets over the internet.
For each subnet there is a security gateway which is
linked via a cryptographically secured tunnel to the security gateway of
the other subnet.
.Xr ipsec 4
is used to provide the necessary network-layer cryptographic services.
This document describes the configuration process for setting up a VPN.
.Pp
Briefly, creating a VPN consists of the following steps:
.Pp
.Bl -enum -compact
.It
Enable packet forwarding.
.It
Choose a key exchange method: manual or automated.
.It
For manual keying, generate the keys.
.It
For manual keying, create the Security Associations (SA).
.It
For manual keying, create the appropriate IPsec flows.
.It
For automated keying, configure the keying daemon.
.It
Configure firewall rules appropriately.
.It
Enable the packet filter.
.It
For automated keying, start the keying daemon.
.It
Test the setup.
.El
.Ss About this page
It is recommended that a test setup be created before attempting to
deploy a VPN on the internet.
The examples in this page can be done using two machines
directly connected to each other,
and a little imagination.
The IP address of each machine represents a gateway address;
the alias (see below) is simply a hook into a fictitious network.
.Pp
The following steps are only necessary
if the VPN is being set up as a test VPN,
on an internal LAN.
.Pp
The VPN can be represented using two machines (A and B).
An alias should be added to each machine,
to give it the appearance of being in another network.
.Pp
On machine A:
.Bd -literal -offset indent
# ifconfig ne0 192.168.1.13 description "Machine A"
# ifconfig ne0 alias 10.0.50.1
.Ed
.Pp
On machine B:
.Bd -literal -offset indent
# ifconfig bge0 192.168.1.15 description "Machine B"
# ifconfig bge0 alias 10.0.99.1
.Ed
.Pp
For all other (non-test) cases,
.Xr ifconfig 8
should be used to configure machines as normal.
.Pp
Additionally, the GATEWAY_* and NETWORK_* variables used in the
following sections are defined below in
.Sx Configuring Firewall Rules .
Please see that section for the correct values for these variables.
.Ss Enabling Packet Forwarding
For security gateways, proper operation often requires packet
forwarding to be enabled using
.Xr sysctl 8 :
.Bd -literal -offset indent
# sysctl net.inet.ip.forwarding=1
# sysctl net.inet6.ip6.forwarding=1
.Ed
.Pp
Packet forwarding defaults to
.Sq off .
.Pp
Additionally, if
.Va net.inet.ip.forwarding
is set to 2,
IP forwarding is restricted to IPsec traffic only.
These and other IPsec related options are documented in
.Xr sysctl 3 .
.Pp
For more permanent operation,
the appropriate option(s) can be enabled in
.Xr sysctl.conf 5 .
.Ss Choosing a Key Exchange Method
There are currently two key exchange methods available:
.Pp
.Bl -bullet -compact
.It
manual keying:
.Xr ipsecadm 8
.It
automated keying:
.Xr isakmpd 8
.El
.Ss Generating Manual Keys [manual keying]
The shared secret symmetric keys used to create a VPN can
be any hexadecimal value, so long as both sides of the connection use
the same values.
Since the security of the VPN is based on these keys
being unguessable, it is very important that the keys be chosen using a
strong random source.
One practical method of generating them is by using the
.Xr random 4
device.
To produce 160 bits (20 bytes) of randomness, for example, do:
.Bd -literal -offset indent
# openssl rand 20 | hexdump -e '20/1 "%02x"'
.Ed
or:
.Bd -literal -offset indent -compact
# openssl rand 20 | perl -pe 's/./unpack("H2",$&)/ges'
.Ed
.Pp
Different cipher types may require different sized keys.
.Pp
.Bl -column "CipherXX" "Key Length" -offset indent -compact
.It Em Cipher	Key Length
.It Li DES Ta "56 bits"
.It Li 3DES Ta "168 bits"
.It Li AES Ta "Variable (128 bits recommended)"
.It Li BLF Ta "Variable (160 bits recommended)"
.It Li CAST Ta "Variable (128 bits maximum and recommended)"
.It Li SKIPJACK Ta "80 bits"
.El
.Pp
Use of DES or SKIPJACK as an encryption algorithm is not recommended
(except for backwards compatibility) due to their short key length.
Furthermore, recent attacks on SKIPJACK have shown severe weaknesses
in its structure.
.Pp
Note that DES requires 8 bytes to form a 56-bit key and 3DES requires 24 bytes
to form its 168-bit key.
This is because the most significant bit of each byte is ignored by both
algorithms.
.Pp
The following would create suitable keys for a 3DES encryption key
and SHA-1 authentication key:
.Bd -literal -offset indent
# openssl rand 24 | hexdump -e '24/1 "%02x"' \*(Gt enc_key
# openssl rand 20 | hexdump -e '20/1 "%02x"' \*(Gt auth_key
.Ed
.Pp
The 3DES encryption key needs 192 bits (3x64), or 24 bytes.
The SHA-1 authentication key needs 160 bits, or 20 bytes.
.Ss Creating Security Associations [manual keying]
Before the IPsec flows can be defined, two Security Associations (SAs)
must be defined on each end of the VPN e.g.:
.Bd -literal -offset indent
# ipsecadm new esp -src $GATEWAY_A -dst $GATEWAY_B \e
    -spi $SPI_AB -forcetunnel -enc 3des -auth sha1 \e
    -keyfile $ENCRYPTION_KEY_FILE \e
    -authkeyfile $AUTHENTICATION_KEY_FILE

# ipsecadm new esp -src $GATEWAY_B -dst $GATEWAY_A \e
    -spi $SPI_BA -forcetunnel -enc 3des -auth sha1 \e
    -keyfile $ENCRYPTION_KEY_FILE \e
    -authkeyfile $AUTHENTICATION_KEY_FILE
.Ed
.Pp
Note that the
.Fl key
and
.Fl authkey
options may be used to specify the keys directly in the
.Xr ipsecadm 8
command line.
However, another user could view the keys by using the
.Xr ps 1
command at the appropriate time (or use a program for doing so).
.Ss Creating IPsec Flows [manual keying]
Both IPsec gateways need to configure
.Xr ipsec 4
routes (flows) with the
.Xr ipsecadm 8
tool.
Two flows are created on each machine:
the first is for outbound flows,
the second is the ingress filter for the incoming security association.
.Pp
On the security gateway of subnet A:
.Bd -literal -offset indent
# ipsecadm flow -out -require -proto esp \e
    -src $GATEWAY_A -dst $GATEWAY_B \e
    -addr $NETWORK_A $NETWORK_B
# ipsecadm flow -in -require -proto esp \e
    -src $GATEWAY_A -dst $GATEWAY_B \e
    -addr $NETWORK_B $NETWORK_A
.Ed
.Pp
On the security gateway of subnet B:
.Bd -literal -offset indent
# ipsecadm flow -out -require -proto esp \e
    -src $GATEWAY_B -dst $GATEWAY_A \e
    -addr $NETWORK_B $NETWORK_A
# ipsecadm flow -in -require -proto esp \e
    -src $GATEWAY_B -dst $GATEWAY_A \e
    -addr $NETWORK_A $NETWORK_B
.Ed
.Ss Configuring the Keying Daemon [automated keying]
Unless manual keying is used, both security gateways need to use the
.Xr isakmpd 8
key management daemon.
.Xr isakmpd 8
implements security policy using the
.Em KeyNote
trust management system.
.Pp
To create a VPN between the same two C class networks as the example
above, using
.Xr isakmpd 8 :
.Bl -enum
.It
Create
.Pa /etc/isakmpd/isakmpd.conf
for machine A:
.Bd -literal -offset indent
# Filter incoming phase 1 negotiations so they are only
# valid if negotiating with this local address.

[General]
Listen-On=		192.168.1.13

# Incoming phase 1 negotiations are multiplexed on the
# source IP address.  Phase 1 is used to set up a protected
# channel just between the two gateway machines.
# This channel is then used for the phase 2 negotiation
# traffic (i.e. encrypted & authenticated).

[Phase 1]
192.168.1.15=		peer-machineB

# 'Phase 2' defines which connections the daemon
# should establish.  These connections contain the actual
# "IPsec VPN" information.

[Phase 2]
Connections=		VPN-A-B

# ISAKMP phase 1 peers (from [Phase 1])

[peer-machineB]
Phase=			1
Transport=		udp
Address=		192.168.1.15
Configuration=		Default-main-mode
Authentication=		yoursharedsecret

# IPSEC phase 2 connections (from [Phase 2])

[VPN-A-B]
Phase=			2
ISAKMP-peer=		peer-machineB
Configuration=		Default-quick-mode
Local-ID=		machineA-internal-network
Remote-ID=		machineB-internal-network

# ID sections (as used in [VPN-A-B])

[machineA-internal-network]
ID-type=		IPV4_ADDR_SUBNET
Network=		10.0.50.0
Netmask=		255.255.255.0

[machineB-internal-network]
ID-type=		IPV4_ADDR_SUBNET
Network=		10.0.99.0
Netmask=		255.255.255.0

# Main and Quick Mode descriptions
# (as used by peers and connections).

[Default-main-mode]
DOI=			IPSEC
EXCHANGE_TYPE=		ID_PROT
Transforms=		3DES-SHA,BLF-SHA

[Default-quick-mode]
DOI=			IPSEC
EXCHANGE_TYPE=		QUICK_MODE
Suites=			QM-ESP-3DES-SHA-SUITE
.Ed
.Pp
.It
Create
.Pa /etc/isakmpd/isakmpd.conf
for machine B:
.Bd -literal -offset indent
# Filter incoming phase 1 negotiations so they are only
# valid if negotiating with this local address.

[General]
Listen-On=		192.168.1.15

# Incoming phase 1 negotiations are multiplexed on the
# source IP address.  Phase 1 is used to set up a protected
# channel just between the two gateway machines.
# This channel is then used for the phase 2 negotiation
# traffic (i.e. encrypted & authenticated).

[Phase 1]
192.168.1.13=		peer-machineA

# 'Phase 2' defines which connections the daemon
# should establish.  These connections contain the actual
# "IPsec VPN" information.

[Phase 2]
Connections=		VPN-B-A

# ISAKMP phase 1 peers (from [Phase 1])

[peer-machineA]
Phase=			1
Transport=		udp
Address=		192.168.1.13
Configuration=		Default-main-mode
Authentication=		yoursharedsecret

# IPSEC phase 2 connections (from [Phase 2])

[VPN-B-A]
Phase=			2
ISAKMP-peer=		peer-machineA
Configuration=		Default-quick-mode
Local-ID=		machineB-internal-network
Remote-ID=		machineA-internal-network

# ID sections (as used in [VPN-A-B])

[machineA-internal-network]
ID-type=		IPV4_ADDR_SUBNET
Network=		10.0.50.0
Netmask=		255.255.255.0

[machineB-internal-network]
ID-type=		IPV4_ADDR_SUBNET
Network=		10.0.99.0
Netmask=		255.255.255.0

# Main and Quick Mode descriptions
# (as used by peers and connections).

[Default-main-mode]
DOI=			IPSEC
EXCHANGE_TYPE=		ID_PROT
Transforms=		3DES-SHA,BLF-SHA

[Default-quick-mode]
DOI=			IPSEC
EXCHANGE_TYPE=		QUICK_MODE
Suites=			QM-ESP-3DES-SHA-SUITE
.Ed
.It
Read through the configuration one more time.
The only real differences between the two files in this example are
the IP addresses, and ordering of Local-ID and Remote-ID for the VPN
itself.
Note that the shared secret (the
.Em Authentication
tag) must match between machineA and machineB.
.Pp
Due to the sensitive information contained in the configuration file,
it must be owned by root and installed without any permissions for
"group" or "other".
.Pp
.Dl # chown root:wheel /etc/isakmpd/isakmpd.conf
.Dl # chmod 0600 /etc/isakmpd/isakmpd.conf
.It
Create a simple
.Pa /etc/isakmpd/isakmpd.policy
file for both machine A and machine B (identical):
.Bd -literal -offset indent
Keynote-version: 2
Authorizer: "POLICY"
Conditions: app_domain == "IPsec policy" &&
            esp_present == "yes" &&
            esp_enc_alg != "null" -\*(Gt "true";
.Ed
.Pp
Due to the sensitive information contained in the policy file,
it must be owned by root and installed without any permissions for
"group" or "other".
.Pp
.Dl # chown root:wheel /etc/isakmpd/isakmpd.policy
.Dl # chmod 0600 /etc/isakmpd/isakmpd.policy
.El
.Ss Configuring Firewall Rules
.Xr pf 4
needs to be configured such that all packets from the outside are blocked
by default.
Only successfully IPsec-processed packets (those on the
.Xr enc 4
interface) or key management packets
(for automated keying,
UDP packets with source and destination ports of 500)
should be allowed to pass.
.Pp
Additional filter rules may be present for other traffic,
though care should be taken that other rules do not leak IPsec traffic.
NAT rules can also be used on the
.Xr enc 4
interface.
.Pp
.Sy Note :
The examples in this page describe a test setup on an internal LAN,
using private (non-routable) IP addresses.
In a typical setup,
at least GATEWAY_A and GATEWAY_B would be configured using
public (routable) IP addresses.
NETWORK_A and NETWORK_B may or may not use public IP addresses,
depending on the network.
.Pp
The
.Xr pf.conf 5
rules for a tunnel which uses encryption (the ESP IPsec protocol) and
.Xr isakmpd 8
on security gateway A might look like this:
.Bd -literal -offset indent
GATEWAY_A = "192.168.1.13"
GATEWAY_B = "192.168.1.15"
NETWORK_A = "10.0.50.0/24"
NETWORK_B = "10.0.99.0/24"

ext_if="ne0"

# default deny
# $ext_if is the only interface going to the outside.
block log on { enc0, $ext_if } all

# Passing in encrypted traffic from security gateways
pass in proto esp from $GATEWAY_B to $GATEWAY_A
pass out proto esp from $GATEWAY_A to $GATEWAY_B

# Need to allow ipencap traffic on enc0.
pass in on enc0 proto ipencap from $GATEWAY_B to $GATEWAY_A

# Passing in traffic from the designated subnets.
pass in on enc0 from $NETWORK_B to $NETWORK_A
pass out on enc0 from $NETWORK_A to $NETWORK_B

# Passing in isakmpd(8) traffic from the security gateways
pass in on $ext_if proto udp from $GATEWAY_B port = 500 \e
	to $GATEWAY_A port = 500
pass out on $ext_if proto udp from $GATEWAY_A port = 500 \e
	to $GATEWAY_B port = 500
.Ed
.Pp
The
.Xr pf.conf 5
rules on security gateway B might look like this:
.Bd -literal -offset indent
GATEWAY_A = "192.168.1.13"
GATEWAY_B = "192.168.1.15"
NETWORK_A = "10.0.50.0/24"
NETWORK_B = "10.0.99.0/24"

ext_if="bge0"

# default deny
# $ext_if is the only interface going to the outside.
block log on { enc0, $ext_if } all

# Passing in encrypted traffic from security gateways
pass in proto esp from $GATEWAY_A to $GATEWAY_B
pass out proto esp from $GATEWAY_B to $GATEWAY_A

# Need to allow ipencap traffic on enc0.
pass in on enc0 proto ipencap from $GATEWAY_A to $GATEWAY_B

# Passing in traffic from the designated subnets.
pass in on enc0 from $NETWORK_A to $NETWORK_B
pass out on enc0 from $NETWORK_B to $NETWORK_A

# Passing in isakmpd(8) traffic from the security gateways
pass in on $ext_if proto udp from $GATEWAY_A port = 500 \e
	to $GATEWAY_B port = 500
pass out on $ext_if proto udp from $GATEWAY_B port = 500 \e
	to $GATEWAY_A port = 500
.Ed
.Ss Enabling the Packet Filter
Enable the packet filter and load the ruleset:
.Bd -literal -offset indent
# pfctl -e
# pfctl -f /etc/pf.conf
.Ed
.Ss Starting the Keying Daemon [automated keying]
Start
.Xr isakmpd 8
.Pp
On both machines, run:
.Pp
.Dl # /sbin/isakmpd
.Pp
To run with verbose debugging enabled, instead start with:
.Pp
.Dl # /sbin/isakmpd -d -DA=99
.Ss Testing the Setup
It is important to check the setup is working correctly.
Remember that the following examples illustrate a test setup only,
and therefore tests carried out on GATEWAY_A and NETWORK_A will be
carried out on the same machine (Machine A).
If this were a real setup, GATEWAY_A and a machine on NETWORK_A would be
different machines.
.Pp
Using the test setup,
first check the routing table shows the routes between the two gateways.
.Pp
On GATEWAY_A:
.Bd -literal -offset 1n
$ netstat -rn -f encap
Routing tables

Encap:
Source      Port Destination  Port  Proto SA(Address/Proto/Type/Direction)
10.0.99/24  0    10.0.50/24   0     0     192.168.1.15/50/use/in
10.0.50/24  0    10.0.99/24   0     0     192.168.1.15/50/require/out
.Ed
.Pp
This shows that anything with source address 10.0.99.0/24 (NETWORK_B)
is routed to destination 10.0.50.0/24 (NETWORK_A),
and vice versa.
The opposite would be true if
.Xr netstat 1
were run on GATEWAY_B.
.Pp
Note that the routing table above is given for an automated keying session.
SA information for a manual keying session would differ slightly: the
.Dq Type
field would be
.Dq require
for both directions.
.Pp
Next check that you can
.Xr ping 8
the networks:
.Pp
On NETWORK_A:
.Pp
.Dl $ ping -I 10.0.50.1 10.0.99.1
.Pp
Note the
.Fl I
option passed to
.Xr ping 8 :
this is necessary to specify a source address
from the network.
Check that the
.Xr ping 8
works from both NETWORK_A and NETWORK_B, changing the arguments as necessary.
.Pp
Check that the traffic between the two networks really is
ESP encapsulated.
On GATEWAY_A:
.Pp
.Dl # tcpdump -n -i ne0 esp
.Pp
On NETWORK_A:
.Pp
.Dl $ ping -I 10.0.50.1 10.0.99.1
.Pp
Check that
.Xr tcpdump 8
shows ESP packets whilst the ping is in progress.
That shows that the traffic is IPsec encapsulated.
.Pp
If both networks are pingable,
the routing tables look as described above,
and
.Xr tcpdump 8
is working as described,
it means the VPN is working correctly.
However, it is also important to check that no IPsec traffic
is being leaked,
either by badly designed firewall rules
or by a misconfigured VPN setup.
.Pp
On GATEWAY_A:
.Pp
.Dl "# tcpdump -n -i ne0 not esp and host 192.168.1.15"
.Pp
On NETWORK_A:
.Pp
.Dl $ ping -I 10.0.50.1 10.0.99.1
.Pp
This time
.Xr tcpdump 8
has been instructed to ignore ESP packets going to
host 192.168.1.15 (GATEWAY_B),
and no traffic should be seen whilst the ping is running.
One exception to this is if the automated keying setup has been followed,
in which case
.Xr isakmpd 8
key management packets on UDP port 500 may be seen.
This is perfectly normal.
If any traffic is being leaked
i.e. the last ping detailed above is showing traffic,
it is suggested that the administrator review the steps above,
paying particular notice to the firewall configuration procedures.
.Sh FILES
.Bl -tag -width "/etc/isakmpd/isakmpd.policyXX" -compact
.It Pa /etc/isakmpd/isakmpd.conf
.Xr isakmpd 8
configuration file.
.It Pa /etc/isakmpd/isakmpd.policy
.Xr isakmpd 8
policy file.
.It Pa /etc/pf.conf
Firewall configuration file.
.It Pa /usr/share/ipsec/rc.vpn
Sample VPN configuration file.
.El
.Sh SEE ALSO
.Xr netstat 1 ,
.Xr openssl 1 ,
.Xr sysctl 3 ,
.Xr enc 4 ,
.Xr ipsec 4 ,
.Xr keynote 4 ,
.Xr isakmpd.conf 5 ,
.Xr isakmpd.policy 5 ,
.Xr pf.conf 5 ,
.Xr ifconfig 8 ,
.Xr ipsecadm 8 ,
.Xr isakmpd 8 ,
.Xr pfctl 8 ,
.Xr ping 8 ,
.Xr sysctl 8 ,
.Xr tcpdump 8