Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [Solved] IPSec IKEv2 in pfSense only allow one mobile client to connect.

    Scheduled Pinned Locked Moved IPsec
    16 Posts 4 Posters 8.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Z Offline
      zllovesuki
      last edited by

      Strange.

      Using a pool for ip breaks things:

      This file is automatically generated. Do not edit

      config setup
      uniqueids = no
      charondebug=""

      conn con1
      fragmentation = yes
      keyexchange = ikev2
      reauth = yes
      forceencaps = no
      rekey = yes
      installpolicy = yes
      type = tunnel
      dpdaction = clear
      dpddelay = 10s
      dpdtimeout = 60s
      left = 64.62.136.2
      leftid = @[redacted]
      ikelifetime = 28800s
      lifetime = 3600s
      rightsourceip = 10.0.100.0/24
      right = %any
      rightauth=eap-mschapv2
      rightsubnet = 10.0.100.0/24
      auto = add
      ike = aes256-sha256-modp1024!
      esp = aes256-sha1-modp1024,aes256-sha1-modp1024,aes256-sha1-modp1024,aes256-sha1-modp1024!
      eap_identity=%any
      leftauth=pubkey
      leftcert=/var/etc/ipsec/ipsec.d/certs/cert-1.crt
      leftsubnet = 10.0.0.0/24,10.20.30.0/24,192.168.99.0/24,10.20.40.0/24

      However defining IP for each client works:

      This file is automatically generated. Do not edit

      config setup
      uniqueids = no
      charondebug=""

      #conn con1
      conn %default
      fragmentation = yes
      keyexchange = ikev2
      reauth = yes
      forceencaps = no
      rekey = yes
      installpolicy = yes
      type = tunnel
      dpdaction = clear
      dpddelay = 10s
      dpdtimeout = 60s
      left = 64.62.136.2
      leftid = @[redacted]
      ikelifetime = 28800s
      lifetime = 3600s
      ike = aes256-sha256-modp1024!
      esp = aes256-sha1-modp1024,aes256-sha1-modp1024,aes256-sha1-modp1024,aes256-sha1-modp1024!
      eap_identity=%any
      leftauth=pubkey
      leftcert=/var/etc/ipsec/ipsec.d/certs/cert-1.crt
      leftsubnet = 10.0.0.0/24,10.20.30.0/24,192.168.99.0/24,10.20.40.0/24

      conn Jerry
      rightsourceip = 10.0.100.2
      right = %any
      rightauth=eap-mschapv2
      rightid = Jerry@[redacted]
      auto = add

      conn mobile
      rightsourceip = 10.0.100.3
      right = %any
      rightauth=eap-mschapv2
      rightid = mobile@[redacted]
      auto = add

      conn mbp
      rightsourceip = 10.0.100.4
      right = %any
      rightauth=eap-mschapv2
      rightid = mbp@[redacted]
      auto = add

      conn any
      rightsourceip = 10.0.100.128/25
      rightsubnet = 10.0.100.128/25
      right = %any
      rightid = %any
      rightauth=eap-mschapv2
      auto = add

      Security policies (Two clients under same NAT, one under another NAT):

      1 Reply Last reply Reply Quote 0
      • Z Offline
        zllovesuki
        last edited by

        Got'em coach.

        The problem is that the generated conf is for site-to-site (presumably). Therefore it adds "rightsubnet" to the configuration, even though it is for mobile clients. If "rightsubnet" exists, every time a new mobile client connects, the SP gets replaced.

        To solve the problem, edit /etc/inc/vpn.inc, comment out (only if you are only using mobile client):

        
        if (!empty($rightsubnet_spec)) {
        	$tempsubnets = array();
        	foreach ($rightsubnet_spec as $rightsubnet)
        		$tempsubnets[$rightsubnet] = $rightsubnet;
        	$ipsecfin .= "\trightsubnet = " . join(",", $tempsubnets) . "\n";
        	unset($tempsubnets, $rightsubnet);
        }
        
        1 Reply Last reply Reply Quote 0
        • E Offline
          eri--
          last edited by

          Ok a fix has been pushed.
          Thank you for analysis.

          1 Reply Last reply Reply Quote 0
          • maxxerM Offline
            maxxer
            last edited by

            sorry for hijacking the thread, but I'm having troubles in connecting from my mobile clients since the upgrade to 2.2.
            From your post I see it's working for you, so would you mind sharing your config with us? Or at least tell what's the difference between the wiki doc, or the changes you applied after the upgrade…

            thanks

            1 Reply Last reply Reply Quote 0
            • M Offline
              meta4
              last edited by

              @maxxer:

              sorry for hijacking the thread, but I'm having troubles in connecting from my mobile clients since the upgrade to 2.2.
              From your post I see it's working for you, so would you mind sharing your config with us? Or at least tell what's the difference between the wiki doc, or the changes you applied after the upgrade…

              thanks

              +1

              1 Reply Last reply Reply Quote 0
              • E Offline
                eri--
                last edited by

                A similar change has been applied to make the config work.
                https://github.com/pfsense/pfsense/commit/034a23f0ab3eb765eba53f44ec256272b3e80b17

                1 Reply Last reply Reply Quote 0
                • Z Offline
                  zllovesuki
                  last edited by

                  @maxxer:

                  sorry for hijacking the thread, but I'm having troubles in connecting from my mobile clients since the upgrade to 2.2.
                  From your post I see it's working for you, so would you mind sharing your config with us? Or at least tell what's the difference between the wiki doc, or the changes you applied after the upgrade…

                  thanks

                  You have to understand the fundamental changes between IKEv2 and V1. V2 does not require peers to agree on what method to use to authenticate. Instead, Phase 1 is always (in a laymans term) encrypted with X.509 certificate, then authenticated based on the SAN in the certificate (IP, DNS, etc). It is then peers (most likely right) authenticate using EAP or IKEv2 identity via MSCHAPv2 (this is one way of doing it). Therefore, every mobile client needs to have the self signed CA installed. For strongSwan client, the X.509 server certificate needs to be installed as well.

                  1 Reply Last reply Reply Quote 0
                  • maxxerM Offline
                    maxxer
                    last edited by

                    @ermal:

                    A similar change has been applied to make the config work.
                    https://github.com/pfsense/pfsense/commit/034a23f0ab3eb765eba53f44ec256272b3e80b17

                    tried but with no change…

                    1 Reply Last reply Reply Quote 0
                    • maxxerM Offline
                      maxxer
                      last edited by

                      @zllovesuki:

                      You have to understand the fundamental changes between IKEv2 and V1. V2 does not require peers to agree on what method to use to authenticate. Instead, Phase 1 is always (in a laymans term) encrypted with X.509 certificate, then authenticated based on the SAN in the certificate (IP, DNS, etc). It is then peers (most likely right) authenticate using EAP or IKEv2 identity via MSCHAPv2 (this is one way of doing it). Therefore, every mobile client needs to have the self signed CA installed. For strongSwan client, the X.509 server certificate needs to be installed as well.

                      but I didn't switch to IKEv2, I'm still on v1. And other than that my Ubuntu client connect without problems, just androids fail :( I will gather some logs asap

                      1 Reply Last reply Reply Quote 0
                      • E Offline
                        eri--
                        last edited by

                        Check the algorithms being used, mobiles are picky about those in general.
                        Usually you increase the log level on the IKE SA to see what the client proposes.

                        1 Reply Last reply Reply Quote 0
                        • Z Offline
                          zllovesuki
                          last edited by

                          @maxxer:

                          @zllovesuki:

                          You have to understand the fundamental changes between IKEv2 and V1. V2 does not require peers to agree on what method to use to authenticate. Instead, Phase 1 is always (in a laymans term) encrypted with X.509 certificate, then authenticated based on the SAN in the certificate (IP, DNS, etc). It is then peers (most likely right) authenticate using EAP or IKEv2 identity via MSCHAPv2 (this is one way of doing it). Therefore, every mobile client needs to have the self signed CA installed. For strongSwan client, the X.509 server certificate needs to be installed as well.

                          but I didn't switch to IKEv2, I'm still on v1. And other than that my Ubuntu client connect without problems, just androids fail :( I will gather some logs asap

                          I am on V2 and, surprisingly, V1 is actually making things more difficult.

                          1 Reply Last reply Reply Quote 0
                          • maxxerM Offline
                            maxxer
                            last edited by

                            @zllovesuki:

                            Therefore, every mobile client needs to have the self signed CA installed. For strongSwan client, the X.509 server certificate needs to be installed as well.

                            So to use IPsec with IKEv2 you need to import a cert on the mobile client?

                            I managed to get IPSec back to work with IKEv1, but now my Ubuntu client won't connect anymore. I was wondering if moving to IKEv2 could solve both issues, but cannot manage it to authenticate.
                            i found here that android 4.4 should work with EAP-MSCHAPv2, which from what I understand is still a user/pass method, but it won't work here…

                            1 Reply Last reply Reply Quote 0
                            • Z Offline
                              zllovesuki
                              last edited by

                              @maxxer:

                              @zllovesuki:

                              Therefore, every mobile client needs to have the self signed CA installed. For strongSwan client, the X.509 server certificate needs to be installed as well.

                              So to use IPsec with IKEv2 you need to import a cert on the mobile client?

                              I managed to get IPSec back to work with IKEv1, but now my Ubuntu client won't connect anymore. I was wondering if moving to IKEv2 could solve both issues, but cannot manage it to authenticate.
                              i found here that android 4.4 should work with EAP-MSCHAPv2, which from what I understand is still a user/pass method, but it won't work here…

                              Yes, you need to install/import the CA that issued the e IPSec certificate.

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.