Differences

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
Next revisionBoth sides next revision
docs:guide-user:services:vpn:strongswan:roadwarrior [2022/10/03 13:03] sunshinejnjndocs:guide-user:services:vpn:strongswan:roadwarrior [2023/01/19 15:23] lukepicci
Line 1: Line 1:
-====== IPsec Modern IKEv2 Road-Warrior Configuration (ipsec / swanctl)======+====== IPsec Modern IKEv2 Road-Warrior Configuration ======
 IPsec Road-Warrior Configuration: Android (app), Windows 7+ (native), iOS9+ (native) BB10 (native), PlayBook, Dtek mobile devices. IPsec Road-Warrior Configuration: Android (app), Windows 7+ (native), iOS9+ (native) BB10 (native), PlayBook, Dtek mobile devices.
  
Line 165: Line 165:
 If you want to issue personal certificates to your clients then you should verify the signing CA's identity instead of the client certificates themselves. To achieve this, use the ''rightca="C=US, O=yyy, CN=xxxx"'' directive instead of ''rightcert'', where ''yyy'' and ''xxxx'' are what you choose in the next steps at Making Keys. More information on this: [[http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection|strongSwan documentation]]  If you want to issue personal certificates to your clients then you should verify the signing CA's identity instead of the client certificates themselves. To achieve this, use the ''rightca="C=US, O=yyy, CN=xxxx"'' directive instead of ''rightcert'', where ''yyy'' and ''xxxx'' are what you choose in the next steps at Making Keys. More information on this: [[http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection|strongSwan documentation]] 
 With the above configuration, you will need to also install caCert.pem on your clients in addition to the client cert - see the 'Making Keys' section below. With the above configuration, you will need to also install caCert.pem on your clients in addition to the client cert - see the 'Making Keys' section below.
 +
 +===== /etc/swanctl/* for swanctl-style config =====
 +If you are running Openwrt 22.03+, you probably want this instead of ipsec. We are going to demonstrate setting up a swanctl.conf and corresponding files to a similar configuration as the above ipsec configuration. Please note: we are using "default" proposals provided by strongswan here as the test shows they work well with present clients (apps/oses' default settings).
 +
 +0. Certificates (including (.pem) key files). Make them and put them in corresponding directories according to the "making of certificate/key files" section above. If you are migrating from ipsec config, move the files in swanctl directory: /etc/ipsec.d/cacerts/* --> /etc/swanctl/x509ca/* ; /etc/ipsec.d/private/* --> /etc/swanctl/private/* ; /etc/ipsec.d/certs/* --> /etc/swanctl/x509/
 +
 +1. Create a /etc/swanctl/common.conf file as a counterpart of conn %default settings in ipsec.conf as swanctl.conf does not have such %default part but needs to use "include" to do so.
 +<code>
 +      local_addrs  = 0.0.0.0/0,::/0
 +      remote_addrs = 0.0.0.0/0,::/0
 +      local {
 +         auth = pubkey
 +         certs = serverCert_myvpnserver.dyndns.org.pem
 +         id = myvpnserver.dyndns.org
 +      }
 +      children {
 +         ikev2clients {
 +            local_ts  = 0.0.0.0/0;::/0
 +            esp_proposals = default
 +         }
 +      }
 +      pools = strongswanippool 
 +      unique = never
 +      version = 2
 +      proposals = default
 +</code>
 +
 +2. Create main settings in Create a /etc/swanctl/swanctl.conf
 +<code>
 +connections {
 +   rw-eapmschapv2 {
 +      include ./common.conf
 +      remote-eapmschapv2 {
 +         auth = eap-mschapv2
 +         eap_id = %any
 +      }
 +      send_certreq = no
 +      send_cert = always
 +   }
 +   rw-eapmschapv2ios {
 +      include ./common.conf
 +      remote-eapmschapv2ios {
 +         auth = eap-mschapv2
 +         eap_id = %any
 +      }
 +      send_certreq = no
 +      send_cert = always
 +   }
 +   rw-eaptls {
 +      include ./common.conf
 +      remote-eaptls {
 +         auth = eap-tls
 +         certs = clientCert_myvpnclient.pem
 +      }
 +      send_certreq = no
 +   }
 +   rw-eaptlsios {
 +      include ./common.conf
 +      remote-eaptlsios {
 +         auth = eap-tls
 +         certs = clientCert_myvpnclient.pem
 +         id = myVpnClients
 +      }
 +      send_certreq = no
 +      send_cert = always
 +   }
 +   rw-pubkey {
 +      include ./common.conf
 +      remote-pubkey {
 +         auth = pubkey
 +         certs = clientCert_myvpnclient.pem
 +      }
 +      send_certreq = no
 +   }
 +   rw-pubkeyios {
 +      include ./common.conf
 +      remote-pubkeyios {
 +         auth = pubkey
 +         certs = clientCert_myvpnclient.pem
 +         id = myVpnClients
 +      }
 +      send_certreq = no
 +      send_cert = always
 +   }
 +}
 +
 +secrets {
 +   rsa- {
 +      filename="serverKey_myvpnserver.dyndns.org.pem"
 +   }
 +   eap-remoteuser {
 +      id = remoteusername 
 +      secret = secretpassword
 +   }
 +}
 +
 +pools {
 +    strongswanippool {
 +        addrs = 10.0.1.0/24
 + # dns = 8.8.8.8
 +    }
 +}
 +
 +# Include config snippets
 +include conf.d/*.conf
 +
 +include /var/swanctl/swanctl.conf
 +</code>
 +
 +3. If you are upgrading from an old router setting (installed strongswan in older OpenWrt versions and did a system upgrade keeping the settings, reinstalled strongswan-full), you may want to make sure you have the newly added (as you may find in .conf-opkg files) second "include" part in /etc/swanctl/swanctl.conf 
 +<code>
 +include /var/swanctl/swanctl.conf
 +</code>
 +and /etc/strongswan.conf
 +<code>
 +include /var/ipsec/strongswan.conf
 +</code>
 +Also, you may want to rename/remove all /etc/ipsec.* files to keep strongswan from using them.
 +You may want to run /etc/init.d/ipsec disable (as well as /etc/init.d/ipsec stop)
 +
 +4. Check the config
 +<code bash>
 +swanctl --load-all
 +</code>
 +You'll see 6 connections loaded successfully if everything goes well. Otherwise, check the prompts to see what went wrong.
  
 ===== ipsec.secrets ===== ===== ipsec.secrets =====
Line 290: Line 415:
  option target 'ACCEPT'  option target 'ACCEPT'
 </code> </code>
 +
 +for swanctl config, you probably want to add this too:
 +
 +<code>
 +config rule
 +        option name 'AllowIPsec2WAN'
 +        list proto 'all'
 +        option src 'wan'
 +        option dest 'wan'
 +        option target 'ACCEPT'
 +</code>
 +
 Explanation: Explanation:
-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. +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. Please see [[https://forum.openwrt.org/t/traffic-is-dropped-for-ipsec-with-firewall4|this forum post]] for more details on how to do that with //fw4// and //nftables//
 + 
 +For swanctl part, as we used a policy-based VPN, your virtual IPs would be installed on the "outbound" interface on the server, which is usually your wan interface, such as pppoe-wan or something. And your version of OpenWRT probably uses nftables instead of iptables for the firewall, it would block WAN interface to forward by default which makes sense if it only accepts packets to its own IP. But as virtual IPs are considered originated from this interface, they would be dropped by the rule banning all forwarding happening to the packets sent by your virtual IP (and arrived on WAN interface first). They will never make their way to srcnat or something to NAT ""back"" (from WAN) to WANZONE. By adding this AllowIPsec2WAN, you can allow your VPN clients to access the internet (wan) while accessing your lan.
  
 You will also need additional rules in ''/etc/firewall.user''. Note that strongswan mentions the ''leftfirewall=yes'' setting in ipsec.conf which was used to add the iptables entries using the ''_updown'' script in ''/usr/libexec/ipsec/_updown'' but this has been deprecated and doesn't do anything. You will also need additional rules in ''/etc/firewall.user''. Note that strongswan mentions the ''leftfirewall=yes'' setting in ipsec.conf which was used to add the iptables entries using the ''_updown'' script in ''/usr/libexec/ipsec/_updown'' but this has been deprecated and doesn't do anything.
Line 321: Line 460:
  
 Explication: "-m policy" uses the iptables policy module, and matching on the "--pol none" means no policy. To match on traffic that came from IPSEC, it would have been "--pol ipsec". The reason this is needed is IPSEC in the kernel shows as coming from the WAN interface even after it's decrypted (rather than from, say, a special virtual IPSEC interface). Explication: "-m policy" uses the iptables policy module, and matching on the "--pol none" means no policy. To match on traffic that came from IPSEC, it would have been "--pol ipsec". The reason this is needed is IPSEC in the kernel shows as coming from the WAN interface even after it's decrypted (rather than from, say, a special virtual IPSEC interface).
- 
-===== Testing ===== 
-For testing, I used a Blackberry Z10 with NATIVE Ikev2 support (LOVE your Blackberry), an android phone with the StrongSwan Client, Windows 7 and 10 machines using native IKEv2, and a Blackberry DTek running Android with Dtek. 
- 
-You can email client.p12 (and caCert, if needed) to the mobile clients.  
- 
- 
-===== /etc/swanctl/* for swanctl config ===== 
-If you are running Openwrt 22.03+, you probably want this instead of ipsec. We are going to demonstrate setting up a swanctl.conf and corresponding files to a similar configuration as the above ipsec configuration. Please note: we are using "default" proposals provided by strongswan here as the test shows they work well with present clients (apps/oses' default settings). 
- 
-0. Certificates (including (.pem) key files). Make them and put them in corresponding directories according to the "making of certificate/key files" section above. If you are migrating from ipsec config, move the files in swanctl directory: /etc/ipsec.d/cacerts/* --> /etc/swanctl/x509ca/* ; /etc/ipsec.d/private/* --> /etc/swanctl/private/* ; /etc/ipsec.d/certs/* --> /etc/swanctl/x509/ 
- 
-1. Create a /etc/swanctl/common.conf file as a counterpart of conn %default settings in ipsec.conf as swanctl.conf does not have such %default part but needs to use "include" to do so. 
-<code> 
-      local_addrs  = 0.0.0.0/0,::/0 
-      remote_addrs = 0.0.0.0/0,::/0 
-      local { 
-         auth = pubkey 
-         certs = serverCert_myvpnserver.dyndns.org.pem 
-         id = myvpnserver.dyndns.org 
-      } 
-      children { 
-         ikev2clients { 
-            local_ts  = 0.0.0.0/0;::/0 
-            esp_proposals = default 
-         } 
-      } 
-      pools = strongswanippool  
-      unique = never 
-      version = 2 
-      proposals = default 
-</code> 
- 
-2. Create main settings in Create a /etc/swanctl/swanctl.conf 
-<code> 
-connections { 
-   rw-eapmschapv2 { 
-      include ./common.conf 
-      remote-eapmschapv2 { 
-         auth = eap-mschapv2 
-         eap_id = %any 
-      } 
-      send_certreq = no 
-      send_cert = always 
-   } 
-   rw-eapmschapv2ios { 
-      include ./common.conf 
-      remote-eapmschapv2ios { 
-         auth = eap-mschapv2 
-         eap_id = %any 
-      } 
-      send_certreq = no 
-      send_cert = always 
-   } 
-   rw-eaptls { 
-      include ./common.conf 
-      remote-eaptls { 
-         auth = eap-tls 
-         certs = clientCert_myvpnclient.pem 
-      } 
-      send_certreq = no 
-   } 
-   rw-eaptlsios { 
-      include ./common.conf 
-      remote-eaptlsios { 
-         auth = eap-tls 
-         certs = clientCert_myvpnclient.pem 
-         id = myVpnClients 
-      } 
-      send_certreq = no 
-      send_cert = always 
-   } 
-   rw-pubkey { 
-      include ./common.conf 
-      remote-pubkey { 
-         auth = pubkey 
-         certs = clientCert_myvpnclient.pem 
-      } 
-      send_certreq = no 
-   } 
-   rw-pubkeyios { 
-      include ./common.conf 
-      remote-pubkeyios { 
-         auth = pubkey 
-         certs = clientCert_myvpnclient.pem 
-         id = myVpnClients 
-      } 
-      send_certreq = no 
-      send_cert = always 
-   } 
-} 
- 
-secrets { 
-   rsa- { 
-      filename="serverKey_myvpnserver.dyndns.org.pem" 
-   } 
-   eap-remoteuser { 
-      id = remoteusername  
-      secret = secretpassword 
-   } 
-} 
- 
-pools { 
-    strongswanippool { 
-        addrs = 10.0.1.0/24 
- # dns = 8.8.8.8 
-    } 
-} 
- 
-# Include config snippets 
-include conf.d/*.conf 
- 
-include /var/swanctl/swanctl.conf 
-</code> 
- 
-3. If you are upgrading from an old router setting (installed strongswan in older OpenWrt versions and did a system upgrade keeping the settings, reinstalled strongswan-full), you may want to make sure you have the newly added (as you may find in .conf-opkg files) second "include" part in /etc/swanctl/swanctl.conf  
-<code> 
-include /var/swanctl/swanctl.conf 
-</code> 
-and /etc/strongswan.conf 
-<code> 
-include /var/ipsec/strongswan.conf 
-</code> 
-Also, you may want to rename/remove all /etc/ipsec.* files to keep strongswan from using them. 
-You may want to run /etc/init.d/ipsec disable (as well as /etc/init.d/ipsec stop) 
- 
-4. Check the config 
-<code bash> 
-swanctl --load-all 
-</code> 
-You'll see 6 connections loaded successfully if everything goes well. Otherwise, check the prompts to see what went wrong. 
  
 ==== For BlackBerry Clients ==== ==== For BlackBerry Clients ====
Line 487: Line 495:
 openssl x509 -in /etc/ipsec.d/certs/serverCert.pem -text -noout openssl x509 -in /etc/ipsec.d/certs/serverCert.pem -text -noout
 </code>  </code> 
 +
 +===== Road-Warriors configuration =====
 +For testing, the original author of this page used a Blackberry Z10 with NATIVE Ikev2 support (LOVE your Blackberry), an Android phone with the strongSwan app, Windows 7 and 10+ machines using native IKEv2, and a Blackberry DTek running Android with DTek.
 +
 +Hint: you can easily email client certs .p12 bundles (and caCert, if needed) to the mobile device users. 
  
 ==== For Windows Clients ==== ==== For Windows Clients ====
Line 498: Line 511:
 You will need administrative rights to set up this kind of VPN connection. Only traditional desktop editions are supported. You will need administrative rights to set up this kind of VPN connection. Only traditional desktop editions are supported.
  
-In windows, import your client and CA certificates into **Local Machine** storage, not Current User. If you followed this tutorial the CA certificate is already in a bundle with the client cert into the client.p12 package, just take care of importing, again, into Local Machine and keep selecting the option to automatically choose the appropriate certificate store. At the end of the import, you should have the CA in "Trusted Root Certification Authorities\Certificates" store and the client cert in "My\Certificates" store.+In windows, import your client and CA certificates into **Local Machine** storage, not Current User. If you followed this tutorial the CA certificate is already in a bundle with the client cert into the client.p12 package, just take care of importing, again, into **Local Machine** and keep selecting the option to automatically choose the appropriate certificate store. At the end of the import, you should have the CA in "Trusted Root Certification Authorities\Certificates" store and the client cert in "My\Certificates" store.
  
 Follow these instructions to set up the Windows VPN connection for using Machine Certificates: [[https://supportforums.cisco.com/docs/DOC-24022]] Follow these instructions to set up the Windows VPN connection for using Machine Certificates: [[https://supportforums.cisco.com/docs/DOC-24022]]
 +
 +Please note: this Machine Certificates setup uses Device certificate/key installed in **Local Machine** keystore and it is not based on EAP. Windows **does not** support EAP with Device certificate/key from **Local Machine** keystore for native VPN client.
  
 === as EAPTLS roadwarriors === === as EAPTLS roadwarriors ===
-You don't need administrative rights to set up this kind of VPN connection. Modern WinRT-based editions are also supported (including WP8+ mobile editions).+You don't need administrative rights to set up this kind of VPN connection, but you still need to be an admin in order to import the CA cert only. Modern WinRT-based editions are also supported (including WP8+ mobile editions).
  
-In Windows, import your client and CA certificate into **Current User**, not Local Machine. If you followed this tutorial the CA certificate is already in a bundle with the client cert into the client.p12 package, just take care of importing, again, into Current User and keep selecting the option to automatically choose the appropriate certificate store. At the end of the import, you should have the CA in "Trusted Root Certification Authorities\Certificates" store and the client cert in "My\Certificates" store.+In Windows, import your client and CA certificate into **Current User**, not Local Machine. If you followed this tutorial the CA certificate is already in a bundle with the client cert into the client.p12 package, just take care of importing, again, into **Current User** and keep selecting the option to automatically choose the appropriate certificate store. At the end of the import, you should have the CA in "Trusted Root Certification Authorities\Certificates" store and the client cert in "My\Certificates" store. Now you need to import this CA as **Local Machine**, you can do it by using the standalone CA cert from the bove steps or export it from the **Current User** CA store after p12 import is done.
  
 Create a new VPN connection from the wizard, choose IKEv2 as the type, and select "Certificate" for the authentication method. Connect, and pick your "myvpnclient" cert when prompted. Please note, split-tunneling is enabled by default in Windows 10+ (just google for "disable Split Tunneling Windows" or read here: https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnection?view=win10-ps#examples. Create a new VPN connection from the wizard, choose IKEv2 as the type, and select "Certificate" for the authentication method. Connect, and pick your "myvpnclient" cert when prompted. Please note, split-tunneling is enabled by default in Windows 10+ (just google for "disable Split Tunneling Windows" or read here: https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnection?view=win10-ps#examples.
 +
 +Please note: this EAP-TLS setup uses User certificate/key installed in **Current User** keystore. Windows **does not** support EAP (including EAP-TLS) with Device certificate/key from **Local Machine** keystore for native VPN client.
  
 ==== For Android Clients ==== ==== For Android Clients ====
  • Last modified: 2024/03/29 03:47
  • by zetago