[Solved] IPSec IKEv2 in pfSense only allow one mobile client to connect.
-
From what it seems to me you have the same issue as https://forum.pfsense.org/index.php?topic=87857.0
Check the solutions provided there and see if it fixes your issues.
-
@ermal:
From what it seems to me you have the same issue as https://forum.pfsense.org/index.php?topic=87857.0
Check the solutions provided there and see if it fixes your issues.
Hi,
I changed uniqueids to be 'no'. However I don't think the two problems are similar. In the other thread, additional client is flat out not connecting. In my case, additional client with different identifiers would connect (hence not the uniqueids problem). Instead, only the SP (security policies) for the newest client connected is retained/used/displayed. Disconnect any other one would restore the SP for the client previously connected.
-
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/24However 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/24conn Jerry
rightsourceip = 10.0.100.2
right = %any
rightauth=eap-mschapv2
rightid = Jerry@[redacted]
auto = addconn mobile
rightsourceip = 10.0.100.3
right = %any
rightauth=eap-mschapv2
rightid = mobile@[redacted]
auto = addconn mbp
rightsourceip = 10.0.100.4
right = %any
rightauth=eap-mschapv2
rightid = mbp@[redacted]
auto = addconn any
rightsourceip = 10.0.100.128/25
rightsubnet = 10.0.100.128/25
right = %any
rightid = %any
rightauth=eap-mschapv2
auto = addSecurity policies (Two clients under same NAT, one under another NAT):
-
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); } -
Ok a fix has been pushed.
Thank you for analysis. -
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
-
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
-
A similar change has been applied to make the config work.
https://github.com/pfsense/pfsense/commit/034a23f0ab3eb765eba53f44ec256272b3e80b17 -
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.
-
@ermal:
A similar change has been applied to make the config work.
https://github.com/pfsense/pfsense/commit/034a23f0ab3eb765eba53f44ec256272b3e80b17tried but with no change…
-
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
-
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. -
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.
-
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… -
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.
