[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