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

    Site to Site Tunnel with Mutual RSA stopped working after 2.2 upgrade

    Scheduled Pinned Locked Moved IPsec
    5 Posts 4 Posters 2.3k 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.
    • I
      interush
      last edited by

      Our site to site tunnel ceased to function after upgrading from 2.1.5 to 2.2, with no other changes having occurred. I've been able to temporarily bring the tunnel back up using a pre-shared key, but for security purposes we'd like to get back on mutual RSA. I've moved away from ASN.1 Distinguished names and reverted to setting the peer and remote identifiers, to no avail. Has anyone else run into an issue using certificates for authentication as opposed to a PSK? The pertinent details from logging seem to be:

      Feb 5 08:17:50 charon: 02[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
      Feb 5 08:17:50 charon: 02[IKE] <con1|459>received AUTHENTICATION_FAILED notify error
      Feb 5 08:17:50 charon: 02[IKE] received AUTHENTICATION_FAILED notify error</con1|459>

      1 Reply Last reply Reply Quote 0
      • G
        georgeman
        last edited by

        Watch out the logs for the exact certificate CN that strongswan expects. I also run an RSA VPN and when upgraded to 2.2 found out that the CN is sent with a slightly different syntax, which led to authentication issues

        If it ain't broke, you haven't tampered enough with it

        1 Reply Last reply Reply Quote 0
        • M
          MichelZ
          last edited by

          Yes, the certificate CN is different in 2.2 as it was in 2.1.5.
          To give you an indication, I'm using this:

          "C=US, ST=MyState, L=MyLocation, O=MyOrg, E=My@Email.com, CN=vpn.company.com"

          (including the double quotes, as the strongswan deamon will not come up otherwise)

          1 Reply Last reply Reply Quote 0
          • I
            interush
            last edited by

            Thanks for the replies. This worked like a charm, after placing "C=US, ST=California, L=Irvine, O=MyOrg, E=My@Email.com, CN=OurCertificateName" (with respective options used to actually generate the certificate) as the local/remote identifiers via ASN.1 Distinguished Name the tunnel was able to authenticate as it had before.

            Much appreciated.

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

              Yeah this bug has been fixed in the repository and will come with pfSense 2.2.1 update.

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