[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