Set up an IPSec VPN for Strongswan in CentOS 6.3

Set up an IPSec VPN for Strongswan in CentOS 6.3

I. Software Description

IPsec is a type of Virtual Private Network (VPN) used to establish an encrypted tunnel between the server and the client and transmit sensitive data. It consists of two phases: the first phase (Phrase 1, ph1), the exchange key to establish a connection, the use of Internet Key Exchange (ike) protocol; the second phase (Phrase 2, ph2 ), after the connection is established, data is encrypted and transmitted using the encapsulated Security load (esp) protocol. Refer to: IPsec entry in Wikipedia.

Different encryption methods (cipher suites) can be used in the first and second phases ). Even the first version of ike Protocol (ikev1) has two modes: main mode and active mode. The main mode performs six encrypted handshakes, the positive mode is not encrypted to achieve the goal of establishing a connection quickly.

The ike protocol in the first phase has two versions (ikev1/ikev2). Different open-source/closed-source software versions have different implementations, and different devices have different implementations. Then contact the various encryption methods used in the first or second phases to make the IPsec configuration a bit of a black magic, either completely understand, get through, or completely understand, copy.

Ii. device operating system specifications

The ike version used by the device/operating system and its special requirements are described here.

Linux

The command line client is strongswan itself, so it is perfectly compatible and supports the connection between ikev1/ikev2 and all encryption methods. Therefore, if you only use the Linux Command Line client and do not use any mobile devices or Windows, there is no such thing.

