Multiple issues on RSA IPsec on v2.2.3 (incl bug reports and possible solutions)
-
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.comstrongSwan:
"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.
-
I'm also having issues with certificates since 2.2.3. KeyID = %any doesn't seem to work anymore. The line
rightid = keyid:is generated, in 2.2.2 it was```
rightid = %any -
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.