[strongSwan] Faulty SubjectAltName

[Andreas Steffen]

Well if VPN-1 sends you its real IP address as an ID
then you are definitively fried :-(

No chance to change the ID on Checkpoint box?

Andreas

On 06/25/2010 03:21 PM, Johannes Tysiak wrote:
> Hi Andreas,
> 
> thank you very much for your quick answer. Unfortunately your suggestion
> did not solve my problem entirely. Let me give you some more information
> on my setup.
> 
> I am running strongSwan 4.3.2 installed from the Ubuntu 10.04
> repository. My /etc/ipsec.conf looks like this:
> 
> ******
> config setup
>         nat_traversal=yes
>         plutodebug=control
>         crlcheckinterval=180
>         strictcrlpolicy=no
>         charonstart=no
> 
> conn %default
>         ikelifetime=60m
>         keylife=20m
>         rekeymargin=3m
>         keyingtries=1
> 
> conn xxx
>         left=%defaultroute
>         leftcert=<my-user-cert>.pem
>         leftid=<myid>
>         leftfirewall=yes
>         right=<real IP of the VPN-1 gateway>
>         rightid=<faulty IP found in the VPN-1 cert subjectAltName>
>         keyexchange=ikev1
>         ike=3des-sha1-modp1024,3des-md5-modp1024
>         auto=add
> ******
> 
> I extracted the key and certificate information like suggested in this
> link: http://www.fw-1.de/aerasec/ng/vpn-freeswan/CP-FW1-NG
> +Linux-FreeSWAN-RoadWarrior.html#freeswan-x509-roadwarrior
> 
> Currently the result looks like this:
> 
> ******
> ipsec up xxx
> 002 "xxx" #2: initiating Main Mode
> 104 "xxx" #2: STATE_MAIN_I1: initiate
> 003 "xxx" #2: received Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-02_n]
> 002 "xxx" #2: enabling possible NAT-traversal with method RFC 3947
> 106 "xxx" #2: STATE_MAIN_I2: sent MI2, expecting MR2
> 003 "xxx" #2: NAT-Traversal: Result using
> draft-ietf-ipsec-nat-t-ike-02/03: both are NATed
> 002 "xxx" #2: we have a cert and are sending it upon request
> 108 "xxx" #2: STATE_MAIN_I3: sent MI3, expecting MR3
> 002 "xxx" #2: Peer ID is ID_IPV4_ADDR: '<real VPN-1 IP>'
> 003 "xxx" #2: no public key known for '<real VPN-1 IP>'
> 217 "xxx" #2: STATE_MAIN_I3: INVALID_KEY_INFORMATION
> 002 "xxx" #2: sending encrypted notification INVALID_KEY_INFORMATION to
> <real VPN-1 IP>:4500
> ******
> 
> Any hints on what I could try next? I feel like I am running out of
> ideas, though I still haven't given up.
> 
> Once more, thanks a lot for your help!
> 
> Best regards,
> Johannes
> 
> On Fri, 2010-06-25 at 04:14 +0200, Andreas Steffen wrote:
>> Hi Johannes,
>>
>> 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>
>>
>> Best regards
>>
>> Andreas
>>
>> 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
>>> [draft-ietf-ipsec-nat-t-ike-02_n]
>>> 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
>>> w.x.y.z:4500
>>> *****
>>>
>>> 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.
>>>
>>> Cheers,
>>> Johannes

======================================================================
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)
===========================================================[ITA-HSR]==

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3430 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20100625/f54160b1/attachment.bin>