[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