MirOS Manual: vpn(8)

VPN(8)                   BSD System Manager's Manual                    VPN(8)

NAME

     vpn - configuring the system for virtual private networks

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. ipsec(4) is used to provide the necessary
     network-layer cryptographic services. This document describes the confi-
     guration process for setting up a VPN.

     Briefly, creating a VPN consists of the following steps:

     1.   Enable packet forwarding.
     2.   Choose a key exchange method: manual or automated.
     3.   For manual keying, generate the keys.
     4.   For manual keying, create the Security Associations (SA).
     5.   For manual keying, create the appropriate IPsec flows.
     6.   For automated keying, configure the keying daemon.
     7.   Configure firewall rules appropriately.
     8.   Enable the packet filter.
     9.   For automated keying, start the keying daemon.
     10. Test the setup.

About this page

     It is recommended that a test setup be created before attempting to de-
     ploy 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.

     The following steps are only necessary if the VPN is being set up as a
     test VPN, on an internal LAN.

     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.

     On machine A:

           # ifconfig ne0 192.168.1.13 description "Machine A"
           # ifconfig ne0 alias 10.0.50.1

     On machine B:

           # ifconfig bge0 192.168.1.15 description "Machine B"
           # ifconfig bge0 alias 10.0.99.1

     For all other (non-test) cases, ifconfig(8) should be used to configure
     machines as normal.

     Additionally, the GATEWAY_* and NETWORK_* variables used in the following
     sections are defined below in Configuring Firewall Rules. Please see that
     section for the correct values for these variables.

Enabling Packet Forwarding

     For security gateways, proper operation often requires packet forwarding
     to be enabled using sysctl(8):

           # sysctl net.inet.ip.forwarding=1
           # sysctl net.inet6.ip6.forwarding=1

     Packet forwarding defaults to 'off'.

     Additionally, if 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 sysctl(3).

     For more permanent operation, the appropriate option(s) can be enabled in
     sysctl.conf(5).

Choosing a Key Exchange Method

     There are currently two key exchange methods available:

     •   manual keying: ipsecadm(8)
     •   automated keying: isakmpd(8)

Generating Manual Keys [manual keying]

     The shared secret symmetric keys used to create a VPN can be any hexade-
     cimal 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 random(4)
     device. To produce 160 bits (20 bytes) of randomness, for example, do:

           # openssl rand 20 | hexdump -ve '20/1 "%02X"'
     or:
           # openssl rand 20 | perl -pe 's/./unpack("H2",$&)/ges'

     Different cipher types may require different sized keys.

           Cipher      Key Length
           DES         56 bits
           3DES        168 bits
           AES         Variable (128 bits recommended)
           BLF         Variable (160 bits recommended)
           CAST        Variable (128 bits maximum and recommended)
           SKIPJACK    80 bits

     Use of DES or SKIPJACK as an encryption algorithm is not recommended (ex-
     cept for backwards compatibility) due to their short key length. Further-
     more, recent attacks on SKIPJACK have shown severe weaknesses in its
     structure.

     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.

     The following would create suitable keys for a 3DES encryption key and
     SHA-1 authentication key:

           # openssl rand 24 | hexdump -ve '24/1 "%02X"' > enc_key
           # openssl rand 20 | hexdump -ve '20/1 "%02X"' > auth_key

     The 3DES encryption key needs 192 bits (3x64), or 24 bytes. The SHA-1 au-
     thentication key needs 160 bits, or 20 bytes.

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.:

           # ipsecadm new esp -src $GATEWAY_A -dst $GATEWAY_B \
               -spi $SPI_AB -forcetunnel -enc 3des -auth sha1 \
               -keyfile $ENCRYPTION_KEY_FILE \
               -authkeyfile $AUTHENTICATION_KEY_FILE

           # ipsecadm new esp -src $GATEWAY_B -dst $GATEWAY_A \
               -spi $SPI_BA -forcetunnel -enc 3des -auth sha1 \
               -keyfile $ENCRYPTION_KEY_FILE \
               -authkeyfile $AUTHENTICATION_KEY_FILE

     Note that the -key and -authkey options may be used to specify the keys
     directly in the ipsecadm(8) command line. However, another user could
     view the keys by using the ps(1) command at the appropriate time (or use
     a program for doing so).

Creating IPsec Flows [manual keying]

     Both IPsec gateways need to configure ipsec(4) routes (flows) with the
     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 securi-
     ty association.

     On the security gateway of subnet A:

           # ipsecadm flow -out -require -proto esp \
               -src $GATEWAY_A -dst $GATEWAY_B \
               -addr $NETWORK_A $NETWORK_B
           # ipsecadm flow -in -require -proto esp \
               -src $GATEWAY_A -dst $GATEWAY_B \
               -addr $NETWORK_B $NETWORK_A

     On the security gateway of subnet B:

           # ipsecadm flow -out -require -proto esp \
               -src $GATEWAY_B -dst $GATEWAY_A \
               -addr $NETWORK_B $NETWORK_A
           # ipsecadm flow -in -require -proto esp \
               -src $GATEWAY_B -dst $GATEWAY_A \
               -addr $NETWORK_A $NETWORK_B

