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

    Charon does not match sent identity to configured one

    Scheduled Pinned Locked Moved IPsec
    5 Posts 4 Posters 1.8k 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.
    • 8
      8191
      last edited by

      Hi,

      I want to establish an IPSec connection to a Cisco ASA 8.4 using Main mode and mutual RSA authentication. My ASA sends the correct identity (the CN of the certificate) but pfsense does not like it. I've already hardcoded configured the identity using the "Peer identifier" setting "ASN.1 DN", but charon claims the follwing:

      charon: 11[IKE] <con2000|71> IDir 'C=AT, ST=Upper Austria, L=City, O=Example, CN=houston.lan.example.org, unstructuredName=houston.lan.example.org' does not match to ''</con2000|71>
      

      Even I've configured the peer ID to exactly the same string like mentioned in the log record, charon seems only to check it against an empty string (see '' at the end).

      1 Reply Last reply Reply Quote 0
      • D
        doktornotor Banned
        last edited by

        asn1dn won't work at all as it is, stop wasting your time. There's a bug about the strongswan madness somewhere, or multiple of them… like:

        https://redmine.pfsense.org/issues/4792
        https://redmine.pfsense.org/issues/4794

        If you insist on using it, read this:

        https://lists.strongswan.org/pipermail/users/2015-May/008123.html
        https://lists.strongswan.org/pipermail/users/2015-May/008191.html

        and good luck with figuring that out.  ::) >:(

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

          I agree. Binary encode of the ASN1 identifier indeed works but is a mess to obtain.

          Best workaround right now is modify /etc/inc/vpn.inc around line 767, to force skipping the identity prefix altogether. Once done it'll work as in previous versions

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

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

            @georgeman:

            Best workaround right now is modify /etc/inc/vpn.inc around line 767, to force skipping the identity prefix altogether. Once done it'll work as in previous versions

            That'll work for that circumstance, but possibly break others. Should be a fine workaround in your case.

            I'm going through all the possible combinations there now doing testing, with an automated test setup to iterate through all the possibilities. We'll have that resolved for 2.2.4.

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

              @cmb:

              I'm going through all the possible combinations there now doing testing, with an automated test setup to iterate through all the possibilities. We'll have that resolved for 2.2.4.

              Awesome!  :D

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

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