[strongSwan] Faulty SubjectAltName
andreas.steffen at strongswan.org
Fri Jun 25 04:14:45 CEST 2010
this is a well known Checkpoint VPN-1 phenomenon where the
certicate contains the IP address the node-locked software
license is tied to which is strangely enough sometimes not
the same IP address the traffic is coming from.
The workaround is simple. On the strongSwan box just define:
right=<actual IP address of the VPN-1 box>
rightid=<IP address contained in the subjectAltName>
On 25.06.2010 00:43, Johannes Tysiak wrote:
> Hello everyone,
> I am trying to connect to a Checkpoint VPN-1 using strongswan.
> Unfortunately the VPN-1's certificate is faulty, i.e. the IP address in
> the SubjectAltName differs from the IP address of the VPN-1. This causes
> the following log:
> ipsec up xxx
> 002 "xxx" #1: initiating Main Mode
> 104 "xxx" #1: STATE_MAIN_I1: initiate
> 003 "xxx" #1: received Vendor ID payload
> 002 "xxx" #1: enabling possible NAT-traversal with method RFC 3947
> 106 "xxx" #1: STATE_MAIN_I2: sent MI2, expecting MR2
> 003 "xxx" #1: NAT-Traversal: Result using
> draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
> 002 "xxx" #1: we have a cert and are sending it upon request
> 108 "xxx" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> 002 "xxx" #1: Peer ID is ID_IPV4_ADDR: 'w.x.y.z'
> 003 "xxx" #1: no public key known for 'w.x.y.z'
> 217 "xxx" #1: STATE_MAIN_I3: INVALID_KEY_INFORMATION
> 002 "xxx" #1: sending encrypted notification INVALID_KEY_INFORMATION to
> I have no possibility to correct the wrong config on the VPN-1 side, so
> I have to deal with the faulty certificate. Is there any way to achieve
> this using strongswan (e.g. forcing a specific certificate to be used
> while ignoring the faulty SubjectAltName?
> Thanks very much for your help.
> Users mailing list
> Users at lists.strongswan.org
Andreas Steffen andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3430 bytes
Desc: S/MIME Cryptographic Signature
More information about the Users