However, the Linux graphical interface client NetworkManager-strongswan currently only supports ikev2 connections and must be authenticated using certificates or EAP (supported by various encryption methods, including Microsoft's MSCHAPv2). It does not support pure passwords (PSK) authentication. This is not a strongswan error, or the technology is not good (Open Source is always at the forefront of the technology, after all, the command line is supported), but only reflects a choice: ikev1 is considered as the obsolete protocol by the strongswan project, and PSK encryption is considered very insecure. Refer to the strongswan wiki NetworkManager entry.

Android

Unlike Linux, Android only supports ikev1. Like Linux in other aspects, there are even many IPsec VPN configuration modes available.

IOS/Mac OS X

They declare that the used IPsec client is Cisco and the racoon is actually modified by themselves. It only supports the first version of ike Protocol, namely ikev1. It can be authenticated using a certificate or a pure password (PSK), but must be supplemented by xauth username/password authentication.

The modified version of racoon will give priority to the unencrypted positive mode, which is not supported by strongSwan. Therefore, the main mode is used.

IOS 6 also has a "tail" fault: it splits the data packet into small parts (fragmentation) during the first-stage handshake, and then "encrypts" The data packet. However, this type of encryption is only declared and is not actually encrypted. As a result, strongSwan and other standard server/Cisco devices cannot be decrypted. In addition, the fragmentation plug-in of ikev1 is closed-source. Open-source servers cannot reorganize these small blocks. Refer to: Cisco VPN stop working after upgrading to IOS 6

Therefore, a suitable method is to use a small certificate (less than 1024, usually 2048 by default) to avoid unpacking. However, the update of Mac OS X 10.7 blocks this method, learning that Microsoft has added certificate verification, and small certificates are rejected directly.

Fortunately, strongswan 5.0.2 has completed the fragmentation open-source implementation and the encryption of the iOS statement is not actually encrypted: IKE message fragmentation (cisco) + IOS 6.0 Hack for encrypted flaged ike fragmentation packets, the strongswan 4 patch can also be found in this link.

Windows

Microsoft is only a little worse than iOS. The advantage is that it supports ikev2, but only after Windows 7, and ikev1 is still used before Vista. The disadvantage is that its ikev2 support is very strange and Diffie Hellman group (DH, difi-Herman Key Exchange Group) must be modp1024. This is a rare encryption option that should not be concerned by the system administrator theoretically:

In strongswan, the syntax for defining phase 1 (ike) and Phase 2 (esp) encryption methods is:

Ike/esp = encryption-integrity [-dhgroup] [-esnmode]
Phase 1/Phase 2 = encryption method-Robustness authentication method (optional for the next two items) [-DH group] [-extended serial number support mode (RFC4304)]

Reference: IKEv2CipherSuites

Windows defines an optional option, which makes it necessary to define the encryption method for the entire first phase. This increases the possibility of cracking.

The second is its rekey (reconnect ). IPsec authentication has a validity period and will be re-authenticated if it exceeds the time limit. This CHILD_SA authentication can be issued by the server or by the client, generally by the server. However, ikev2 in Windows 7 shows that if you receive such a request on a vronat (NAT), the internal notification code of Microsoft will be sent, with the code 12345, after an error is detected in the strongswan project, this code indicates ERROR_IPSEC_IKE_INVALID_SITUATION. But it cannot be processed. It is not an error defined by the IPsec standard protocol.

There are two options:

One is to allow Windows 7 to actively rekey. Windows 7 rekey takes about 58 minutes and 46 seconds, so it takes longer to configure the server rekey. However, the effect is very poor. Because the rekey is controlled by three variables, the lifecycle of the key, the marginal time of the key (how long before the lifecycle rekey), and the marginal time error (rekeyfuzz ), the error is uncontrollable. Reference: ExpiryRekey.

Even if you can control the strongswan side, Windows is still "about"; even if both sides can control it, if the server delays rekey for one second, theoretically, if the connection lasts long enough, it will still crash: after 58x60 + 46 rekey attempts, the system crashed 146 days later and did not last for a year. The Linux Server obviously does not meet the requirements for Windows instances.

So currently, only the last method can be used to completely disable the server-side rekey.

Finally, its EAP authentication is also very bad. The eap identity of MSCHAPv2 is not an ikev2 identity (ikev2 identity is generally an EAP User Name). Therefore, you must explicitly define eap_identity on the server side to use the Windows 7 eap identity.

Iii. Software Installation

Software Installation is very convenient. Here we use the yum installation in the epel Repository

# Yum install strongswan

A command is ready for installation. Next, let's check which files are installed.

# Rpm-ql strongswan

Here I will not show what is available. Let's take a look at our main configuration files.

# Rpm-qc strongswan

Among them,/etc/strongswan/ipsec. conf is the main configuration file, and we mainly configure it.

Enable forwarding

# Echo 1>/proc/sys/net/ipv4/ip_forward

4. Software Configuration

1. Create a certificate. I will not demonstrate it here. You can refer to the following article.

Http://wangzan18.blog.51cto.com/8021085/1676529

Assume that all the certificates have been created. Put the certificates in the following directory.

#cp-rcacert.pem/etc/ipsec.d/cacerts/#cp-rserver.crt/etc/ipsec.d/certs/#cp-rserver.key/etc/ipsec.d/private/#cp-rclient.crt/etc/ipsec.d/certs/#cp-rclient.key/etc/ipsec.d/private/

2. Edit ipsec. conf

# Vim/etc/strongswan/ipsec. conf

configsetupuniqueids=neverconniOS_certkeyexchange=ikev1fragmentation=yesleft=%defaultrouteleftauth=pubkeyleftsubnet=0.0.0.0/0leftcert=server.crtright=%anyrightauth=pubkeyrightauth2=xauthrightsourceip=10.31.2.0/24rightcert=client.crtauto=addconnandroid_xauth_pskkeyexchange=ikev1left=%defaultrouteleftauth=pskleftsubnet=0.0.0.0/0right=%anyrightauth=pskrightauth2=xauthrightsourceip=10.31.2.0/24auto=addconnnetworkmanager-strongswankeyexchange=ikev2left=%defaultrouteleftauth=pubkeyleftsubnet=0.0.0.0/0leftcert=server.cert.pemright=%anyrightauth=pubkeyrightsourceip=10.31.2.0/24rightcert=client.crtauto=add

3. Explanation of the ipsec. conf configuration file

Among them, config setup can only appear once, while conn <connection name> can have many. The name here is not predefined and can be written at will, as long as you can identify it. It is mainly used to define a connection to make it easier to find in the log.

In the new version of strongswan, config setup does not have much content than in the old version, and many required options in the old version are voided. For example:

1. All ike protocols in the new version of plutostart are taken over by the daemon: charon of ikev2. There is no pluto at all.

2. All ike protocols in the new version of nat_traversal can traverse the router (NAT.

3. virtual_private defines the IP address of the server's LAN. It is now replaced by the magic word 0.0.0.0/0.

4. pfs is perfectly kept forward for rekey. This means that if your current key exchange process is broken, will it affect the exchanged key. In the past, it was generally set to no, which is applicable when a client such as iOS sends an unencrypted rekey request in positive mode. This option is useless now. The first stage is always the perfect forward secrecy. If the second stage (esp) is set to a DH group, the forward secrecy is also perfect, but the default encryption method has already specified the DH group. So this option is always yes.

In addition, the options of the old version and new version also define the default value, such:

1. Does strictpolicy require the Certificate Revocation List (CRL) URL. The default value is no.

2. Whether charonstart starts the daemon of ikev2. This was added in the old version, because the main force at that time was pluto. Now the default value is yes. If you change it to no, you cannot connect to the original pluto connection, because charon takes over the implementation of the ike protocol.

Therefore, config setup basically occupies a space. Here we modify the value of uniqueids to enable multiple devices to be online at the same time.

While conn mainly needs to understand the concept of left and right. In fact, the left and right sides can be separated. They are only used to represent the two ends of a connection. If you do not have a full definition, the left side will be considered as the Local Machine (your VPS) by default, and the right side will be his machine (your notebook) by default, that is, the left side will be regarded as the statue.

1. left/right is the left and right id. They are used to identify servers/clients. They can be certificate alias (DN), such as "C = CN, O = strongSwan, CN = strongSwan CA" or IP addresses, it can also be the username of EAP, or the magic word % any, indicating everything. If % any is defined for the local machine before 5.0.0, The ikev1 connection, that is, the keyexchange = ikev1 connection, cannot be identified. Therefore, you need to change it to % defaultroute to get the IP address from ifconfig. This method is used to distinguish it from % any of right. So the last two options seem useless. But they are required.

2. leftauth/rightauth is the most important change. The new version mainly voided the previous options of authby and xauth = server/client, and switched to this method. Therefore, ikev1 can also be used for mixed-race authentication (the authentication methods on both sides are different. The pubkey indicates the certificate, psk indicates the password, and eap indicates the Extended Authentication Protocol.

3. leftau2and rightau2are used to cope with the common old versions of authby = xauthpsk/xauthrsasig. Now xauth can only be written here. Psk corresponds to the PSK method in leftauth/rightauth, and rsasig corresponds to the pubkey method.

4. leftsubnet introduces the magic word 0.0.0.0/0. If you assign a virtual IP address to the client on the right side, it means you will do iptables forwarding later, then the magic word must be used on the left side.

5. leftcert/rightcert indicates the Certificate Name.

6. The virtual IP segment allocated by rightsourceip for the client.

7. auto defines the connection behavior when strongswan starts. "Start" means "start", "route" means "add route table", and "add" means "add connection type" but "do not start", and "ignore" means "ignore" means "not exist. The default value is ignore. It seems that route is better, but the problem is that we cannot pre-allocate virtual IP addresses on the server side, so the server side generally uses add. You can select start for client text configuration.

In addition, let's talk about the old version of xauth = server/client. It indicates whether xauth is performed on the server or on the client. The new version is mainly reflected in the left and right directions. For example, if you perform authentication on the server, the authentication request is sent by the client, so you need to write rightau2= xauth. If the authentication is performed on the client, the authentication request is sent by the server, so leftau2= xauth is required.

Another common configuration option on the internet is leftfirewall = yes. This is totally wrong. It seems that its only function is to define whether your server is behind the firewall, but it is actually developed as a parameter of the ipsec_updown script, indicates whether your local subnet is forwarded/disguised using iptables. If yes, call the script in the path defined by left/rightupdown. The script uses iptables to exempt packets connected through ipsec.

The reason for this error is outrageous (although there is no impact), because these people do not understand it at all, and subnet of servers with public IP addresses is rarely disguised. In addition, it makes sense to write the script option. No one who has read this option has written the script. Also, leftsubnet = 0.0.0.0/0 defines subnet as any through magic words, and you cannot write scripts at all. So we don't need it here.

For a certain type of connection, it is mainly defined according to the device specification. Some special options are described as follows:

1. fragmentation = yes enables the iOS package reorganization support.

2. ike = aes256-sha1-modp1024! The first-stage encryption method specified by Windows.

3. If the rekey = no server sends a rekey request to Windows, the connection is closed.

4. rightsendcert = never because it is a hybrid connection. The server uses a certificate to authenticate its own identity, while the server uses a eap-mschapv2 to authenticate the client. If this parameter is not set, ifasked is used by default. This means that if the server requests a certificate from the client, the client will give it, but the client cannot provide the certificate, and the connection will be disconnected. The setting here is that the client never gives it. In fact, it means that the server does not request a certificate from the client.

5. eap_identity = % any uses Windows eap identity. Otherwise, the "no eap key found for host <rightid>" error will occur.

4. ipsec. secrets Configuration

This file does not exist by default. I will create it myself.

# Vim/etc/strongswan/ipsec. secrets

:RSAserver.pem:PSK"myPSKkey":XAUTH"myXAUTHPass"[User name] % any: EAP"[Password]"

Change the above myPSKkey word to your key for the PSK authentication method;
Change the above myXAUTHPass word to the password required for the XAUTH authentication method. The user name for this authentication method is random;
Change the [user name] To the login name you want and the [Password] to the password you want (remove the [] symbol). You can add multiple lines to obtain multiple users, this is the credential used for user name and password authentication of IKEv2.

: PSK "PSK password" equivalent to: % any: PSK "PSK password"

Follow the format of "host peer: Method <Local Certificate/Protocol Password> <local certificate password>. The Division is set to: Fill the passwords from left to right. Except for missing passwords, % any is used to fill in null. (How can the password be % any ).

5. strongswan. conf configuration

# Vim/etc/strongswan. conf

charon{load_modular=yesduplicheck.enable=nocompress=yesplugins{includestrongswan.d/charon/*.conf}dns1=114.114.114.114nbns1=114.114.114.114}includestrongswan.d/*.conf

Dns can be changed to the dns you want to use. You can add two dns1 dns2

5. Start the service

# Service strongswan start

Then we can use our cell phone to connect.

Vi. Client settings

IOS

Send the CA certificate and the pkcs12 (. p12) You have prepared to yourself. Receive emails on iOS and import the two. Create an IPSec VPN:

• All servers are IP addresses or URLs.

• The two accounts and passwords before and after XAUTH in ipsec. secrets

• If you want to use the certificate, select the one you just used. Otherwise, enter the PSK password set in ipsec. secrets without using the certificate.

AndroidIPSec Xauth PSK

Mainly:

• All servers are IP addresses or URLs.

• IPSec pre-shared key: enter the password next to the PSK in ipsec. secrets.

Then, the two usernames and passwords before and after XAUTH are used for logon.

"StrongSwan VPN Client" for Android 4.0 (ICS) +

This is an official client, which is available on Google Play.

Send a prepared pkcs12 email to yourself. In fact, pkcs12 contains the CA certificate. iOS requires the CA certificate to be imported only when there is a bug (despise it ). Android is not required. Click In GMail and you will be prompted for import.

Open the official client and create a solution:

• Gateway is the server, same as above

• Select IKEv2 Certificate for Type.

• User certificate select the one you just imported

• Cancel automatic selection of CA certificate, and then select

For Windows clients, we recommend pptp or l2tp openvpn.

VII. Problem debugging

If there is no special need, the server logs are enough to detect the sources of most problems.

Log reading skills

After the charon daemon of strongswan is started, it will initialize and load the previously defined conn. This part of log does not need to be read. Of course, it may be necessary when you have a configuration problem, but when there is a configuration problem, service strongswan start will fail, and strongswan status will point out the row number where your configuration problem is located (=. = )...

Server debugging

/Var/log/strongswan-charon.log File

Debug logs need to be enabled in/etc/strongswan. d/charon-logging.conf

IOS debugging

Install iFile in jailbreak mode. Edit the/etc/racoon. conf file, find the # log debug; field, and change it:

logdebug;pathlogfile"/var/log/racoon.log";

Save.

Android debugging

• The official strongSwan client provides the Log Viewing function.

• The VPN debugging method for android is as follows:

Open terminal simulator, enter su, and the super user will pop up.

cd/storage/sdcard0logcat-f./log.txt

Then, use Airdroid and other tools to upload the log.txt in the SD card to the computer and open the search VPN.

VIII. Summary

After my tests, I have tested only IOS 8 and Xiaomi Note for Android phones. They all use xauth authentication and do not use certificates. My Xiaomi Note can be connected, however, there is a problem with page loading. Check the log. It is the android_xauth_psk connection used, and no cause is found. The same configuration uses IOS connection, because we use the IPSec VPN connection that comes with IOS, and do not use the certificate, the parameter is the same as the connection of Android. Because the certificate is not used, the connection android_xauth_psk is identified, however, access is normal.

More please follow the http://www.wzlinux.com or http://www.wzlinux.com: 45/

If you have any questions, please join us.