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

    Multiple issues on RSA IPsec on v2.2.3 (incl bug reports and possible solutions)

    Scheduled Pinned Locked Moved IPsec
    3 Posts 3 Posters 914 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.
    • G
      georgeman
      last edited by

      Hi guys, let me outline some issues I have found with RSA IPsec, which I already debugged, found the cause, workarounds and reported the bugs  ;)

      Wrong settings for rightid in ipsec.conf

      The webconfigurator sets rightid = asn1dn:whateverYouEntered on ipsec.conf if you select "ASN1 distinguished name" as peer identifier, which causes charon to complain about a mismatch there.

      As per strongSwan documentation:

      Since 5.2.2 it is possible to enforce a specific identity type. For this a prefix may be used, followed by a colon (:).
      If the number sign (#) follows the colon, the remaining data is interpreted as hex encoding, otherwise the string is used as-is
      as the identification data. Note that this implies that no conversion is performed for non-string identities.
      For example, ipv4:10.0.0.1 does not create a valid ID_IPV4_ADDR IKE identity, as it does not get converted to binary
      0x0a000001. Instead, one could use ipv4:#0a000001 to get a valid identity, but just using the implicit type with automatic
      conversion is usually simpler. The same applies to the ASN.1 encoded types.
      The following prefixes are known: ipv4, ipv6, rfc822, email, userfqdn, fqdn, dns, asn1dn, asn1gn and keyid.
      Custom type prefixes may be specified by surrounding the numerical type value with curly brackets.

      So this means that if you specify asn1dn as the type, the data needs to be the certificate CN in ASN1 format, in hex form (which can be extracted following this procedure). I did all this "openssl to hex nightmare" and it indeed works. Still it is probably simpler to avoid specifying the identity type prefix and let strongSwan figure out the correct type and make the appropiate conversion. Consider that the ASN1DN type is not the only one affected, IP addresses for example would still need to be converted to hex if the identity prefix is specified.

      Workaround: edit /etc/inc/vpn.inc on line 767 onwards, remove the if clause so it always make $peerid_spec = $peerid_data

      Bug report: 4792 (was about to file it myself but found it was reported earlier today)

      Handling of upgrades from v2.1.x

      The certificate CNs are interpreted differently by raccoon and strongSwan, for example:

      raccoon:
      C=US, ST=Whatever, L=Springfield, O=Springfield Power Plant/emailAddress=burns@powerplant.com, CN=springfield.powerplant.com

      strongSwan:
      "C=US, ST=Whatever, L=Springfield, O=Springfield Power Plant, E=burns@powerplant.com, CN=springfield.powerplant.com"

      So on upgrades from v2.1.x and before, some regex needs to be done on the ASN1DN field. Also, the value needs to be surrounded in quotes, but be careful because if the identity prefix is provided, the prefix must be included within the quotes, eg: rightid = "asn1dn:#hexvalue…"

      Bug report: 4794

      ~~IPsec logging is not working at all

      Just that, it doesn't log anywhere even if setting all values to "highest". I had to manually modify strongswan.conf to force it to log to a specific file in order to debug all this. Anyway this is not related to strongSwan itself, probably a bug on how the syslog is handled.

      Bug report: 4795~~

      Update 06/29/2015: there was no problem with IPsec logging. I had two systems which were hit by some (still) unidentified condition related to bug 4393 and the whole syslog was not working across reboots.

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

      1 Reply Last reply Reply Quote 0
      • J
        joegeorge
        last edited by

        I'm also having issues with certificates since 2.2.3. KeyID = %any doesn't seem to work anymore. The linerightid = keyid:is generated, in 2.2.2 it was```
        rightid = %any

        1 Reply Last reply Reply Quote 0
        • V
          vbentley
          last edited by

          @georgeman:

          Hi guys, let me outline some issues I have found with RSA IPsec, which I already debugged, found the cause, workarounds and reported the bugs  ;)

          georgeman, thank you, thank you, thank you!

          I did suspect it was a data matching problem, thanks for proving it.

          Trademark Attribution and Credit
          pfSense® and pfSense Certified® are registered trademarks of Electric Sheep Fencing, LLC in the United States and other countries.

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