IPSec for Mobile Clients not working 2.3_1
-
Upgraded from 2.6 to 2.3 and then 2.3_1 looks like all point to point IPSec connections are working just fine. However the mobile IPSec does not. I am using shrewsoft for the mobile clients to connect. In the IPSec logs I keep getting the following error:
05[IKE] <con2|101>no shared key found for "IP of Pfsense" [IP of Pfsense] and "Authentication string ie: user@something.com or fake IP like 50.50.50.50" [Public WAN IP of Client]
This error persists if I change the authentication string to anything on the client side of things (fake IP, FQDN, etc) and the connection is only successful if I go into the IPSec page and then go to the "Pre-Shared Keys" section, then add the Public WAN IP address of the client as a Pre-Shared Key. This obviously isn't a fix because the clients Public WAN IP changes every time they connect.
It seems that PfSense is checking the public IP address of the mobile client instead of the Authentication string when comparing values against what is stored in the Pre-Shared Keys table.
Any help would be greatly appreciated!</con2|101>
-
How's your mobile P1 configured?
-
Screenshots Attached.
-
Ok so no PSKs in the P1. Where and how do you have the PSKs defined?
-
Under the Pre-Shared Keys tab.
-
The part you see in brackets after the client's IP in this log:
05[IKE] <con2|101>no shared key found for "IP of Pfsense" [IP of Pfsense] and "Authentication string ie: user@something.com or fake IP like 50.50.50.50" [Public WAN IP of Client]</con2|101>
Assuming that was something like [50.50.50.50] at the end where client was coming from 50.50.50.50, that means the client is actually sending its IP as its identifier. So yes, with that config you would have to add the public IP of the client as the identifier. The Shrewsoft config must have its local identifier set to type "IP Address", and the checkbox "Use a discovered local host address" must be checked.
That doesn't look like something that would have (or should have) ever worked. I don't recall any changes in how the PSKs are written out in that regard which could change the behavior. It definitely wouldn't have changed the client-side behavior, and wouldn't have matched on IP unless a PSK with the IP was defined.
-
In shrewsoft you can override the IP to something like 50.50.50.50. The issue is not that this specific way is not working. It is that nothing is working, all of these ways did work in the previous releases 1.3.4 - 2.2.6 (and is currently working in them) so I would assume that it is the update to 2.3 that broke the issue since there have been no changes to any of the clients and all are experiencing the same issue…
I do believe the issue is that PfSense is parsing the two strings in reverse order it is parsing the Authentication string as the WAN IP and the WAN IP as the Authentication string. I don't know where in the code to go to check this, but based on my testing I am fairly confident that this is happening. OR PfSense is just ignoring the Authentication string all together and only checking against the WAN IP. (These authentication strings being the values passed by the IPSec Client to be compared against the ones in the Pre-Shared Keys table on PfSense).
-
The conf files are in /var/etc/ipsec/
I know for a fact that many people using Shrewsoft with configs like that have upgraded. The only issue along those lines I'm aware of in 2.3 is this.
https://redmine.pfsense.org/issues/6286
but that was exactly the same circumstance in 2.2.6 and all prior versions with strongswan (2.2.*). -
Any recommendations on how to further troubleshoot then? Everything was working before the upgrade, none of the clients have changed, yet all of the clients cannot connect anymore. Also affects clients running the Mac built in IPSec client, so it is not isolated to Shrewsoft.
-
PM me your exact IPsec logs, and the contents of /var/etc/ipsec/ipsec.secrets (you can omit the part at the end after 0s, which is the actual PSK).
-
I can confirm I'm experiencing the same issue using my Macbook Pro's native VPN client. After an upgrade the connection is broken.
I've also noticed that for some reason the VPN won't allow me to use aggressive mode for phase 1. Even if I select it and save/apply the config, it reverts to main mode which I believe could be the cause as the Macbook's client can only use aggressive if I recall correctly.
-
I can confirm I'm experiencing the same issue using my Macbook Pro's native VPN client. After an upgrade the connection is broken.
I've also noticed that for some reason the VPN won't allow me to use aggressive mode for phase 1. Even if I select it and save/apply the config, it reverts to main mode which I believe could be the cause as the Macbook's client can only use aggressive if I recall correctly.
Not the same issue. Sounds like you have IKE version auto, should be IKEv1 for that purpose. There is an issue there with the mode with IKE auto, I'll fix that, but that's not the source of your issue.
The reason in your case is probably having the Unity plugin disabled by default. VPN>IPsec, Advanced, enable Unity there.
stiadmin: you might want to try enabling Unity as well, though I'm guessing in your case it won't matter either way.
-
PM Sent!
-
We just migrated our router to 2.3.1 and using the same configs on both the pre 2.3.x and the 2.3.1 we cannot get Mobile VPN to work but the IPSEC peer to peer tunnels are fine. We have rebuilt the configs multiple times with the same error coming back.
08[IKE] <con6|1>message parsing failed
08[ENC] <con6|1>could not decrypt payloads
08[ENC] <con6|1>invalid HASH_V1 payload length, decryption failed?Everything is correct and we can still connect with the pre 2.3.x box. We will be moving to OpenVPN for the time being for mobile users but there is definately something up with MobileVPN.</con6|1></con6|1></con6|1>
-
I can confirm this problem as well.
-
I can confirm that with last nights upgrade to 2.3.1 Mobile VPN is working again.
-
I will run the update tonight and see if it resolved the issue for us as well.
-
We had the same problem.
It seems there is a problem with the static entry of the local ip adress at the client vpn settings.Try to change from static to IKE-config pull.
Under VPN-> IPSec-> Mobile Clients aktivate "Virtual Address Pool - Provide a virtual IP address to clients" if not done yet.After changing from static ip-setting to ike-config pull our mobile clients work as a charm.
Ann.:
Identifier was not changed.regards
–--------
Thanks to Stefan S. for this workaround ;) -
After running the update to 2.3.1 it does not appear that our issue has been resolved. We already have the Virtual IP pool setup (it was already previously setup that way). We will test the Mac clients today to see if the issue has been resolved, but the Windows Machines running ShrewSoft still cannot connect unless the WAN IP is stored in PfSense as the Key Identifier.
-
are you able to get shrewsoft client to work with latests pfsense version?
-
I will upgrade to the latest version tonight or tomorrow to see if it resolves the issue.
-
ok thanks. I am struggling to find a clear tutorial for this on 2.3.