[Swan-dev] Is it possible to have multiple roaming user to connect with one IPSec server using certificate in ikev2 mode for libreswan

jeffchen jeffchen at ruggedcom.com
Thu May 1 16:47:28 EEST 2014


> On Wed, 30 Apr 2014, jeffchen wrote:
>
>> I am trying to use certificate to connect multiple roaming user with one
>> IPSec server (each side is running libreswan 3.8).
>> It failed when I use ikev2 mode. If I use ikev1 mode (by removing the line
>> ikev2=insist), it works fine.
>>
>> Below is my configuration. Is there anything wrong in the configuration to
>> make it work in ikev2 mode? Thanks.
> That should be possible yes.
>
>> conn R2-R9
>>         authby=rsasig
>>         auto=add
>>         phase2=esp
>>         ikev2=insist
>>         left=192.168.22.2
>>         leftcert=R4
>>         leftid="C=CA, ST=Ontario, O=RuggedCom, CN=R4, E=R4 at example.com"
>>         leftnexthop=%defaultroute
>>         leftsubnet=192.168.21.0/24
>>         pfs=no
>>         right=%any
>>         rightid=%fromcert
>>         rightupdown="ipsec _updown --route yes"
>>         type=tunnel
> perhaps add leftsendcert=always
>
>> conn R2-R9
>>         connaddrfamily=ipv4
>>         authby=rsasig
>>         auto=start
>>         phase2=esp
>>         ikev2=insist
>>         left=192.168.22.2
>>         leftid="C=CA, ST=Ontario, O=RuggedCom, CN=R4, E=R4 at example.com"
>>         leftsubnet=192.168.21.0/24
>>         pfs=no
>>         right=192.168.34.9
>>         rightcert=R9
>>         rightid="C=CA, ST=Ontario, O=RuggedCom, CN=R9, E=R9 at example.com"
>>         rightnexthop=%defaultroute
>>         rightupdown="ipsec _updown --route yes"
>>         type=tunnel
>>
>> The tunnel is established successfully in ikev1 mode. But failed in ikev2
>> mode. It gives the following error message in ikev2 mode:
>> Apr 30 09:44:18 rrjc2 pluto[5068]: "R2-R9"[1] 192.168.34.9 #1: no RSA public key known for '%fromcert'
> That might be a bug in the IKEv2 code. Can you try adding
> rightsendcert=always here and let me know if that makes a difference.
>
> I'll do some testing regarding this issue and try to reproduce it.
>
> Paul
It still has the same problem. I tried to use ikev1 (which works 
successfully), and compare the log between ikev1 and ikev2, I found in 
ikev1 mode, it called refine_connection function where is uses %fromcert 
and find the right connection. Below is the log in ikev1 mode.

Apr 29 14:36:18 rrjc2 pluto[20743]: | requested CA: '%any'
Apr 29 14:36:18 rrjc2 pluto[20743]: | refine_connection: starting with R2-R9
Apr 29 14:36:18 rrjc2 pluto[20743]: |    match_id a=C=CA, ST=Ontario, 
O=RuggedCom, CN=R9, E=R9 at example.com
Apr 29 14:36:18 rrjc2 pluto[20743]: |             b=%fromcert
Apr 29 14:36:18 rrjc2 pluto[20743]: |    results  fail
Apr 29 14:36:18 rrjc2 pluto[20743]: |   trusted_ca called with a=C=CA, 
ST=Ontario, O=RuggedCom, CN=CA, E=ca at example.com b=(empty)
Apr 29 14:36:18 rrjc2 pluto[20743]: | refine_connection: checking R2-R9 
against R2-R9, best=(none) with match=0(id=0/ca=1/reqca=1)
Apr 29 14:36:18 rrjc2 pluto[20743]: | refine_connection: checked R2-R9 
against R2-R9, now for see if best
Apr 29 14:36:18 rrjc2 pluto[20743]: | started looking for secret for 
C=CA, ST=Ontario, O=RuggedCom, CN=R4, E=R4 at example.com->%fromcert of 
kind PPK_RSA
Apr 29 14:36:18 rrjc2 pluto[20743]: | searching for certificate 
PPK_RSA:AwEAAahLI vs PPK_RSA:AwEAAahLI
Apr 29 14:36:18 rrjc2 pluto[20743]: | k did match
Apr 29 14:36:18 rrjc2 pluto[20743]: | n did match
Apr 29 14:36:18 rrjc2 pluto[20743]: | e did match
Apr 29 14:36:18 rrjc2 pluto[20743]: | refine_connection: picking new 
best R2-R9 (wild=0, peer_pathlen=7/our=0)
Apr 29 14:36:18 rrjc2 pluto[20743]: | find_host_pair: comparing to 
192.168.22.2:500 192.168.34.9:500
Apr 29 14:36:18 rrjc2 pluto[20743]: | find_host_pair: comparing to 
192.168.22.2:500 0.0.0.0:500
Apr 29 14:36:18 rrjc2 pluto[20743]: | find_host_pair_conn 
(refine_host_connection): 192.168.22.2:500 %any:500 -> hp:R2-R9
Apr 29 14:36:18 rrjc2 pluto[20743]: |    match_id a=C=CA, ST=Ontario, 
O=RuggedCom, CN=R9, E=R9 at example.com
Apr 29 14:36:18 rrjc2 pluto[20743]: |             b=%fromcert
Apr 29 14:36:18 rrjc2 pluto[20743]: |    results  fail
Apr 29 14:36:18 rrjc2 pluto[20743]: |   trusted_ca called with a=C=CA, 
ST=Ontario, O=RuggedCom, CN=CA, E=ca at example.com b=(empty)
Apr 29 14:36:18 rrjc2 pluto[20743]: | refine_connection: checking R2-R9 
against R2-R9, best=R2-R9 with match=0(id=0/ca=1/reqca=1)
Apr 29 14:36:18 rrjc2 pluto[20743]: | refine_connection: checked R2-R9 
against R2-R9, now for see if best
Apr 29 14:36:18 rrjc2 pluto[20743]: | started looking for secret for 
C=CA, ST=Ontario, O=RuggedCom, CN=R4, E=R4 at example.com->%fromcert of 
kind PPK_RSA
Apr 29 14:36:18 rrjc2 pluto[20743]: | searching for certificate 
PPK_RSA:AwEAAahLI vs PPK_RSA:AwEAAahLI
Apr 29 14:36:18 rrjc2 pluto[20743]: | k did match
Apr 29 14:36:18 rrjc2 pluto[20743]: | n did match
Apr 29 14:36:18 rrjc2 pluto[20743]: | e did match
Apr 29 14:36:18 rrjc2 pluto[20743]: | offered CA: 'C=CA, ST=Ontario, 
O=RuggedCom, CN=CA, E=ca at example.com'
Apr 29 14:36:18 rrjc2 pluto[20743]: | copying ID for fromcert


-- 
Jeff Chen



More information about the Swan-dev mailing list