Actions
Regression #12549
open
Per-user Mobile IPsec settings are not applied to connecting mobile clients
Start date:
Due date:
% Done:
0%
Estimated time:
Plus Target Version:
Plus-Next
Release Notes:
Force Inclusion
Affected Version:
2.5.x
Affected Architecture:
Description
Not sure when this regressed but it looks like the connection matching in strongSwan is different now than it used to be. Possible that it changed with swanctl.conf vs ipsec.conf changes.
The order right now is "con-mobile" and then the per-user connections underneath, which will never match the user settings since it matches con-mobile first. So con-mobile needs to move down below the per-user connection settings.
Second problem is the identifiers. First, the ID of connecting EAP-MSCHAPv2 clients is most often going to be their IP address and strongSwan matches the eap_id for EAP, not the IKEv2 ID. So for EAP-MSCHAPv2 at least, we can omit the ID. Second related problem is that in the place ipsec_setup_userpools() gets run, it attempts to access $ph1ent which doesn't exist yet. So that function needs to be passed a copy of the mobile P1 so it can check settings inside.
I have a patch to test, but it has an odd side effect. At least for Windows clients, they are prompted to re-enter credentials on each connection attempt because the first one is rejected. So there is likely some other setting that's not quite right yet. Thus I'm not merging it yet until more testing can be done.
Files
.png){kind=link}
Related issues
Updated by Jim Pingle about 3 years ago
- File patch-12549.diff patch-12549.diff added
Diff attached. The commit is on a private branch at https://gitlab.netgate.com/pfSense/pfSense/-/commit/2119d125f008da5f18e0a1700cbcbb8ad3da85c3
Updated by Danilo Zrenjanin about 3 years ago
- File image (4).png image (4).png added
I couldn't add that patch.
/usr/bin/patch --directory=/ -t -p2 -i /var/patches/61a753782d95f.patch --check --forward --ignore-whitespace Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/src/etc/inc/ipsec.inc b/src/etc/inc/ipsec.inc |index 122cbdd0b4..b49bd5ef97 100644 |--- a/src/etc/inc/ipsec.inc |+++ b/src/etc/inc/ipsec.inc -------------------------- Patching file etc/inc/ipsec.inc using Plan A... Hunk #1 succeeded at 1614 (offset -326 lines). Hunk #2 succeeded at 1622 (offset -326 lines). Hunk #3 succeeded at 1630 (offset -326 lines). Hunk #4 succeeded at 1662 (offset -326 lines). Hunk #5 succeeded at 2180 (offset -5 lines). Hunk #6 failed at 2415. Hunk #7 succeeded at 2077 with fuzz 2 (offset -374 lines). Hunk #8 succeeded at 3119 (offset -56 lines). No such line 3182 in input file, ignoring Hunk #9 succeeded at 2870 (offset -371 lines). 1 out of 9 hunks failed while patching etc/inc/ipsec.inc done
Updated by Jim Pingle about 3 years ago
It would apply against the current 2.6.0 code base, and not older versions.
Updated by Danilo Zrenjanin about 3 years ago
Tested against:
2.6.0-DEVELOPMENT (amd64) built on Tue Nov 30 06:19:18 UTC 2021 FreeBSD 12.3-PRERELEASE
With or without the patch applied, I couldn't establish a connection with the server. For some reason, the connection moves to NAT-T even though there was no NAT in the path.
I tested from the MacOS native client.
Server was in EAP-MSCHAPv2 mode.
Dec 2 09:35:57 charon 60674 01[NET] <7> received packet: from 192.168.33.217[500] to 192.168.33.20[500] (604 bytes) Dec 2 09:35:57 charon 60674 01[ENC] <7> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] Dec 2 09:35:57 charon 60674 01[CFG] <7> looking for an IKEv2 config for 192.168.33.20...192.168.33.217 Dec 2 09:35:57 charon 60674 01[CFG] <7> candidate: 192.168.33.20...0.0.0.0/0, ::/0, prio 1052 Dec 2 09:35:57 charon 60674 01[CFG] <7> found matching ike config: 192.168.33.20...0.0.0.0/0, ::/0 with prio 1052 Dec 2 09:35:57 charon 60674 01[IKE] <7> local endpoint changed from 0.0.0.0[500] to 192.168.33.20[500] Dec 2 09:35:57 charon 60674 01[IKE] <7> remote endpoint changed from 0.0.0.0 to 192.168.33.217[500] Dec 2 09:35:57 charon 60674 01[IKE] <7> 192.168.33.217 is initiating an IKE_SA Dec 2 09:35:57 charon 60674 01[IKE] <7> IKE_SA (unnamed)[7] state change: CREATED => CONNECTING Dec 2 09:35:57 charon 60674 01[CFG] <7> selecting proposal: Dec 2 09:35:57 charon 60674 01[CFG] <7> proposal matches Dec 2 09:35:57 charon 60674 01[CFG] <7> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 Dec 2 09:35:57 charon 60674 01[CFG] <7> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 Dec 2 09:35:57 charon 60674 01[CFG] <7> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 Dec 2 09:35:57 charon 60674 01[IKE] <7> sending cert request for "XXXXX" Dec 2 09:35:57 charon 60674 01[ENC] <7> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ] Dec 2 09:35:57 charon 60674 01[NET] <7> sending packet: from 192.168.33.20[500] to 192.168.33.217[500] (481 bytes) Dec 2 09:35:57 charon 60674 01[NET] <7> received packet: from 192.168.33.217[4500] to 192.168.33.20[4500] (496 bytes) Dec 2 09:35:57 charon 60674 01[ENC] <7> unknown attribute type INTERNAL_DNS_DOMAIN Dec 2 09:35:57 charon 60674 01[ENC] <7> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ] Dec 2 09:35:57 charon 60674 01[IKE] <7> local endpoint changed from 192.168.33.20[500] to 192.168.33.20[4500] Dec 2 09:35:57 charon 60674 01[IKE] <7> remote endpoint changed from 192.168.33.217[500] to 192.168.33.217[4500] Dec 2 09:35:57 charon 60674 01[CFG] <7> looking for peer configs matching 192.168.33.20[192.168.33.20]...192.168.33.217[192.168.33.217] Dec 2 09:35:57 charon 60674 01[CFG] <7> candidate "con-mobile", match: 20/1/1052 (me/other/ike) Dec 2 09:35:57 charon 60674 01[CFG] <con-mobile|7> selected peer config 'con-mobile' Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> initiating EAP_IDENTITY method (id 0x00) Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> processing INTERNAL_IP4_ADDRESS attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> processing INTERNAL_IP4_NETMASK attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> processing INTERNAL_IP4_DHCP attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> processing INTERNAL_IP4_DNS attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> processing INTERNAL_IP6_ADDRESS attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> processing INTERNAL_IP6_DHCP attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> processing INTERNAL_IP6_DNS attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> processing INTERNAL_DNS_DOMAIN attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> peer supports MOBIKE Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> authentication of '192.168.33.20' (myself) with RSA signature successful Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|7> sending end entity cert "XXXXXXX" Dec 2 09:35:57 charon 60674 01[ENC] <con-mobile|7> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ] Dec 2 09:35:57 charon 60674 01[ENC] <con-mobile|7> splitting IKE message (1312 bytes) into 2 fragments Dec 2 09:35:57 charon 60674 01[ENC] <con-mobile|7> generating IKE_AUTH response 1 [ EF(1/2) ] Dec 2 09:35:57 charon 60674 01[ENC] <con-mobile|7> generating IKE_AUTH response 1 [ EF(2/2) ] Dec 2 09:35:57 charon 60674 01[NET] <con-mobile|7> sending packet: from 192.168.33.20[4500] to 192.168.33.217[4500] (1236 bytes) Dec 2 09:35:57 charon 60674 01[NET] <con-mobile|7> sending packet: from 192.168.33.20[4500] to 192.168.33.217[4500] (148 bytes) Dec 2 09:35:57 charon 60674 01[NET] <8> received packet: from 192.168.33.217[500] to 192.168.33.20[500] (604 bytes) Dec 2 09:35:57 charon 60674 01[ENC] <8> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] Dec 2 09:35:57 charon 60674 01[CFG] <8> looking for an IKEv2 config for 192.168.33.20...192.168.33.217 Dec 2 09:35:57 charon 60674 01[CFG] <8> candidate: 192.168.33.20...0.0.0.0/0, ::/0, prio 1052 Dec 2 09:35:57 charon 60674 01[CFG] <8> found matching ike config: 192.168.33.20...0.0.0.0/0, ::/0 with prio 1052 Dec 2 09:35:57 charon 60674 01[IKE] <8> local endpoint changed from 0.0.0.0[500] to 192.168.33.20[500] Dec 2 09:35:57 charon 60674 01[IKE] <8> remote endpoint changed from 0.0.0.0 to 192.168.33.217[500] Dec 2 09:35:57 charon 60674 01[IKE] <8> 192.168.33.217 is initiating an IKE_SA Dec 2 09:35:57 charon 60674 01[IKE] <8> IKE_SA (unnamed)[8] state change: CREATED => CONNECTING Dec 2 09:35:57 charon 60674 01[CFG] <8> selecting proposal: Dec 2 09:35:57 charon 60674 01[CFG] <8> proposal matches Dec 2 09:35:57 charon 60674 01[CFG] <8> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 Dec 2 09:35:57 charon 60674 01[CFG] <8> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 Dec 2 09:35:57 charon 60674 01[CFG] <8> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 Dec 2 09:35:57 charon 60674 01[IKE] <8> sending cert request for "XXXXXX" Dec 2 09:35:57 charon 60674 01[ENC] <8> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ] Dec 2 09:35:57 charon 60674 01[NET] <8> sending packet: from 192.168.33.20[500] to 192.168.33.217[500] (481 bytes) Dec 2 09:35:57 charon 60674 01[NET] <8> received packet: from 192.168.33.217[4500] to 192.168.33.20[4500] (496 bytes) Dec 2 09:35:57 charon 60674 01[ENC] <8> unknown attribute type INTERNAL_DNS_DOMAIN Dec 2 09:35:57 charon 60674 01[ENC] <8> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ] Dec 2 09:35:57 charon 60674 01[IKE] <8> local endpoint changed from 192.168.33.20[500] to 192.168.33.20[4500] Dec 2 09:35:57 charon 60674 01[IKE] <8> remote endpoint changed from 192.168.33.217[500] to 192.168.33.217[4500] Dec 2 09:35:57 charon 60674 01[CFG] <8> looking for peer configs matching 192.168.33.20[192.168.33.20]...192.168.33.217[192.168.33.217] Dec 2 09:35:57 charon 60674 01[CFG] <8> candidate "con-mobile", match: 20/1/1052 (me/other/ike) Dec 2 09:35:57 charon 60674 01[CFG] <con-mobile|8> selected peer config 'con-mobile' Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> initiating EAP_IDENTITY method (id 0x00) Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> processing INTERNAL_IP4_ADDRESS attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> processing INTERNAL_IP4_NETMASK attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> processing INTERNAL_IP4_DHCP attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> processing INTERNAL_IP4_DNS attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> processing INTERNAL_IP6_ADDRESS attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> processing INTERNAL_IP6_DHCP attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> processing INTERNAL_IP6_DNS attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> processing INTERNAL_DNS_DOMAIN attribute Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> peer supports MOBIKE Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> authentication of '192.168.33.20' (myself) with RSA signature successful Dec 2 09:35:57 charon 60674 01[IKE] <con-mobile|8> sending end entity cert "XXXXXXX" Dec 2 09:35:57 charon 60674 01[ENC] <con-mobile|8> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ] Dec 2 09:35:57 charon 60674 01[ENC] <con-mobile|8> splitting IKE message (1312 bytes) into 2 fragments Dec 2 09:35:57 charon 60674 01[ENC] <con-mobile|8> generating IKE_AUTH response 1 [ EF(1/2) ] Dec 2 09:35:57 charon 60674 01[ENC] <con-mobile|8> generating IKE_AUTH response 1 [ EF(2/2) ] Dec 2 09:35:57 charon 60674 01[NET] <con-mobile|8> sending packet: from 192.168.33.20[4500] to 192.168.33.217[4500] (1236 bytes) Dec 2 09:35:57 charon 60674 01[NET] <con-mobile|8> sending packet: from 192.168.33.20[4500] to 192.168.33.217[4500] (148 bytes) Dec 2 09:36:27 charon 60674 14[JOB] <con-mobile|7> deleting half open IKE_SA with 192.168.33.217 after timeout Dec 2 09:36:27 charon 60674 14[IKE] <con-mobile|7> IKE_SA con-mobile[7] state change: CONNECTING => DESTROYING Dec 2 09:36:27 charon 60674 14[JOB] <con-mobile|8> deleting half open IKE_SA with 192.168.33.217 after timeout Dec 2 09:36:27 charon 60674 14[IKE] <con-mobile|8> IKE_SA con-mobile[8] state change: CONNECTING => DESTROYING
Updated by Jim Pingle about 3 years ago
Danilo Zrenjanin wrote in #note-4:
With or without the patch applied, I couldn't establish a connection with the server. For some reason, the connection moves to NAT-T even though there was no NAT in the path.
That would be unrelated to this. It appears the client rejected the connection, not the server. In the type of setup being tested here, it works with and without the patch the only difference is whether or not the static address and other per-user settings are applied.
Updated by Viktor Gurov about 3 years ago
works fine on pfSense-2.6.0.a.20211130.0600 without patch:
Dec 3 12:22:39 pf100 charon[64306]: 12[CFG] <con-mobile-userpool-1|4> selecting traffic selectors for other:
Dec 3 12:22:39 pf100 charon[64306]: 12[CFG] <con-mobile-userpool-1|4> config: 10.66.66.3/32|/0, received: 0.0.0.0/0|/0 => match: 10.66.66.3/32|/0
Dec 3 12:22:39 pf100 charon[64306]: 12[CFG] <con-mobile-userpool-1|4> config: 10.66.66.3/32|/0, received: ::/0|/0 => no match
Dec 3 12:22:39 pf100 charon[64306]: 12[CHD] <con-mobile-userpool-1|4> CHILD_SA con-mobile{2} state change: CREATED => INSTALLING
Dec 3 12:22:39 pf100 charon[64306]: 12[CHD] <con-mobile-userpool-1|4> using AES_CBC for encryption
Dec 3 12:22:39 pf100 charon[64306]: 12[CHD] <con-mobile-userpool-1|4> using HMAC_SHA1_96 for integrity
Dec 3 12:22:39 pf100 charon[64306]: 12[CHD] <con-mobile-userpool-1|4> adding inbound ESP SA
Dec 3 12:22:39 pf100 charon[64306]: 12[CHD] <con-mobile-userpool-1|4> SPI 0xc679b29a, src 192.168.88.3 dst 192.168.88.100
Dec 3 12:22:39 pf100 charon[64306]: 12[CHD] <con-mobile-userpool-1|4> adding outbound ESP SA
Dec 3 12:22:39 pf100 charon[64306]: 12[CHD] <con-mobile-userpool-1|4> SPI 0xc38cc878, src 192.168.88.100 dst 192.168.88.3
Debian 11.1 client:
дек 03 12:22:39 pand charon-nm[697161]: 05[ENC] parsed IKE_AUTH response 5 [ AUTH CPRP(ADDR SUBNET) N(ESP_TFC_PAD_N) SA TSi TSr ]
дек 03 12:22:39 pand charon-nm[697161]: 05[IKE] authentication of '192.168.88.100' with EAP successful
дек 03 12:22:39 pand charon-nm[697161]: 05[IKE] IKE_SA IPsec-test[7] established between 172.21.23.91[eapuser1]...192.168.88.100[192.168.88.100]
дек 03 12:22:39 pand charon-nm[697161]: 05[IKE] scheduling rekeying in 35425s
дек 03 12:22:39 pand charon-nm[697161]: 05[IKE] maximum IKE_SA lifetime 36025s
дек 03 12:22:39 pand charon-nm[697161]: 05[CFG] handling INTERNAL_IP4_SUBNET attribute failed
дек 03 12:22:39 pand charon-nm[697161]: 05[IKE] installing new virtual IP 10.66.66.3
дек 03 12:22:39 pand charon-nm[697161]: 05[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
дек 03 12:22:39 pand charon-nm[697161]: 05[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
дек 03 12:22:39 pand charon-nm[697161]: 05[IKE] CHILD_SA IPsec-test{6} established with SPIs c38cc878_i c679b29a_o and TS 10.66.66.3/32 === 192.168.88.0/24
swanctl.conf:
# This file is automatically generated. Do not edit
connections {
bypass {
remote_addrs = 127.0.0.1
children {
bypasslan {
local_ts = 192.168.88.0/24,fc00:88::/64
remote_ts = 192.168.88.0/24,fc00:88::/64
mode = pass
start_action = trap
}
}
}
con-mobile : con-mobile-defaults {
# Stub to load con-mobile-defaults
}
con-mobile-userpool-1 : con-mobile-defaults {
remote {
id = "eapuser1"
eap_id = %any
}
pools = mobile-userpool-1
}
}
con-mobile-defaults {
fragmentation = yes
unique = replace
version = 2
proposals = aes128-sha256-modp2048
dpd_delay = 10s
dpd_timeout = 60s
rekey_time = 25920s
reauth_time = 0s
over_time = 2880s
rand_time = 2880s
encap = no
mobike = no
local_addrs = 192.168.88.100
remote_addrs = 0.0.0.0/0,::/0
send_cert = always
local {
id = 192.168.88.100
auth = pubkey
cert {
file = /var/etc/ipsec/x509/cert-2.crt
}
}
remote {
id = %any
eap_id = %any
auth = eap-mschapv2
}
children {
con-mobile {
# P2 (reqid 3)
mode = tunnel
policies = yes
life_time = 3600s
rekey_time = 3240s
rand_time = 360s
start_action = none
local_ts = 192.168.88.0/24
esp_proposals = aes256gcm128-modp2048,aes256gcm96-modp2048,aes256gcm64-modp2048,aes192gcm128-modp2048,aes192gcm96-modp2048,aes192gcm64-modp2048,aes128gcm128-modp2048,aes128gcm96-modp2048,aes128gcm64-modp2048,aes256-sha1-modp2048,aes256-sha256-modp2048,aes192-sha1-modp2048,aes192-sha256-modp2048,aes128-sha1-modp2048,aes128-sha256-modp2048
dpd_action = clear
}
}
}
pools {
mobile-userpool-1 : mobile-pool {
addrs = 10.66.66.3/32
}
}
mobile-pool {
# Mobile pool settings template
}
secrets {
private-0 {
file = /var/etc/ipsec/private/cert-2.key
}
eap-1 {
secret = 0sMTIz
id-0 = eapuser1
}
}
Updated by Viktor Gurov about 3 years ago
but it doesn't work with the email id:
Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> authentication of 'email' with EAP successful Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> authentication of '192.168.88.100' (myself) with EAP Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> IKE_SA con-mobile[2] established between 192.168.88.100[192.168.88.100]...1 92.168.88.3[email] Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> IKE_SA con-mobile[2] state change: CONNECTING => ESTABLISHED Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> scheduling rekeying in 24451s Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> maximum IKE_SA lifetime 27331s Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> peer requested virtual IP %any Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> no virtual IP found for %any requested by 'eapuser1@home.lab' Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> peer requested virtual IP %any6 Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> no virtual IP found for %any6 requested by 'eapuser1@home.lab' Dec 3 13:20:51 pf100 charon[88381]: 09[IKE] <con-mobile|2> no virtual IP found, sending INTERNAL_ADDRESS_FAILURE
swanctl.conf diff:
...
con-mobile-userpool-1 : con-mobile-defaults {
remote {
id = "eapuser1@home.lab"
eap_id = %any
}
pools = mobile-userpool-1
}
...
secrets {
private-0 {
file = /var/etc/ipsec/private/cert-2.key
}
eap-1 {
secret = 0sMTIz
id-0 = eapuser1@home.lab
}
}
Updated by Jim Pingle about 3 years ago
The debian client sends the username as the IKE ID, others do not. It's not a great data point given the relative rarity of that client in the wild compared to others like Windows. It needs to somehow match either the IKE ID being the username or the eap_id being the username.
Updated by Jim Pingle about 3 years ago
I did some experiments on a few different styles/settings but so far haven't been able to get it to work any better than with my first patch.
Updated by Max Leighton about 3 years ago
I was able to connect to an IKEv2 MSCHAPv2 mobile tunnel on 2.6.0 running this patch. My test client was Windows 10. I noticed a weird behavior where it would not accept my PSK the first time I would try to connect, but after the second attempt I could successfully authenticate and my client would have the static address specified in the PSK settings.
There is a bug in Windows 10 (not pfSense) that causes the client to get stuck trying to authenticate after an invalid password when using the Settings app, so I was using rasphone.exe to connect.
Updated by Jim Pingle almost 3 years ago
- Target version changed from 2.6.0 to CE-Next
- Plus Target Version changed from 22.01 to 22.05
Updated by Marcos M almost 3 years ago
A user testing this patch mentioned that after some days, the client received a different IP assigned reserved for a different client.
Updated by Jim Pingle over 2 years ago
- Plus Target Version changed from 22.05 to 22.09
Updated by Jim Pingle over 2 years ago
- Plus Target Version changed from 22.09 to 22.11
Updated by Jim Pingle about 2 years ago
- Plus Target Version changed from 22.11 to 23.01
Updated by Jim Pingle about 2 years ago
- Target version changed from CE-Next to 2.7.0
- Plus Target Version changed from 23.01 to 23.05
Still needs more thought here. The differences in client behavior and which values they send may make this impossible to address consistently for all clients.
Updated by Jim Pingle over 1 year ago
- Plus Target Version changed from 23.05 to 23.09
Updated by Jim Pingle over 1 year ago
- Target version changed from 2.7.0 to CE-Next
Updated by Jim Pingle over 1 year ago
- Plus Target Version changed from 23.09 to 24.01
Clients are still not behaving a way that appears to be fixable for all of them at once. Will keep checking, though.
Updated by Jim Pingle about 1 year ago
- Plus Target Version changed from 24.01 to 24.03
Updated by Jim Pingle 10 months ago
- Plus Target Version changed from 24.03 to 24.07
Updated by Roland Giesler 9 months ago
Just to check: Has then been resolved, or is it still pending resolution?
Updated by Jim Pingle 9 months ago
It's still marked as "New" and open so no, it has not been resolved.
Updated by Jim Pingle 7 months ago
- Plus Target Version changed from 24.07 to 24.08
Updated by Jim Pingle 3 months ago
- Plus Target Version changed from 24.08 to Plus-Next
Updated by Jim Pingle 6 days ago
- Has duplicate Bug #15931: Mobile IPsec clients do not receive IP addresses from the virtual pools assigned to individual clients. added
Actions