[Openswan Users] Question about ike configuration
Paul Wouters
paul at xelerance.com
Mon Mar 1 11:39:54 EST 2010
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