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

    IPSec for Mobile Clients not working 2.3_1

    Scheduled Pinned Locked Moved IPsec
    22 Posts 7 Posters 5.1k 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.
    • S
      stiadmin
      last edited by

      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>

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        How's your mobile P1 configured?

        1 Reply Last reply Reply Quote 0
        • S
          stiadmin
          last edited by

          Screenshots Attached.

          2016-05-12_18h24_58.png
          2016-05-12_18h24_58.png_thumb
          2016-05-12_18h25_10.png
          2016-05-12_18h25_10.png_thumb

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            Ok so no PSKs in the P1. Where and how do you have the PSKs defined?

            1 Reply Last reply Reply Quote 0
            • S
              stiadmin
              last edited by

              Under the Pre-Shared Keys tab.

              Untitled2.png
              Untitled2.png_thumb

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                The part you see in brackets after the client's IP in this log:

                @stiadmin:

                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.

                1 Reply Last reply Reply Quote 0
                • S
                  stiadmin
                  last edited by

                  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).

                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    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.*).

                    1 Reply Last reply Reply Quote 0
                    • S
                      stiadmin
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • C
                        cmb
                        last edited by

                        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).

                        1 Reply Last reply Reply Quote 0
                        • H
                          hodgiers
                          last edited by

                          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.

                          1 Reply Last reply Reply Quote 0
                          • C
                            cmb
                            last edited by

                            @hodgiers:

                            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.

                            1 Reply Last reply Reply Quote 0
                            • S
                              stiadmin
                              last edited by

                              PM Sent!

                              1 Reply Last reply Reply Quote 0
                              • W
                                wikidd
                                last edited by

                                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>

                                1 Reply Last reply Reply Quote 0
                                • E
                                  emkowale
                                  last edited by

                                  I can confirm this problem as well.

                                  1 Reply Last reply Reply Quote 0
                                  • W
                                    wikidd
                                    last edited by

                                    I can confirm that with last nights upgrade to 2.3.1 Mobile VPN is working again.

                                    1 Reply Last reply Reply Quote 0
                                    • S
                                      stiadmin
                                      last edited by

                                      I will run the update tonight and see if it resolved the issue for us as well.

                                      1 Reply Last reply Reply Quote 0
                                      • F
                                        flame
                                        last edited by

                                        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 ;)

                                        1 Reply Last reply Reply Quote 0
                                        • S
                                          stiadmin
                                          last edited by

                                          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.

                                          1 Reply Last reply Reply Quote 0
                                          • K
                                            kapara
                                            last edited by

                                            are you able to get shrewsoft client to work with latests pfsense version?

                                            Skype ID:  Marinhd

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