[Openswan Users] Question about ike configuration

mix.kao mix.kao at cipherium.com.tw
Tue Mar 2 02:39:01 EST 2010


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
>>>
>>>
>>
>
>



More information about the Users mailing list