[Openswan Users] Question about ike configuration

mix.kao mix.kao at cipherium.com.tw
Tue Mar 2 04:54:17 EST 2010


Hi Paul,

i am using the Openswan 2.6.24 in two gateways

Test scenario 1:

The difference between two gateways is ike group. gateway1 is group1 and 
gateway2 is group 5, other configuration is all the same.

Test procedure:
1. Initiator from gateway1 group1 to gateway2 group 5, test result 
please see attached file-name: ipsec-ike-diff-group-init-by-group1.log
2. Initiator from gateway2 group5 to gateway1 group 1, test result 
please see attached file-name: ipsec-ike-diff-group-init-by-group5.log

Seems the negotiated configuration will fallow the initiator if the 
configuration between two gateways is not the same.

gateway 1 config
=======
ipsec.conf
=======
version    2.0

config setup
     interfaces="ipsec0=lo ipsec1=eth2 ipsec3=eth10"
     protostack=klips
     klipsdebug=none
     plutodebug=none
     uniqueids=yes
     plutostderrlog="/dev/null"

conn %default
     type=tunnel
     auth=esp
     authby=secret

include /etc/ipsec.d/conf/ipsec.*.conf
include /etc/ipsec.d/conf/site.*.conf


=============
site.gateway1.conf
=============

conn site_192.168.123.0_24-192.168.1.0_24
     left=10.29.3.225
     leftsubnet=192.168.123.0/24
     right=10.29.3.195
     rightsubnet=192.168.1.0/24
     ike=AES256-SHA1-MODP768
     esp=AES256-MD5-96
     dpddelay=10
     dpdtimeout=15
     keyingtries=%forever
     keylife=24h
     ikelifetime=8h
     rekey=no
     rekeymargin=9m
     pfs=yes
     auto=add



gateway 2 config
=======
ipsec.conf
=======

version 2.0

config setup
         interfaces="ipsec0=lo ipsec1=eth2"
         protostack=klips
         klipsdebug=none
         plutodebug=all
         uniqueids=yes
         plutostderrlog="/tmp/ipsec.log"

conn %default
         type=tunnel
         auth=esp
         authby=secret

include /etc/ipsec.d/conf/ipsec.*.conf
include /etc/ipsec.d/conf/site.*.conf

=============
site.gateway2.conf
=============
conn site_192.168.1.0_24-192.168.123.0_24
     left=10.29.3.195
     leftsubnet=192.168.1.0/24
     right=10.29.3.225
     rightsubnet=192.168.123.0/24
     ike=AES256-SHA1-MODP1536
     esp=AES256-MD5-96
     dpddelay=10
     dpdtimeout=15
     keyingtries=%forever
     keylife=24h
     ikelifetime=8h
     rekey=no
     rekeymargin=9m
     pfs=yes
     auto=add


Test scenario 2:

The same esp but different ike configuration between two gateways.
For example gateway1's ike=3des-md5, gateway2's ike=aes256-shal (ike 
group is the same)

Test procedure:
1. Initiator from gateway1 ike=3des-md5, test result please see attached 
file-name: ipsec-ike-diff-group-init-by-3des-md5.log
2. Initiator from gateway2 ike=aes256-sha1, test result please see 
attached file-name: ipsec-ike-same-group-init-by-aes256-sha1.log

Seems the negotiated configuration will fallow the initiator if the 
configuration between two gateways is not the same.



