The information in this document applies to the following NetBSD kernel: NetBSD-current as of may 2005 or above NetBSD-3.0_BETA as of may 2005 or above The information in this document applies to the following userland (&man.setkey.8;, &man.racoon.8;, &man.racoonctl.8; and libipsec): NetBSD-current as of may 2005 or above NetBSD-3.0_BETA as of may 2005 or above Earlier NetBSD releases with the ipsec-tools 0.6.beta2 package or above from NetBSD's pkgsrc Many organisations have a Remote Access Server (RAS) providing users a remote access to the internal network through modem connections over the Plain Old Telephone System (POTS). With the raise of high bandwidth connections like Digital Subscriber Line (DSL) and cable, using POTS for the remote access is getting obsolete, and users want a high bandwidth remote access. Using Virtual Private Networks (VPN) is a solution to this problem. User authentication for VPN access can be done by different methods: Group password (all users have the same password) Login and password x509 certificate Group password is a weak solution and should not be used, because users are not really authenticated. x509 certificate gives you the highest security, but user certificates might be troublesome to manage. If you can afford it, then everything you need to know is in the IPsec FAQ. Login and password are an average security level. Because passwords can be guessed or disclosed by another protocol (e.g.: POP3 without SSL), it is not highly secure, but it can be made reasonably secure if strong passwords are enforced and if the protocol used ensures they cannot be sniffed. This HOW-TO covers the situation where login and password are to be used for remote user VPN access. In order to establish a secured VPN, the remote user must authenticate to the VPN gateway, and the VPN gateway must authenticate to the remote user. If the mutual authentication is not performed, then there is a loophole open for Man in the Middle (MiM) attacks, where an attacker can masquerade as the VPN gateway and collect user passwords. We said the remote user will authenticate using login and password. How can the VPN gateway authenticate? If a pre-shared key is used, then anyone knowing the key will be able to masquerade as the VPN gateway, and all the legitimate users will have to know about the pre-shared key. This is really weak security. The alternative is to use a x509 certificate on the VPN gateway. This is a server certificate, which is much easier to manage than user certificates. We will assume a certificate is used to authenticate the VPN gateway. We want user authentication using a login and a password, and VPN gateway authentication using a certificate. There are not many solutions available. OpenVPN is a Secure Socket Layer (SSL) based solution that is able to do what we want. An alternative is to use IPsec, which is what we will cover here. IPsec phase 1 is part of the IPsec Key Exchange (IKE) operations performed by the IKE daemon, also known as &man.racoon.8; in NetBSD. Its goal is to authenticate the peers and set up master keys for performing a secured IPsec phase 2. The goal of phase 2 is to derive the keys used for exchanging IPsec traffic. Phase 2 rekeying can occur regularly while IPsec traffic is exchanged. IPsec phase 1 offers two authentication methods: pre-shared keys and certificates. This is not what we want because pre-shared keys are not bound to logins. We have no management tools to handle them properly, leaving a group password as the only manageable option. IPsec phase 1 authentication is supposed to be symmetric: pre-shared keys on both endpoints or certificates on both endpoints. This is not what we are looking for. Xauth is an IKE extension that occurs after phase 1 and adds a login/password authentication. This solves half of the authentication problem: because Xauth occurs just after phase 1, it is secured by phase 1 authentication. You still need a pre-shared key or a certificate in phase 1. Using a pre-shared key is not secure, and using a certificate means you use user certificates, which is something we wanted to avoid. Hybrid auth is another IKE extension, that makes phase 1 asymmetric. During phase 1, the VPN gateway can use a certificate, while the remote user does not have to authenticate. After phase 1 we are in a situation where: Remote user knows it speaks to the VPN gateway Communications between the remote user and the VPN gateway are secure The VPN gateway has no idea about who it is talking with After this phase 1, an Xauth exchange can occur to securely authenticate the remote user. Then phase 2 can take place. The security level of IPsec + Xauth + Hybrid auth is roughly equivalent to SSH using password authentication. So our authentication problem is solved by using IPsec + Xauth + Hybrid auth. In order to make the thing really user friendly, we need to make the remote user machine configuration automatic. ISAKMP mode config is an IKE extension that enable the VPN gateway to provide the network configuration for the remote user's machine: Internal IP address, DNS address, domain name, and so on. The remote user might be hidden behind a Network Address Translator (NAT), which will not work when using IPsec encrypted streams. When traffic has to be encrypted, IPsec uses a layer 4 protocol known as Encapsulated Security Payload (ESP). Unlike TCP or UDP, ESP has no port number and cannot easily be handled by NAT devices. RFC 3947 and 3948 describe a method to encapsulate ESP in UDP, and IKE extensions to manage NAT in between endpoints of IPsec streams. The encapsulation method and IKE extensions are together known as NAT Traversal (NAT-T). NAT-T might be encumbered by a US patent. Remote users will often connect from behind DSL modem-router appliances. Most of these devices are utterly broken when dealing with big UDP packets: they assume UDP can only be used for DNS requests and will drop bigger or fragmented UDP packets. IKE transactions and ESP over UDP will tend to use big UDP packets, and will therefore be blocked. In order to address that problem, we use IKE fragmentation, which is an IKE extension used to fragment the IKE packets into smaller fragments. ESP fragmentation addresses the problem of big ESP over UDP packets, by performing IP fragmentation before the ESP encapsulation: instead of sending frag(IP/UDP/ESP/IP) on the network, we send IP/UDP/ESP/frag(IP). Devices between the IPsec endpoints therefore do not see any fragmented packets. Last problem: the remote user Internet connection can be unstable, leading to spurious disconnections. The only built-in mechanism IPsec has to handle that is to force IKE phase 2 rekeying after some time. If the peer is not on-line anymore, it will fail, thus causing the VPN tunnel to be destroyed. This is not very convenient as it forces frequent rekeying to detect that the remote user got off-line. Dead Peer Detection (DPD) is an IKE extension used to regularly probe the remote IPsec endpoint for activity. DPD can be used to detect that the remote host went off-line within a few seconds. Here is a setup example for a VPN gateway using IPsec + Xauth + Hybrid auth + ISAKMP mode config + NAT-T + DPD + IKE fragmentation + ESP fragmentation. First you need to build and install a kernel with at least the following options: options INET options GATEWAY options PFIL_HOOKS options IPSEC options IPSEC_ESP options IPSEC_NAT_T pseudo-device ipfilter You need to enable IPv4 packet forwarding, by using the following command: # sysctl -w net.inet.ip.forwarding=1 This can be automatically executed on reboot by adding this line to /etc/sysctl.conf: net.inet.ip.forwarding=1 If you have not already configured OpenSSL, start by installing the sample config file: # cp /usr/share/examples/openssl/openssl.cnf /etc/openssl/ Then create a private key and use it to create a Certificate Signing Request (CSR): # cd /etc/openssl # umask 077 # openssl genrsa > certs/vpngw.key # umask 022 # openssl req -new -key certs/vpngw.key -out certs/vpngw.csr Send the CSR, vpngw.csr to a Certificate Authority (CA) for signature. You will get a x509 certificate, that we shall name vpngw.crt If you want to be your own CA, then perform the following steps to generate the CA private key and certificate, and to sign your CSR: # cd /etc/openssl # mkdir -p demoCA/newcerts # touch demoCA/index.txt # echo "00" > demoCA/serial # umask 077 # openssl genrsa > certs/ca.key # umask 022 # openssl req -days 3650 -x509 -key certs/ca.key -new > certs/ca.crt # openssl ca -in certs/vpngw.csr -keyfile certs/ca.key -cert certs/ca.crt -out certs/vpngw.crt Keep the secret keys secret, as your VPN will not be secure anymore if they get disclosed. Give the CA certificate ca.crt to remote users, and move to the next step. Here is a sample /etc/racoon/racoon.conf file: path certificate "/etc/openssl/certs"; listen { adminsock disabled; } remote anonymous { exchange_mode aggressive; certificate_type x509 "vpngw.crt" "vpngw.key"; my_identifier asn1dn; proposal_check claim; generate_policy on; # automatically generate IPsec policies dpd_delay 20; # DPD poll every 20 seconds nat_traversal force; # always use NAT-T ike_frag on; # use IKE fragmentation esp_frag 552; # use ESP fragmentation at 552 bytes proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method hybrid_rsa_server; dh_group 2; } } mode_cfg { network4 10.99.99.1; # 1st address of VPN IPv4 pool pool_size 253; # size of the VPN IP pool: 253 addresses auth_source system; # validate logins against /etc/passwd dns4 10.0.12.1; # IPv4 DNS server wins4 10.0.12.1; # IPv4 WINS server banner "/etc/racoon/motd"; # Banner message for clients pfs_group 2; } sainfo anonymous { pfs_group 2; lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } The mode_cfg section defines the configuration sent from the VPN gateway to the client using ISAKMP mode config. For now only IPv4 configuration is supported. The VPN address pool is defined there, by a base address (network4) and a pool size (pool_size). auth_source explains how the login and password are validated. Possible values are system, to validate against the system user database, pam to use the Pluggable Authentication Module (PAM) system (/etc/pam.d/racoon will be used), and radius to validate logins against RADIUS. Once your /etc/racoon/racoon.conf file is ready, you can launch &man.racoon.8;: # racoon In order to have &man.racoon.8; started up at boot time, you need the following in /etc/rc.conf: racoon=YES In the configuration sample, esp_frag is specified so that ESP fragmentation is used to avoid sending packets bigger than 552 bytes. 552 bytes is quite low, but it should work with the most broken DSL modem-routers appliances. The higher esp_frag is, the better the performances are. Using ESP fragmentation, it is possible to exchange IP packets of any size through the tunnel. However, there is a special case for TCP, which may have trouble with Path Maximum Transmission Unit (PMTU) discovery. The solution is to use Maximum Segment Size (MSS) clamping. This can be done in /etc/ipnat.conf, assuming your VPN internal address pool is 10.99.99.0/24: map ex0 10.99.99.0/24 -> 0/0 mssclamp 512 And type the following to enable that configuration: # ipf -E; ipnat -f /etc/ipnat.conf In order to have those commands executed on startup, you need the following in /etc/rc.conf: ipfilter=YES ipnat=YES Note that the system will not boot with ipfilter=YES if the /etc/ipf.conf file is missing. You can create a blank file if you do not need any IP filtering. In this VPN solution, the client needs to send UDP packets to ports 500 and 4500 of the VPN gateway. The first packets are exchanged on port 500, then NAT-T negotiation moves the transaction to port 4500. Firewalls in front of the VPN gateway must be configured to let udp/500 and udp/4500 pass through to the VPN gateway. RADIUS can be used for login validation, IP addresses allocation and accounting. Here is a sample mode_cfg section for /etc/racoon/racoon.conf that enforces RADIUS usage: mode_cfg { pool_size 253; # IPv4 pool size auth_source radius; # login validated against RADIUS conf_source radius; # IPv4 address obtained by RADIUS accounting radius; # RADIUS accounting dns4 10.0.12.1; # IPv4 DNS server wins4 10.0.12.1; # IPv4 WINS server banner "/etc/racoon/motd"; # Banner message for clients pfs_group 2; } Additionally, you need to create a /etc/radius.conf file that contains the RADIUS server address and the secret shared with the RADIUS server. This file must be owned by root and mode 0600 in order to keep the shared secret secure. Here is an example, see &man.radius.conf.5; for the details: auth radius.example.net MyDirtySecret acct radius.example.net MyDirtySecret The VPN gateway setup presented in the previous section is interoperable with the Cisco VPN client configured in mutual group authentication (this is a synonym for Hybrid authentication). The group and group password required by Cisco VPN client are ignored by &man.racoon.8;, but that does not make user authentication unsecure. Do not forget to set up the client with IPsec over UDP transport to get NAT-T enabled. It is also possible to use &man.racoon.8; as a client. You need to install the CA certificate in /etc/openssl/certs/ca.crt, and the configuration below in /etc/racoon/racoon.conf path certificate "/etc/openssl/certs"; path pre_shared_key "/etc/racoon/psk.txt"; listen { # socket used for communication between racoon and racoonctl adminsock "/var/racoon/racoon.sock" "root" "operator" 0660; } # Here is the address of the VPN gateway remote 192.0.2.50 { exchange_mode aggressive; ca_type x509 "ca.crt"; proposal_check obey; mode_cfg on; # accept config through ISAKMP mode config dpd_delay 20; nat_traversal force; ike_frag on; esp_frag 552; script "/etc/racoon/phase1-up.sh" phase1_up; script "/etc/racoon/phase1-down.sh" phase1_down; passive off; proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method hybrid_rsa_client; dh_group 2; } } sainfo anonymous { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate ; } The phase1-up.sh and phase1-down.sh scripts are called when the IKE phase 1 is established and terminated, that is, at VPN connection and disconnect time. They are responsible for setting up and deleting the IPsec Security Policies (SP), VPN IP address, and routing entries. The sample scripts should do what you need, but you can customize them to fit your particular needs. # cp /usr/share/examples/racoon/roadwarrior/client/*.sh /etc/racoon/ Once this is ready, you can start &man.racoon.8;: # racoon In order to have it started at boot time, add racoon=YES to /etc/rc.conf. racoonctl(8) can be used to connect to the VPN and to disconnect from it. The login is given through the -u option and the password is prompted on the terminal: $ racoonctl vc -u username 192.0.2.50 Password: password Bound to address 10.99.99.3 ========================================================== Flying pigs LTD Welcome to our internal network, remote user. ========================================================== $ racoonctl vd 192.0.2.50 VPN connection terminated DNS addresses can be used instead of IP addresses in this example. Note that if for some reason the routing entries or Security Policy Database (SPD) get screwed, the DNS resolution will not work at VPN disconnect time. To recover from such a situation, type the following commands as root: # setkey -F # setkey -FP # route flush # route add default your_default_gateway Anyone with read/write rights to the &man.racoon.8; socket /var/racoon/racoon.sock can start or stop the VPN. The ownership and rights to the socket can be set using the adminsock statement in the listen section of /etc/racoon/racoon.conf. If you want to avoid typing the Xauth password, you can store it in racoon's Pre-Shared Key (PSK) file. Add the following statement in the remote section of /etc/racoon/racoon.conf: xauth_login "username"; Then add a line in /etc/racoon/psk.txt with the login and the password: username password With that setup, this command will establish the VPN connection using the toto login, without prompting for a password: $ racoonctl vc 192.0.2.50