User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
doc:howto:vpn.ipsec.roadwarrior [2012/12/24 16:12]
miceliux Add dpd_delay option
doc:howto:vpn.ipsec.roadwarrior [2015/09/25 17:03] (current)
rajl [For iPhones/iOS Clients]
Line 1: Line 1:
-====== IPSec Road Warrior Configuration ======+====== IPSec Road Warrior Configuration: Android, Windows 7, BB10, PlayBook Clients ​====== 
 +| For an overview over all existing Virtual private network (VPN)-related articles in the OpenWrt wiki, please visit [[doc/​howto/​vpn.overview]] | 
 +:!: This page is about strongswan. The old racoon documentation can be found [[vpn.ipsec.roadwarrior.racoon|here]].
-In the last years SSL VPN Networks made a good job in replacing classic IPsec road warrior clients. Although having some drawbacks a combination ​of the free [[http://​|ShrewSoft VPN client]] with an IPsec central site getway still does a good job. As a matter ​of form this article expands the possible VPN setups to a new scope. Once again you should have some know how of the [[vpn.ipsec.basics|basic]] and [[vpn.ipsec.firewall|firewall]] setup.+Most of the racoon information is relevant (sort-of)
-===== IPSec Road Warrior Configuration =====+The basic context of the "road warrior"​ configuration:​ 
 +  - Your OpenWrt router is the HOST or gateway that receives requests to connect from mobile users, or clients. 
 +  - The clients have a dynamically assigned (private) IP outside your private net which changes. 
 +  - The clients frequently move around. 
 +  - The clients require access to both internal and external resources (full tunnel support) through a "​gateway"​.
-Contrary ​to the previous articles about [[vpn.ipsec.site2site|site to site]] neworks we want to allow different computers ​with a locally installed IPsec client access to the network behind the OpenWrt router. A picture will give a helpful overview.+Examples would be a phone or laptop that wants to VPN into a home network. 
 +Note that Strongswan'​s IKEv2 with MOBIKE lets you leave VPN up ALL the time on phone with near zero battery drain or perceptible performance hit. The benefits of this cannot be overstated for the roadwarrior.
-The most important facts are:+This configuration uses TWO authentication mechanismscertificates and a username/​password challenge (EAP) for an added layer of security. This is an IKEv2 setup. Everything else in my opinion is obsolete and should not be used. IKEv2 is built-in to Windows 7 and Blackberry. It's added to Android using the Strongswan client. ​
-  ​To make it not too easy we once again want to provide access to two different company networks. ACME LAN with addresses and ACME DMZ with​26.  +===== Prerequisites ===== 
-  * A laptop that connects to a VPN network is assigned a "​secondary VPN inside IP" on a virtual VPN adapterOur roadwarriors should get IP addresses from the range way they can reach the normal outside network when using the primary network adapter ​and the company network through their virtual address 192.0.2.X. In case you are not familiar ​with private IP address ranges you should have look in [[http://​​wiki/​IPv4|Wikipedia]]. If you are in the wild your laptop very often gets DHCP addresses from the most common private networks (, or​16). To avoid routing conflicts between the locally connected and the VPN network this special test network has proven to be the best choice for VPN configurations.+  ​Supported version of OpenWrt (opkg will complain about kernel version if not)
 +  * Strongswan-Full 5.x.x (tested to 5.0.4-1 as explained, ​and to 5.1.1-1 with some slight config modifications) 
 +  * OpenSSL (to make the .p12 or PKCS#12 package you distribute to clients)
 +Tested on OpenWrt Barrier Breaker r37092-r39879 on WNDR3700v2. ​ (Strongswan did not install on 34054 for me).
 +To make sure Strongswan runs, you can type 
 +''/​etc/​init.d/​ipsec start''​
 +For testing, you will want to run logread in a scrolling window as follows:
-===== Authentication =====+''​logread && logread -f''​
-We already learned that site to site IPsec tunnels use authentication based on preshared keys or certificatesBoth of them share a small imperfection when used for roadwarriors - they have no user related secretWhen the administrator installs the VPN client he stores the preshared key or the certificate on the road warrior laptopSo any user that has access to the laptop ​and the stored data can connect to the company networkThis encourages a two way authentication process. After phase 1 has completed the user should be asked for a password. The hybrid IPsec authentication process (also called Xauth) provides what we need. +We're going to edit the following:​ 
 +  * **/​etc/​strongswan.conf**: Strongswan configuration file  
 +  * **/​etc/​ipsec.conf**: Tunnel definitions 
 +  * **/​etc/​ipsec.secrets**: List of secrets ​and keys 
 +  * **/​etc/​ipsec.d**: Folder ​for certificates 
 +  * **/​etc/​config/​firewall**:​ Firewall changes to allow VPN traffic
-Let us start with the user road warrior database ​that is stored ​in UCI file [[doc:​uci:​users|/​etc/​config/​users]]Have look over there for further detailsAs an example we create user otto and enable him for IPsec.+ 
 +===== strongswan.conf ===== 
 +charon { 
 +        threads = 16 
 +        dns1 = 
 +        nbns1 = 
 +pluto { 
 +libstrongswan { 
 +        crypto_test { 
 +                on_add = yes 
 +        } 
 +Starting ​with StrongSwan 5.1.1 (or perhaps earlier), you may find that charon plugins are not loading dynamically. If you find this to be true (or its just not working, which you can spot by changing charondebug ​in ipsec.conf), try explicitly telling charon which plugins you want by adding "load = ..." to charon like this:
 <​code>​ <​code>​
-config '​user'​ +charon { 
-  ​option '​enabled'​ '​1'​ +load = aes des sha1 sha2 md5 pem pkcs1 gmp random nonce x509 revocation hmac stroke kernel-netlink socket-default updown attr farp dhcp 
-  ​option '​name'​ '​otto'​ +.....
-  option '​password'​ '​this_is_ottos_password'​ +
-  option '​xauth'​ '​1'​+
 </​code>​ </​code>​
 +The above issue seems to have been resolved in 5.1.2 according to the 
 +[[https://​​projects/​strongswan/​wiki/​PluginLoad|Wiki here.]]
 +''​charon''​ is the IKEv2 daemon. ''​pluto''​ is the IKEv1 daemon which we won't use. Replace the IP addresses with the appropriate values for your INTERNAL network. In this and other examples, I expect your private internal network to be​24.
 +"​dns1"​ entry tells ''​charon''​ (the IKEv2 service) where to go for dns - typically the openwrt host.
 +"​nbns1"​ entry tells ''​charon''​ where to go for netbios name services if you want to use windows file sharing.
-**Attention**:​ This user database combined with preshared key authentication depends ​on three prerequisites:+Note that the ''​crypto_test''​ option for ''​libstrongswan''​ is added to tell Strongswan to test its crypto algorithms ​on initialization. You can read more here: [[http://​​projects/​strongswan/​wiki/​CryptoTest]]
-  * [[http://​​patch/​1561/​|racoon user database patch]] **not yet in trunk**. It allows racoon to read users and their passwords from a plain file. +===== ipsec.conf =====
-  * [[vpn.ipsec.basics#​ike.daemon|racoon start script]] of at least version 13. Generates a user/​password file from /​etc/​config/​users. +
-  * [[https://​​browser/​packages/​net/​ipsec-tools/​patches/​001-ipsec-tools-def-psk.patch?​rev=28102|racoon patch]] that allows racoon to accept road warrior connections with one single preshared key.+
 +Note that this is a certificate-based configuration with an additional username/​password challenge. It REQUIRES you to put certificates on the server and clients, as well as have clients supply username and password. ​
-If you cannot compile racoon with those patches yourself you have to wait until both of them are in trunk. A workaround could be users stored in /etc/passwd but this is something that we normally do not want. Other ways are LDAP or Radius.+<​code>​ 
 +config setup
-===== Security policies =====+conn %default 
 + ​keyexchange=ikev2
-Until now we always had defined tunnel endpoints for site to site IPsec connectionsSo we could generate security policies in advanceWith a road warrior setup this is no longer possibleBut that is no problem at allPre loaded security policies in the kernel are only important to open VPN tunnels from the OpenWrt router to a remote VPN routerIf they are not available the device will simply send packets into the internet without encryptionIn our case the tunnel will be established by a remote laptopAfter the tunnel is active racoon can generate the required policies+conn roadwarrior 
 + ​left=%any 
 + ​leftauth=pubkey 
 + ​leftcert=serverCert.pem 
 + ​ 
 + ​leftsubnet=,::/0 
 + ​leftfirewall=yes 
 + ​right=%any 
 + ​rightsourceip= 
 + ​rightauth=pubkey 
 + ​rightcert=clientCert.pem 
 + ​rightauth2=eap-mschapv2 
 + ​auto=add 
 + ​esp=aes-aes256-sha-modp1024,​aes256-sha512-modp4096 
 + ​ike=aes-aes256-sha-modp1024,​aes256-sha512-modp4096
-Or to explain it the other way roundAll laptops will be assigned IP addresses of a predefined rangeIf we would create a security policy ​that routes all of the traffic ​of this range into one tunnel we cannot have more than one connected machineInstead each tunnel ​will only route traffic ​for single ​IP addressThis is the simple difference between ​site to site and a road warrior configuration.+</​code>​ 
 +The notion of "​left"​ and "​right"​ is explained in the strongswan documentation,​ but briefly, "​left"​ here is the "​Local"​ (Left = Local) or private net you want access ​to, and "​right"​ is the "​Remote"​ (Right = Remote) or client side. 
 +  * The ''​config setup''​ block is needed but can be empty 
 +  * The ''​conn %default''​ block provides default settings if you plan on adding more profiles. 
 +  * ''​conn roadwarrior''​ is our roadwarrior configuration. 
 +  * ''​leftauth = pubkey''​ tells the host to use certificates. 
 +  * ''​leftid =''​ the FQDN you put in the cert as subjectAltName (see "​--san"​ option when you make your certs below). Note that it could be anything as long as it matches. Use of dyndns (in example) is advised if your gateway is also assigned a dynamic address. 
 +  * ''​leftsubnet ='' ​the scope of VPN0.0.0.0/0 is a full tunnel, meaning ALL traffic ​will go through the VPN. You can put if you want your client to use the VPN to reach ONLY those addresses and your private net is​24. The full tunnel option is more secure because it prevents ​client from acting as a bridge. 
 +  * ''​right = %any''​ - lets any peer IP connect(remote user) 
 +  * ''​rightsourceIP''​ = The pool of internal addresses to use for the VPN clients. Note that if you have only ONE client connecting, you could use​32 as an example, which means that only 1 host can connect and it will be given the address You may want to assign IPs from subnet which doesn'​t overlap neither your home nor your guest'​s LAN. 
 +  * ''​rightcert = ''​ the cert the client needs 
 +  * ''​rightauth = pubkey''​ Tells the client ​to use certificates. 
 +  * ''​rightauth2 = eap-mschapv2''​ tells the client to use a second challenge: username ​and password. 
 +  * ''​esp''​ and ''​ike''​ specify the cipher suites, and the dh group which is required for PFS. Note that the PFS directive has been deprecated. Google "​Perfect Forward Secrecy"​ for details - you want this.["​Deprecated"​ -That means you shouldn'​t be using it typically because it is dangerous, outdated, or because ​better alternative existsIf anyone else can edit this to spellout precisely why we should google and what we're looking for, would be appreciated]
-What is important for us? Nothing - just a little background information. Our racoon start script will take care of the different variants.+If you want to issue personal certificates to your clients then you should verify the signing CA's identity instead ​of the client certificates itself. To achieve this, use the ''​rightca''​ directive instead of ''​rightcert''​. More information on this: [[http://​​projects/​strongswan/​wiki/​ConnSection|strongSwan documentation]]
-===== Split Tunnel ​=====+===== ipsec.secrets ​=====
-Split tunnel describes the fact, that a connected laptop will only send VPN related traffic through the tunnelAll other request will go directly ​to the internetThis may be a potential security risk and very often VPN laptop clients will route all traffic into the tunnelAt the current development state only a split tunnel setup is possible. The two main reasons are:+<​code>​ 
 +: RSA serverKey.pem 
 +remoteusername : EAP "​secretpassword"​ 
 +The first line defines the key to use and the second line is for the username/​password challenge (EAP). 
 +Replace ''​remoteusername'' ​and ''​secretpassword''​ with the values you want.
-  * Split tunnel will save bandwidth of the central side OpenWrt gateway. Otherwise each packet from the laptop to the internet has to pass the tunnel before the gateway will sent it to the outside world. +===== Making Keys =====
-  * It requires less routing and firewall policies on the gateway. ​+
-But we just have startedMaybe someone has time to implement and document it.+To make keys, run this script: 
 +ipsec pki --gen --outform pem > caKey.pem 
 +ipsec pki --self --in caKey.pem --dn "C=US, O=xxx, CN=xxxx"​ --ca --outform pem > caCert.pem 
 +ipsec pki --gen --outform pem > serverKey.pem 
 +ipsec pki --pub --in serverKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn "C=US, O=xxx,"​ --san="​"​ --flag serverAuth --flag ikeIntermediate --outform pem > serverCert.pem 
 +ipsec pki --gen --outform pem > clientKey.pem 
 +ipsec pki --pub --in clientKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn "C=US, O=xxx, CN=client"​ --outform pem > clientCert.pem 
 +openssl pkcs12 -export -inkey clientKey.pem -in clientCert.pem -name "​client"​ -certfile caCert.pem -caname "​xxxx"​ -out clientCert.p12 
 +# where to put them... 
 +mv caCert.pem /​etc/​ipsec.d/​cacerts/​ 
 +mv serverCert.pem /​etc/​ipsec.d/​certs/​ 
 +mv serverKey.pem /​etc/​ipsec.d/​private/​ 
 +mv clientCert.pem /​etc/​ipsec.d/​certs/​ 
 +mv clientKey.pem /​etc/​ipsec.d/​private/​ 
 +mv caKey.pem /etc/ipsec.d/​private/​ 
-===== Naming Services =====+Now install clientCert.p12 on the clients.
-Being connected to the company network it is helpful to have a working name resolution for internal hostnames. We want to use a central configuration and free the road warriors from manual DNS setup. Racoon allows to push the DNS configuration to the IPsec client after connection has been established. Our [[vpn.ipsec.basics#​ike.daemon|/​etc/​init.d/​racoon]] start script takes care of that if we make a proper configuration. Therefore insert the **dns** and **domain** options into the racoon secion of [[doc:​uci:​racoon|/​etc/​config/​racoon]].+===== /​etc/​config/​firewall =====
 +Add the following to your firewall configuration. You can use Luci for this.
 <​code>​ <​code>​
-config 'racoon+config ​rule 
-  option 'dns' '        option src 'wan
-  option 'domain' ​'​'​ +        option ​name 'IPSec ESP' 
-</​code>​+        option proto 'esp
 +        option ​target ​'ACCEPT'
-With these parameters the virtual Shrew VPN network interface will be assigned domain **** and the DNS server ****. If you use OpenWrt DNS and set this option to the internal router IP address do not forget to create a rule VPN->​Device UDP 53 and **place it on top** to the other VPN rules.+config ​rule 
 +        option src '​wan'​ 
 +        option name 'IPSec IKE' 
 +        option proto '​udp'​ 
 +        option dest_port '​500'​ 
 +        option target '​ACCEPT'​
-{{:​doc:​howto:​ipsec_fw_rwdns.png|}}+config rule 
 +        option src '​wan'​ 
 +        option name 'IPSec NAT-T'​ 
 +        option proto '​udp'​ 
 +        option dest_port '​4500'​ 
 +        option target '​ACCEPT'​
-===== OpenWrt Configuration =====+config rule 
 +        option src '​wan'​ 
 +        option name 'Auth Header'​ 
 +        option proto '​ah'​ 
 +        option target '​ACCEPT'​ 
 +Basically you're opening up the ports/​protocols on the WAN zone that strongswan needs to accept traffic from a client. You can also create a custom zone called "​VPN"​ if you want to get fancy. ​
-If you are already familiar with UCI racoon configuration ​you will not see many differences for our setupNo rocket science at allHere the required information for our ACME infrastructure.+Note that some guides have you adding additional forwarding rules using ''​firewall.user''​. This is NOT necessary due to the fact that strongswan does this dynamically,​ as long as you have the ''​leftfirewall=yes''​ line in ipsec.conf 
 +HOWEVER: some builds of Strongswan (eg. v5.0.0 which is included in the 12.09 Attitude Adjustment package repository) seem to require the custom forwarding rules (perhaps because the ''​leftfirewall=yes''​ does not behave as it should??), so if you connect but don't get a default gateway and/or can't pass traffic, add these to firewall.user:
 <​code>​ <​code>​
-... +iptables -I INPUT  -m policy --dir in --pol ipsec --proto esp -j ACCEPT 
-config '​tunnel'​ '​roadwarrior'​ +iptables -I FORWARD ​ -m policy --dir in --pol ipsec --proto esp -j ACCEPT 
-  option '​enabled'​ '​1'​ +iptables -I FORWARD ​ -m policy --dir out --pol ipsec --proto esp -j ACCEPT 
-  ​option '​remote'​ '​anonymous'​ +iptables -I OUTPUT ​  ​-m policy --dir out --pol ipsec --proto esp -j ACCEPT 
-  ​option '​exchange_mode'​ '​aggressive'​ +</​code>​
-  ​option '​pre_shared_key'​ '​a_very_secret_key'​ +
-  option '​dpd_delay'​ '​300'​ +
-  list   ​'​p1_proposal'​ '​pre_g2_3des_sha1_xauth'​ +
-  ​list ​  '​sainfo'​ '​acme_dmz'​ +
-  list   '​sainfo'​ '​acme_lan'​+
-config '​sainfo'​ '​acme_lan'​ +===== Testing =====
-  option '​remote_subnet'​ '​​24'​ +
-  option '​local_subnet'​ '​​24'​ +
-  option '​p2_proposal'​ '​g2_aes_sha1'​+
-config '​sainfo'​ '​acme_dmz'​ +For testing, I used a Blackberry Z10 with NATIVE Ikev2 support (LOVE your Blackberry),​ an android phone with the StrongSwan Client and a Windows 7 machine using native IKEv2.
-  option '​remote_subnet'​ '​24'​ +
-  option '​local_subnet'​ '​​26'​ +
-  option '​p2_proposal'​ '​g2_aes_sha1'​+
-config '​p1_proposal'​ '​pre_g2_3des_sha1_xauth'​ +You can email clientCert.p12 to the mobile clients. ​
-  option '​lifetime'​ '​28800'​ +
-  option '​encryption_algorithm'​ '​3des'​ +
-  option '​hash_algorithm'​ '​sha1'​ +
-  option '​authentication_method'​ '​xauth_psk_server'​ +
-  option '​dh_group'​ '​2'​+
-config '​p2_proposal'​ '​g2_aes_sha1'​ +==== For BlackBerry Clients ==== 
-  ​option '​pfs_group'​ '​2'​ + 
-  ​option ​'lifetime' '3600+BlackBerry allows you to specify Perfect Forward Secrecy. You will want/need this. This should be standard. To make this work, however, you need to add the following lines to the ipsec.conf file in the ''​conn roadwarrior'' ​section, assuming this is the connection you want for your berry: 
-  ​option '​encryption_algorithm'​ 'aes' + 
-  ​option '​authentication_algorithm'​ '​hmac_sha1'​ +<​code>​ 
-...+ esp=aes-aes256-sha-modp1024,​aes256-sha512-modp4096 
 + ike=aes-aes256-sha-modp1024,​aes256-sha512-modp4096
 </​code>​ </​code>​
-A little explanation of the key facts.+What this does is specify what cipher suites to use, including ​the Diffie Hellman Groups; you can read about these settings in the [[https://​​projects/​strongswan/​wiki/​IKEv2CipherSuites|strongswan IKEv2 cipher suite documentation]]. Previously (before Strongswan, you'd use the ''​pfs=yes''​ statement. This has been deprecated.
-  * We define a new tunnel, give it the name '​roadwarrior'​ and enable it. The name is just for readability and has no special meaning. +Import your certificates into the Berry firstthen add VPN profile ​with the following settings:
-  * With **remote=anonymous** we tell the start script that this tunnel is for roadwarriors. This declaration can only be used for one enabled tunnel definition in the whole config file.  +
-  * As usual the exchange mode, the preshared key, a phase one proposal and at least one sainfo block must be referenced. +
-  * The phase one proposal has to be defined ​with [[doc:uci:​racoon#​p1_proposal|xauth_psk_server]]. This activates hybrid preshared key and xauth authentication. The other settings are more or less up to your favourites. +
-  * For each network the road warriors want to reach we define a sainfo block. In our case one for LAN and one for DMZ. The **remote_subnet** section of the sainfo block defines the laptop IP range. It must be the same for all road warrior sainfo blocks. The racoon [[vpn.ipsec.basics#​ike.daemon|start]] and [[vpn.ipsec.firewall#​vpn.firewall.script|firewall]] scripts will evaluate this parameter and will do everything that is required. The **local_subnet** section defines the network that the remote users can reach through the tunnel.+
-===== Firewall rules =====+  * Your gateway type will be "​Generic IKEv2 VPN Server",​ 
 +  * Authentication Type PKI, 
 +  * Authentication ID TypeIdentity Certificate Distinguished Name 
 +  * Client Certificate ​The name of your client cert ("​clent"​ in the above example) 
 +  * Gateway Auth Type PKI 
 +  * Gateway Auth ID Type Identify Certificate Distinguished Name 
 +  * Gateway CA Certificate ​your server Certificate name ("​xxxx"​ in the above example) 
 +  * Perfect Forward Secrecy ​On (VERY IMPORTANT) 
 +  * Automatically determine IP ON 
 +  * Automatically determine DNS ON 
 +  * Automatically determine algorithm ​ON
-Like in all previous chapters the firewall configuration is very simple. Our central firewall setup script will make all required settings ​to add the remote laptops into the [[vpn.ipsec.firewall#​zones|VPN zone]]. So we only need rules to allow VPN traffic from remote laptops into the intranet and the DMZ. As an example we create two rules. One "allow all" for the internal network and one rule for the ACME mailserver that has IP address in the DMZ.+The rest can be left to defaults.
-{{:​doc:​howto:​ipsec_roadwarrior_firewall.png|}}+If you receive Authentication Error you can try to use distuingished name (DN) of your server'​s certificate instead of the FQDN for the ''​leftid''​ propertyIt is ''"​C=US,​ O=xxx,"''​ in the example above, but you can find out yours using the command below and looking for the "​Subject"​ field
-**Remark!** If you want to use any services on your OpenWrt router through the IPsec tunnel you have to address its interfaces on the local networksOnly those IP addresses can be routed into the VPN due to the auto generated policiesAs an example let us assume OpenWrt runs a time service (NTP) and has the internal IP So we need a firewall rule vpn:​ -device port 123 UDP. On the road warrior clients we have to set NTP to IP<​code>​ 
 +openssl x509 -in /etc/ipsec.d/​certs/​serverCert.pem -text -noout 
-===== Client Configuration ===== 
-On the Shrew client side we have to build exactly the same IPsec setup. Add a new connection called "ACME Inc." and follow the screenshots below. A small explanation for each of the dialogues for the Shrew newbies.+==== For Windows 7 Clients ====
-  - The general settings gives the IP address of the central site OpenWrt routerThe pull option tells the client ​to obtain the setup from racoon. The network device will be configured automatically too. +In windows, run certmgr.msc to import your client ​certificateDo NOT simply click on the cert this won't work
-  - The client ​tab was left with default options. +Follow these instructions ​to setup the Windows ​VPN connection: [[https://​​docs/​DOC-24022]]
-  ​Name resolution will be taken from racoon setup+
-  - Authentication is set to PSK + XAuth. Local identifier is not relevant as racoon will accept any client +
-  - Remote Identity is not checked as we are working with a static ​VPN gateway IP address. +
-  ​On the credentials page the preshared key is entered +
-  - Phase 1 is set correspondingly to racoon +
-  - Phase 2 also matches racoon setup +
-  - IPsec policies will be pulled from racoon. This gives an automatic split tunnel setup.+
-{{:​doc:​howto:​ipsec_shrew2.png|}}+==== For Android Clients ====
-===== Connection =====+In Android, go to "​Settings > Security"​ to import.
-A double click on our new ACME Inc. connection will open the connection dialogue. There you have to provide ​your Xauth user and password ​and afterwards click on "​Connect"​The rest should work automaticallyTo verify that everything is fine you can have look at ipconfig /all. It should provide some output like this.+In the Strongswan client, specify "IKEv2 Certificate + EAP" as the type of VPN, pick "​client"​ for your certificate you just imported, ​and specify the username/password ​combo you added to ''/​etc/​ipsec.secrets''​Keep an eye on the logfile (see above) during initial login to spot any issues. If all goes well, you can use your router as VPN gateway for any mobile device, tablet, or laptop.
-{{:​doc:​howto:​ipsec_ipconfig.png|}}+Blackberry supports IKEv2 natively.
-===== What's next =====+==== For iPhones/iOS Clients ​====
-Only one thing leftA road [[vpn.ipsec.roadwarriorcertificates|warrior configuration with certificates]].+Versions of iOS prior to iOS 9, like Android, only support IKEv1This setup is not recommended For versions of iOS prior to iOS 9, you will need to use an app to use IKEv2Cisco'​s Anyconnect may work, but has not been tested
 +Beginning with iOS 9, IKEv2 connections are natively supported. ​ However, iOS9 only supports the use of certificates or username/​password,​ but not both.  Therefore, the native IKEv2 implementation in iOS 9 will not work with this example. ​ You will have to either alter the configuration above to support client certificates only or to support username/​password only.  If you wish to use both certificates and username/​passwords together for iOS 9 clients of your IPsec VPN, you will have to use a third-party application. ​ Cisco'​s Anyconnect may work, but has not been tested.
doc/howto/vpn.ipsec.roadwarrior.1356361922.txt.bz2 · Last modified: 2012/12/24 16:12 by miceliux