On 03/02/2010 03:39 PM, mix.kao wrote:
> Ok, i will do some more test and report later
>
> Thanks.
>
> On 03/02/2010 12:39 AM, Paul Wouters wrote:
>    
>> On Mon, 1 Mar 2010, mix.kao wrote:
>>
>>      
>>> the ike option is difference between two gateways, but seems the
>>> connection is still can build.
>>>        
>> Hmm, that's not supposed to happen. Though we might always allow a
>> bigger modp group.
>> Can you tell me the version of openswan on each end? And can you do a
>> test from the
>> modp768 end as initiator and a test with the modp1536 as initiator?
>> And if either of those
>> work, redo it with plutodebug=all and mail me the logs? (or start a
>> new bug on bugs.openswan.org
>> and attach the logs there?)
>>
>> Thanks,
>>
>>      
>>> gateway1: ipsec whack --status
>>>
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":
>>> 192.168.123.0/24===10.29.3.225<10.29.3.225>[+S=C]...10.2.3.156<10.2.3.156>[+S=C]===192.168.1.0/24;
>>> erouted; eroute owner: #6
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":     myip=unset;
>>> hisip=unset; myup=/ramfs/ipsec/bin/_updown;
>>> hisup=/ramfs/ipsec/bin/_updown;
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":   ike_life: 28800s;
>>> ipsec_life: 86400s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":   policy:
>>> PSK+ENCRYPT+TUNNEL+PFS+DONTREKEY+UP+IKEv2ALLOW+lKOD+rKOD; prio:
>>> 24,24; interface: eth2;
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":   dpd: action:clear;
>>> delay:10; timeout:15;
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":   newest ISAKMP SA: #0;
>>> newest IPsec SA: #6;
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":   IKE algorithms wanted:
>>> AES_CBC(7)_128-SHA1(2)-MODP1536(5); flags=-strict
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":   IKE algorithms found:
>>> AES_CBC(7)_128-SHA1(2)_160-5,
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":   ESP algorithms wanted:
>>> AES(12)_256-SHA1(2); flags=-strict
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":   ESP algorithms loaded:
>>> AES(12)_256-SHA1(2)_096
>>> 000 "site_192.168.123.0_24-192.168.1.0_24":   ESP algorithm newest:
>>> AES_256-HMAC_SHA1; pfsgroup=<Phase1>
>>> 000
>>> 000 #38: "site_192.168.123.0_24-192.168.1.0_24":500 STATE_MAIN_I1
>>> (sent MI1, expecting MR1); EVENT_RETRANSMIT in 23s; nodpd; idle;
>>> import:admin initiate
>>> 000 #38: pending Phase 2 for "site_192.168.123.0_24-192.168.1.0_24"
>>> replacing #0
>>> 000 #6: "site_192.168.123.0_24-192.168.1.0_24":500 STATE_QUICK_R2
>>> (IPsec SA established); EVENT_SA_EXPIRE in 83134s; newest IPSEC;
>>> eroute owner; isakmp#5; idle; import:not set
>>> 000 #6: "site_192.168.123.0_24-192.168.1.0_24" used 48s ago;
>>> esp.e6c8d0cd at 10.2.3.156 esp.b3b17a68 at 10.29.3.225 tun.1003 at 10.2.3.156
>>> tun.1004 at 10.29.3.225 ref=7 refhim=5
>>> 000 #36: "site_192.168.123.0_24-192.168.1.0_24":500 STATE_MAIN_I1
>>> (sent MI1, expecting MR1); EVENT_RETRANSMIT in 23s; nodpd; idle;
>>> import:not set
>>> 000 #41: "site_192.168.123.0_24-192.168.1.0_24":500 STATE_MAIN_I1
>>> (sent MI1, expecting MR1); EVENT_RETRANSMIT in 23s; nodpd; idle;
>>> import:not set
>>> 000
>>>
>>> gateway2: ipsec whack --status
>>>
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":
>>> 192.168.1.0/24===10.2.3.156...10.29.3.225===192.168.123.0/24;
>>> erouted; eroute owner: #7
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":     srcip=unset;
>>> dstip=unset; srcup=/ramfs/bin/ipsec_updown.exe;
>>> dstup=/ramfs/bin/ipsec_updown.exe;
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":   ike_life: 28800s;
>>> ipsec_life: 86400s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":   policy:
>>> PSK+ENCRYPT+TUNNEL+PFS+DONTREKEY+UP+failureDROP; prio: 24,24;
>>> interface: eth2;
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":   dpd: action:clear;
>>> delay:10; timeout:15;
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":   newest ISAKMP SA: #0;
>>> newest IPsec SA: #7;
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":   IKE algorithms wanted:
>>> 7_256-2-5, 7_256-2-2, 7_256-2-1, flags=strict
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":   IKE algorithms found:
>>> 7_256-2_160-5, 7_256-2_160-2, 7_256-2_160-1,
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":   ESP algorithms wanted:
>>> 12_256-2, ; pfsgroup=2; flags=strict
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":   ESP algorithms loaded:
>>> 12_256-2, ; pfsgroup=2; flags=strict
>>> 000 "site_192.168.1.0_24-192.168.123.0_24":   ESP algorithm newest:
>>> AES_256-HMAC_SHA1; pfsgroup=MODP1024
>>> 000
>>> 000 #7: "site_192.168.1.0_24-192.168.123.0_24":500 STATE_QUICK_I2
>>> (sent QI2, IPsec SA established); EVENT_SA_REPLACE_IF_USED in 82340s;
>>> newest IPSEC; eroute owner
>>> 000 #7: "site_192.168.1.0_24-192.168.123.0_24" used 27s ago;
>>> esp.b3b17a68 at 10.29.3.225 esp.e6c8d0cd at 10.2.3.156 tun.1004 at 10.29.3.225
>>> tun.1003 at 10.2.3.156
>>>
>>>
>>> On 03/01/2010 02:57 PM, Paul Wouters wrote:
>>>        
>>>> On Mon, 1 Mar 2010, mix.kao wrote:
>>>>
>>>>          
>>>>> i have a question about the openswan config.
>>>>> I am trying to build a tunnel between two gateways.
>>>>> gateway1's ike set to AES256-SHA1-MODP768
>>>>> gateway2's ike set to AES128-SHA1-MODP1536
>>>>> and finally the tunnel use ==>  IKE algorithm newest:
>>>>> AES_CBC_256-SHA1-MODP768
>>>>>            
>>>> I do not understand this.
>>>>
>>>> If the two gateway's set an ike= option, ONLY that proposal is
>>>> allowed. If two
>>>> gateways set two different ike= options, they will never setup a
>>>> tunnel. If
>>>> the ike= options (and other options/auth) match, the tunnel will
>>>> work. If
>>>> you want to allow two proposals, you can allow them both. In your
>>>> example:
>>>> gateway2 would use: ike=AES256-SHA1-MODP768,AES128-SHA1-MODP1536
>>>>
>>>> However note that modp768 does NOT WORK with opensan because it is
>>>> insecure. The minimum openswan will use is modp1024
>>>>
>>>> Paul
>>>>
>>>>
>>>>          
>>>        
>>
>>      
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
>
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20100302/b2afb863/attachment-0001.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipsec-ike-diff-group-init-by-group1.log
Url: http://lists.openswan.org/pipermail/users/attachments/20100302/b2afb863/attachment-0004.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipsec-ike-diff-group-init-by-group5.log
Url: http://lists.openswan.org/pipermail/users/attachments/20100302/b2afb863/attachment-0005.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipsec-ike-same-group-init-by-aes256-sha1.log
Url: http://lists.openswan.org/pipermail/users/attachments/20100302/b2afb863/attachment-0006.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipsec-ike-same-group-init-by-3des-md5.log
Url: http://lists.openswan.org/pipermail/users/attachments/20100302/b2afb863/attachment-0007.pl 


More information about the Users mailing list