Configuring the Keying Daemon [automated keying]

     Unless manual keying is used, both security gateways need to use the
     isakmpd(8) key management daemon. isakmpd(8) implements security policy
     using the KeyNote trust management system.

     To create a VPN between the same two C class networks as the example
     above, using isakmpd(8):

     1.   Create /etc/isakmpd/isakmpd.conf for machine A:

                # 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

     2.   Create /etc/isakmpd/isakmpd.conf for machine B:

                # 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

     3.   Read through the configuration one more time. The only real differ-
          ences 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 Authentication tag) must match between
          machineA and machineB.

          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".

                # chown root:wheel /etc/isakmpd/isakmpd.conf
                # chmod 0600 /etc/isakmpd/isakmpd.conf

     4.   Create a simple /etc/isakmpd/isakmpd.policy file for both machine A
          and machine B (identical):

                Keynote-version: 2
                Authorizer: "POLICY"
                Conditions: app_domain == "IPsec policy" &&
                            esp_present == "yes" &&
                            esp_enc_alg != "null" -> "true";

          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".

                # chown root:wheel /etc/isakmpd/isakmpd.policy
                # chmod 0600 /etc/isakmpd/isakmpd.policy

Configuring Firewall Rules

     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 enc(4) interface) or key management packets (for automated keying,
     UDP packets with source and destination ports of 500) should be allowed
     to pass.

     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 enc(4) interface.

     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 ad-
     dresses, depending on the network.

     The pf.conf(5) rules for a tunnel which uses encryption (the ESP IPsec
     protocol) and isakmpd(8) on security gateway A might look like this:

           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 \
                   to $GATEWAY_A port = 500
           pass out on $ext_if proto udp from $GATEWAY_A port = 500 \
                   to $GATEWAY_B port = 500

     The pf.conf(5) rules on security gateway B might look like this:

           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 \
                   to $GATEWAY_B port = 500
           pass out on $ext_if proto udp from $GATEWAY_B port = 500 \
                   to $GATEWAY_A port = 500

Enabling the Packet Filter

     Enable the packet filter and load the ruleset:

           # pfctl -e
           # pfctl -f /etc/pf.conf

Starting the Keying Daemon [automated keying]

     Start isakmpd(8)

     On both machines, run:

           # /sbin/isakmpd

     To run with verbose debugging enabled, instead start with:

           # /sbin/isakmpd -d -DA=99

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.

     Using the test setup, first check the routing table shows the routes
     between the two gateways.

     On GATEWAY_A:

      $ 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

     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 oppo-
     site would be true if netstat(1) were run on GATEWAY_B.

     Note that the routing table above is given for an automated keying ses-
     sion. SA information for a manual keying session would differ slightly:
     the "Type" field would be "require" for both directions.

     Next check that you can ping(8) the networks:

     On NETWORK_A:

           $ ping -I 10.0.50.1 10.0.99.1

     Note the -I option passed to ping(8): this is necessary to specify a
     source address from the network. Check that the ping(8) works from both
     NETWORK_A and NETWORK_B, changing the arguments as necessary.

     Check that the traffic between the two networks really is ESP encapsulat-
     ed. On GATEWAY_A:

           # tcpdump -n -i ne0 esp

     On NETWORK_A:

           $ ping -I 10.0.50.1 10.0.99.1

     Check that tcpdump(8) shows ESP packets whilst the ping is in progress.
     That shows that the traffic is IPsec encapsulated.

     If both networks are pingable, the routing tables look as described
     above, and tcpdump(8) is working as described, it means the VPN is work-
     ing 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.

     On GATEWAY_A:

           # tcpdump -n -i ne0 not esp and host 192.168.1.15

     On NETWORK_A:

           $ ping -I 10.0.50.1 10.0.99.1

     This time 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 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 sug-
     gested that the administrator review the steps above, paying particular
     notice to the firewall configuration procedures.

FILES

     /etc/isakmpd/isakmpd.conf      isakmpd(8) configuration file.
     /etc/isakmpd/isakmpd.policy    isakmpd(8) policy file.
     /etc/pf.conf                   Firewall configuration file.
     /usr/share/ipsec/rc.vpn        Sample VPN configuration file.

SEE ALSO

     netstat(1), openssl(1), sysctl(3), enc(4), ipsec(4), keynote(4),
     isakmpd.conf(5), isakmpd.policy(5), pf.conf(5), ifconfig(8), ipsecadm(8),
     isakmpd(8), pfctl(8), ping(8), sysctl(8), tcpdump(8)

MirOS BSD #10-current          February 9, 1999                              7

Generated on 2014-07-04 21:17:45 by $MirOS: src/scripts/roff2htm,v 1.79 2014/02/10 00:36:11 tg Exp $

These manual pages and other documentation are copyrighted by their respective writers; their source is available at our CVSweb, AnonCVS, and other mirrors. The rest is Copyright © 2002‒2014 The MirOS Project, Germany.
This product includes material provided by Thorsten Glaser.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report – diffs preferred.