[strongSwan] Does Strongswan support PEM format
Hi, all I met a problem when did interoperability test between Strongswan and my IPsec implementation. I try to send a certificate with PEM format to Strongswan point, but it reports that doesn't support. I found that the Strongswan uses the DER "X.509 Certificate - Signature" format in Certificate Payload even if in the Ipsec.conf file the "leftcert" point to a PEM file. The other issue is that after I changed the Certificate from PEM to DER and try again, the strongswan reported "Authentication of 'CN=**, ST=**, E=***, OU=SSG, O=SGG' with RSA signature failed." My questions are: 1. Does Strongswan support PEM format? 2. The authentication failed means the Certificate has problem or the authentication Payload has problem? Your answer are appreciated. Thanks Michalle ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Yubikey OTP USB Tokens Supported As Authentication Method?
Hi Martin (and all the other list members), first of all, thanks for your quick reply. Concerning the Yubikey: More information is available at: http://www.yubico.com/products/yubikey/ http://www.yubico.com/technical-data http://www.yubico.com/technical-description http://wiki.yubico.com/wiki/index.php/Main_Page http://www.yubico.com/web-api-clients http://code.google.com/p/yubikey-val-server-php/wiki/ValidationProtocolV20 http://forum.yubico.com/viewtopic.php?f=16&t=352 As you can see, the company has got a very good reputation for open sourcing their software. They only charge for the hardware USB tokens. That's one of the main reason's that got me interested in the product. Kind regards, Holger THE standard software for Aviation Authorities ** IMPORTANT NOTICE / WICHTIGER HINWEIS This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us immediately by email or by telephone and then delete this email and any copies of it. Diese E-Mail koennte vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. ** ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Yubikey OTP USB Tokens Supported As Authentication Method?
Hi Holger, > does anybody know of any StrongSWAN setups in which Yubikeys are used No, I don't. > either directly We currently have no built-in support for OTPs. I don't know how these Yubikeys work in detail, but shouldn't be too hard to implement it for IKEv2 wrappend in EAP-OTP/GTC. > or indirectly (via a RADIUS server) Our IKEv2 RADIUS backend can use any EAP method transparently for user authentication. I don't know if there is a RADIUS server supporting Yubikey-over-EAP, though. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Yubikey OTP USB Tokens Supported As Authentication Method?
Hi, does anybody know of any StrongSWAN setups in which Yubikeys are used either directly or indirectly (via a RADIUS server) in order to authenticate users using two-factor authentication (both OTP emitted by the Yubikey and a "regular" account password)? I would like to know this since I'm currently in the process of generally verifying Yubikeys (not just for a VPN setup, but also for local authentication). Thanks in advance for any info & kind regards, Holger THE standard software for Aviation Authorities ** IMPORTANT NOTICE / WICHTIGER HINWEIS This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us immediately by email or by telephone and then delete this email and any copies of it. Diese E-Mail koennte vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. ** ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] ikev2 - configuration payload in spite of explicit virtual IP address
> The initiator stills send the configuration payload > > charon: 05[CFG] received stroke: add connection 'net-net' > > charon: 05[CFG] conn net-net > > charon: 05[CFG] left=192.168.20.51 > > charon: 05[CFG] leftsubnet=(null) > > charon: 05[CFG] leftsourceip=192.168.10.20 > > charon: 05[CFG] leftauth=psk According to your log, starter still loads the config with the leftsourceip specified. Double check that the configuration is updated and starter reload (ipsec restart). > What you you mean exactly by "Also, the IP address is not installed by > the daemon." The configuration payload mechanism used by leftsourceip requests an IP address from the gateway, optionally requesting a specific one. If the gateway accepts such a request, it responds with an IP address the client can use. The daemon automatically installs the address to the system. If you do not want to use the configuration payload exchange mechanism, you'll have to manually install this IP address on your system (i.e. ip address add 192.168.10.20 dev ethx). The daemon does not know it and is unable to do this for you. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] installpolicy=no not working, even when reqid is manually set
reauth=no is already set during the test i did On 11/02/2010 11:27 AM, ext Martin Willi wrote: >> Charon starts with reqid 1 and then just enumerates them. If >> reqid 2 is assigned to your IPsec SA means that reqid 1 was >> assigned to an earlier connection. > Requids are reused after rekeying. But in your case, the tunnel is > reauthenticated (i.e. re-established from scratch). This results in a > completely new CHILD_SA that has a unique requid. Setting reauth=no > probably works better for your special case. > > Regards > Martin > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Query regarding route based security
Hi Vivek, see my inline comments: On 02.11.2010 08:05, vivek bairathi wrote: > Hi Andreas, > > Thanks for your quick reply. > > I have some more queries regarding kernel_netlink interface: > > If I use auto=route in ipsec.conf file for a connection: > Q1. Does the stack after reading the ipsec.conf file for this connection > installs SPD and route entries into the kernel? If yes then is the SPI > and reqid written in SPD are the one that is sent to IKEv2 stack by > kernel in XFRM ACQUIRE message? > An installed IPsec policy doesn't have an SPI. It is identified by the reqid assigned by the IKEv2 daemon and this reqid is in fact returned by the XFM ACQUIRE message. > If I do not use auto=route in ipsec.conf file for a connection: > Q2. I send an XFRM ACQUIRE message to IKEv2 stack using my application > will the IKEv2 stack be able to trigger an IKE/IPSEC SA. I think in this > case there will be no kernel traps installed by IKEv2 stack. So will it > be able to trigger an SA for that connection? > no, connection setup will be triggered only if the reqid is known by the IKEv2 daemon, i.e. you must use auto=route to create the reqid. Using a fixed reqid= in the connection definition helps because if you set installpolicy=no, and let the IPsec policy be created by your application then you have much more control that the reqids match. Have a look at my Mobile IPv6 example where the mipd daemon creates the IPsec policies and triggers the IKEv2 daemon via XFRM ACQUIRE and XFRM MIGRATE messages: http://wiki.strongswan.org/projects/strongswan/wiki/ MobileIPv6 > Thanks & Regards, > Vivek > Best regards Andreas > On Mon, Nov 1, 2010 at 6:45 PM, Andreas Steffen > mailto:andreas.stef...@strongswan.org>> > wrote: > > Hello Vivek, > > this event is signalled by an XFRM ACQUIRE message via the netlink > kernel interface: > > > http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libhydra/plugins/kernel_netlink/kernel_netlink_ipsec.c;h=8cc9a6283014a9b237f8a16b2146b73742ac;hb=HEAD#l514 > > The netlink socket is registered to receive this kind of events: > > > http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libhydra/plugins/kernel_netlink/kernel_netlink_ipsec.c;h=8cc9a6283014a9b237f8a16b2146b73742ac;hb=HEAD#l2199 > > Best regards > > Andreas > > On 11/01/2010 01:34 PM, vivek bairathi wrote: > > Hi All, > > > > I want to know that if I set auto=route in ipsec.conf for a > connection. > > > > The IKEv2 stack will install kernel traps for that connection and will > > initiate an SA only when it gets a packet between the leftsubnet > and the > > rightsubnet. > > > > For this the IKEv2 stack needs trigger from kernel so which interface > > will be used to tell IKEv2 Stack that a packet has hit its kernel > traps > > and now you have to init an IKE_SA? > > > > Thanks & Regards > > Vivek == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Linux VPN Solution!www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[ITA-HSR]== ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] installpolicy=no not working, even when reqid is manually set
By the way, i just realized it is 4.3.6
there is not any previous connection, this is the first connection made
after clean start, and i couldn't find indications of a temporary SA
created and deleted.
# ip xfrm state
src 10.0.0.2 dst 10.0.0.1
proto esp spi 0xc4ac94cf reqid 2 mode tunnel
replay-window 32 flag 20
auth hmac(md5) 0x11ff55908a41ac92f141544623ca8420
enc cbc(des3_ede) 0x4097d8e922581bb364afd6ff020e223ef3335999dbf2b29c
src 10.0.0.1 dst 10.0.0.2
proto esp spi 0xce030a4e reqid 2 mode tunnel
replay-window 32 flag 20
auth hmac(md5) 0x405d116a3795afb110450a3ba386e011
enc cbc(des3_ede) 0xa5ec086797c680f5960f44ef9e6a227a4a688f66b36f6a76
# ip xfrm policy
src 5.5.0.0/16 dst 4.4.0.0/16
dir in priority 31800
tmpl src 10.0.0.1 dst 10.0.0.2
proto esp reqid 1 mode tunnel
src 4.4.0.0/16 dst 5.5.0.0/16
dir out priority 31800
tmpl src 10.0.0.2 dst 10.0.0.1
proto esp reqid 1 mode tunnel
log doesn't show double sessions!
configuration 'rule16~vpn1' routed
10[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
10[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
10[IKE] 10.0.0.1 is initiating an IKE_SA
10[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP)
N(NATD_D_IP) N(MULT_AUTH) ]
10[NET] sending packet: from 10.0.0.2[500] to 10.0.0.1[500]
12[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
12[ENC] parsed IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MULT_AUTH) ]
12[CFG] looking for peer configs matching
10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
12[CFG] selected peer config 'rule16~vpn1'
12[IKE] authentication of '10.0.0.1' with pre-shared key successful
12[IKE] authentication of '10.0.0.2' (myself) with pre-shared key
12[IKE] IKE_SA rule16~vpn1[1] established between
10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
12[IKE] scheduling rekeying in 1900s
12[IKE] maximum IKE_SA lifetime 2000s
12[IKE] CHILD_SA rule16~vpn1{2} established with SPIs ce030a4e_i
c4ac94cf_o and TS 4.4.0.0/16 === 5.5.0.0/16
12[ENC] generating IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
12[NET] sending packet: from 10.0.0.2[500] to 10.0.0.1[500]
On 11/02/2010 11:22 AM, ext Andreas Steffen wrote:
> Charon starts with reqid 1 and then just enumerates them. If
> reqid 2 is assigned to your IPsec SA means that reqid 1 was
> assigned to an earlier connection.
>
> Regards
>
> Andreas
>
> On 02.11.2010 10:16, Mohammad Ayyash wrote:
>> hi,
>>
>> can you explain how Charon assigns reqids (4.3.x)?
>>
>> i insert two xfrm rules:
>> ip xfrm policy add dir in src 5.5.0.0/16 dst 4.4.0.0/16 proto any
>> priority 31800 tmpl src 10.0.0.1 dst 10.0.0.2 proto esp mode tunnel
>> reqid 1 level required
>> ip xfrm policy add dir out src 4.4.0.0/16 dst 5.5.0.0/16 proto any
>> priority 31800 tmpl src 10.0.0.2 dst 10.0.0.1 proto esp mode tunnel
>> reqid 1 level required
>>
>>
>> configurations is like shown below for host2, here is the log
>>
>> 06[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
>> 06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
>> 06[IKE] 10.0.0.1 is initiating an IKE_SA
>> 06[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP)
>> N(NATD_D_IP) N(MULT_AUTH) ]
>> 06[NET] sending packet: from 10.0.0.2[500] to 10.0.0.1[500]
>> 07[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
>> 07[ENC] parsed IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MULT_AUTH) ]
>> 07[CFG] looking for peer configs matching
>> 10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
>> 07[CFG] selected peer config 'rule16~vpn1'
>> 07[IKE] authentication of '10.0.0.1' with pre-shared key successful
>> 07[IKE] authentication of '10.0.0.2' (myself) with pre-shared key
>> 07[IKE] IKE_SA rule16~vpn1[1] established between
>> 10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
>> 07[IKE] scheduling rekeying in 1854s
>> 07[IKE] maximum IKE_SA lifetime 1954s
>> 07[KNL] getting SPI for reqid {2}
>>
>>
>> my question is about the last line, where did this {2} come from? this
>> is causing the local kernel drop packets since there will be SAD entries
>> with reqids 2 and SPD entries with reqid 1.
>>
>>
>> -Mohammad
>>
>>
>>
>>
>>
>>
>> On 11/01/2010 08:45 PM, ext Andreas Steffen wrote:
>>> Hi Mohammad,
>>>
>>> I recommend to upgrade to strongSwan 4.4.1 or 4.5.0 where you
>>> can fix the reqid with
>>>
>>>conn xyz
>>> reqid=
>>>
>>> Regards
>>>
>>> Andreas
>>>
>>> On 11/01/2010 07:17 PM, Mohammad Ayyash wrote:
Hi,
This topic has been complained about so many times and i wonder why
there isn't proper documentation about it. It is clear from this
mailing list + strongswan documentation that if you wish to control SPD
policy installment yourself, you should set installpolicy=no, but if you
do, you must also manually set reqid when creating SPD entries, though
you have to guess the reqid and hope for the best (i am still using
4.3.x, can't upgrade yet)
the setup
Re: [strongSwan] installpolicy=no not working, even when reqid is manually set
> Charon starts with reqid 1 and then just enumerates them. If > reqid 2 is assigned to your IPsec SA means that reqid 1 was > assigned to an earlier connection. Requids are reused after rekeying. But in your case, the tunnel is reauthenticated (i.e. re-established from scratch). This results in a completely new CHILD_SA that has a unique requid. Setting reauth=no probably works better for your special case. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] ikev2 - configuration payload in spite of explicit virtual IP address
Hi Laurence, > We don't expect that the client request an address from the responder > and configured the strongswan client for IKEv2 with an explicit > virtual IP address (leftsourceip=192.168.10.20). An IP specified with leftsourceip is always requested via a configuration payload in IKEv2, even if it is fixed. If you don't want this, just omit the leftsourceip parameter. Of course you'll have to make sure your source IP is in the negotiated tunnel, e.g. by settings leftsubnet=192.168.10.20/32. Also, the IP address is not installed by the daemon. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] installpolicy=no not working, even when reqid is manually set
Charon starts with reqid 1 and then just enumerates them. If
reqid 2 is assigned to your IPsec SA means that reqid 1 was
assigned to an earlier connection.
Regards
Andreas
On 02.11.2010 10:16, Mohammad Ayyash wrote:
> hi,
>
> can you explain how Charon assigns reqids (4.3.x)?
>
> i insert two xfrm rules:
> ip xfrm policy add dir in src 5.5.0.0/16 dst 4.4.0.0/16 proto any
> priority 31800 tmpl src 10.0.0.1 dst 10.0.0.2 proto esp mode tunnel
> reqid 1 level required
> ip xfrm policy add dir out src 4.4.0.0/16 dst 5.5.0.0/16 proto any
> priority 31800 tmpl src 10.0.0.2 dst 10.0.0.1 proto esp mode tunnel
> reqid 1 level required
>
>
> configurations is like shown below for host2, here is the log
>
> 06[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
> 06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> 06[IKE] 10.0.0.1 is initiating an IKE_SA
> 06[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP)
> N(NATD_D_IP) N(MULT_AUTH) ]
> 06[NET] sending packet: from 10.0.0.2[500] to 10.0.0.1[500]
> 07[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
> 07[ENC] parsed IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MULT_AUTH) ]
> 07[CFG] looking for peer configs matching
> 10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
> 07[CFG] selected peer config 'rule16~vpn1'
> 07[IKE] authentication of '10.0.0.1' with pre-shared key successful
> 07[IKE] authentication of '10.0.0.2' (myself) with pre-shared key
> 07[IKE] IKE_SA rule16~vpn1[1] established between
> 10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
> 07[IKE] scheduling rekeying in 1854s
> 07[IKE] maximum IKE_SA lifetime 1954s
> 07[KNL] getting SPI for reqid {2}
>
>
> my question is about the last line, where did this {2} come from? this
> is causing the local kernel drop packets since there will be SAD entries
> with reqids 2 and SPD entries with reqid 1.
>
>
> -Mohammad
>
>
>
>
>
>
> On 11/01/2010 08:45 PM, ext Andreas Steffen wrote:
>> Hi Mohammad,
>>
>> I recommend to upgrade to strongSwan 4.4.1 or 4.5.0 where you
>> can fix the reqid with
>>
>> conn xyz
>>reqid=
>>
>> Regards
>>
>> Andreas
>>
>> On 11/01/2010 07:17 PM, Mohammad Ayyash wrote:
>>> Hi,
>>>
>>> This topic has been complained about so many times and i wonder why
>>> there isn't proper documentation about it. It is clear from this
>>> mailing list + strongswan documentation that if you wish to control SPD
>>> policy installment yourself, you should set installpolicy=no, but if you
>>> do, you must also manually set reqid when creating SPD entries, though
>>> you have to guess the reqid and hope for the best (i am still using
>>> 4.3.x, can't upgrade yet)
>>>
>>> the setup is very simple:
>>> Host1
>>> Host2
>>> 10.0.0.1<== IPSec tunnel ==> 10.0.0.2
>>> 5.5.0.0/16
>>> 4.4.0.0/16
>>>
>>> traffic going between 5.5.0.0/16 and 4.4.0.0/16 subnets will go in IPsec
>>> tunnel.
>>>
>>> configurations:
>>> Host1 (initiates ping):
>>> /etc/ipsec.conf:
>>> config setup
>>> charonstart=yes
>>> plutostart=no
>>> charondebug="knl 0,enc 0,net 0"
>>> conn %default
>>> keyexchange=ikev2
>>> ca strongswan
>>> cacert=/etc/ipsec/certs/ipsec.d//cacerts/cacert.pem
>>> conn rule16~vpn1
>>> rekeymargin=100
>>> rekeyfuzz=100%
>>> left=10.0.0.1
>>> right=10.0.0.2
>>> leftsubnet=5.5.0.0/16
>>> rightsubnet=4.4.0.0/16
>>> leftprotoport=%any
>>> rightprotoport=%any
>>> authby=secret
>>> leftid=10.0.0.1
>>> rightid=10.0.0.2
>>> ike=aes128-md5-modp768
>>> esp=3des-md5
>>> type=tunnel
>>> pfs=yes
>>> pfsgroup=modp1024
>>> ikelifetime=2000s
>>> keylife=1000s
>>> mobike=no
>>> auto=route
>>> installpolicy=no
>>>
>>> xfrm config:
>>> ip xfrm policy add dir out src 5.5.0.0/16 dst 4.4.0.0/16 proto any
>>> action allow priority 31798 tmpl src 10.0.0.1 dst 10.0.0.2 proto esp
>>> mode tunnel reqid 1 level required
>>> ip xfrm policy add dir in src 4.4.0.0/16 dst 5.5.0.0/16 proto any action
>>> allow priority 31798 tmpl src 10.0.0.2 dst 10.0.0.1 proto esp mode
>>> tunnel reqid 1 level required
>>>
>>> # ip xfrm policy
>>> 4.4.0.0/16[0] 5.5.0.0/16[0]
>>> upspec 0 dev (none) uid 0
>>> in allow index 0x8010a878 priority 31800 share any flags
>>> 0x
>>> tmpl-1:
>>> 10.0.0.2 10.0.0.1
>>> esp spi 0(0x) reqid 1 tunnel
>>> level required share any algo-mask:E=32, A=32, C=32
>>> vrfid: 0
>>> linkvrfid: 0
>>> fpid 0x004c
>>>
>>> 5.5.0.0/16[0] 4.4.0.0/16[0]
>>> upspec 0 dev (none) uid 0
>>> out allow index 0x8010a871 priority 31800 share any flags
>>> 0x
>>> tmpl-1:
>>> 10.0.0.1 10.0.0.2
>>> esp spi 0(0x) reqid 1 tunnel
>>> level required share any algo-mask:E=32, A=32, C=32
>>> vrfid: 0
>>> linkvrfid: 0
>>> fpid 0x004b
>>>
>>>
>>> # ip xfrm s
Re: [strongSwan] installpolicy=no not working, even when reqid is manually set
hi,
can you explain how Charon assigns reqids (4.3.x)?
i insert two xfrm rules:
ip xfrm policy add dir in src 5.5.0.0/16 dst 4.4.0.0/16 proto any
priority 31800 tmpl src 10.0.0.1 dst 10.0.0.2 proto esp mode tunnel
reqid 1 level required
ip xfrm policy add dir out src 4.4.0.0/16 dst 5.5.0.0/16 proto any
priority 31800 tmpl src 10.0.0.2 dst 10.0.0.1 proto esp mode tunnel
reqid 1 level required
configurations is like shown below for host2, here is the log
06[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
06[IKE] 10.0.0.1 is initiating an IKE_SA
06[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP)
N(NATD_D_IP) N(MULT_AUTH) ]
06[NET] sending packet: from 10.0.0.2[500] to 10.0.0.1[500]
07[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
07[ENC] parsed IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MULT_AUTH) ]
07[CFG] looking for peer configs matching
10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
07[CFG] selected peer config 'rule16~vpn1'
07[IKE] authentication of '10.0.0.1' with pre-shared key successful
07[IKE] authentication of '10.0.0.2' (myself) with pre-shared key
07[IKE] IKE_SA rule16~vpn1[1] established between
10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
07[IKE] scheduling rekeying in 1854s
07[IKE] maximum IKE_SA lifetime 1954s
07[KNL] getting SPI for reqid {2}
my question is about the last line, where did this {2} come from? this
is causing the local kernel drop packets since there will be SAD entries
with reqids 2 and SPD entries with reqid 1.
-Mohammad
On 11/01/2010 08:45 PM, ext Andreas Steffen wrote:
> Hi Mohammad,
>
> I recommend to upgrade to strongSwan 4.4.1 or 4.5.0 where you
> can fix the reqid with
>
> conn xyz
>reqid=
>
> Regards
>
> Andreas
>
> On 11/01/2010 07:17 PM, Mohammad Ayyash wrote:
>> Hi,
>>
>> This topic has been complained about so many times and i wonder why
>> there isn't proper documentation about it. It is clear from this
>> mailing list + strongswan documentation that if you wish to control SPD
>> policy installment yourself, you should set installpolicy=no, but if you
>> do, you must also manually set reqid when creating SPD entries, though
>> you have to guess the reqid and hope for the best (i am still using
>> 4.3.x, can't upgrade yet)
>>
>> the setup is very simple:
>> Host1
>> Host2
>> 10.0.0.1<== IPSec tunnel ==> 10.0.0.2
>> 5.5.0.0/16
>> 4.4.0.0/16
>>
>> traffic going between 5.5.0.0/16 and 4.4.0.0/16 subnets will go in IPsec
>> tunnel.
>>
>> configurations:
>> Host1 (initiates ping):
>> /etc/ipsec.conf:
>> config setup
>> charonstart=yes
>> plutostart=no
>> charondebug="knl 0,enc 0,net 0"
>> conn %default
>> keyexchange=ikev2
>> ca strongswan
>> cacert=/etc/ipsec/certs/ipsec.d//cacerts/cacert.pem
>> conn rule16~vpn1
>> rekeymargin=100
>> rekeyfuzz=100%
>> left=10.0.0.1
>> right=10.0.0.2
>> leftsubnet=5.5.0.0/16
>> rightsubnet=4.4.0.0/16
>> leftprotoport=%any
>> rightprotoport=%any
>> authby=secret
>> leftid=10.0.0.1
>> rightid=10.0.0.2
>> ike=aes128-md5-modp768
>> esp=3des-md5
>> type=tunnel
>> pfs=yes
>> pfsgroup=modp1024
>> ikelifetime=2000s
>> keylife=1000s
>> mobike=no
>> auto=route
>> installpolicy=no
>>
>> xfrm config:
>> ip xfrm policy add dir out src 5.5.0.0/16 dst 4.4.0.0/16 proto any
>> action allow priority 31798 tmpl src 10.0.0.1 dst 10.0.0.2 proto esp
>> mode tunnel reqid 1 level required
>> ip xfrm policy add dir in src 4.4.0.0/16 dst 5.5.0.0/16 proto any action
>> allow priority 31798 tmpl src 10.0.0.2 dst 10.0.0.1 proto esp mode
>> tunnel reqid 1 level required
>>
>> # ip xfrm policy
>> 4.4.0.0/16[0] 5.5.0.0/16[0]
>> upspec 0 dev (none) uid 0
>> in allow index 0x8010a878 priority 31800 share any flags
>> 0x
>> tmpl-1:
>> 10.0.0.2 10.0.0.1
>> esp spi 0(0x) reqid 1 tunnel
>> level required share any algo-mask:E=32, A=32, C=32
>> vrfid: 0
>> linkvrfid: 0
>> fpid 0x004c
>>
>> 5.5.0.0/16[0] 4.4.0.0/16[0]
>> upspec 0 dev (none) uid 0
>> out allow index 0x8010a871 priority 31800 share any flags
>> 0x
>> tmpl-1:
>> 10.0.0.1 10.0.0.2
>> esp spi 0(0x) reqid 1 tunnel
>> level required share any algo-mask:E=32, A=32, C=32
>> vrfid: 0
>> linkvrfid: 0
>> fpid 0x004b
>>
>>
>> # ip xfrm state
>> 10.0.0.1 10.0.0.2
>> esp spi -926705739(0xc8c397b5) reqid 1 tunnel
>> A:md5 3f3c4f2f 57a7f21f 80498a37 ea4af86
>> E:des3_ede fdd4ad84 bba12863 fa248f1d 4c08e50 d5f6ec7 b27945e3
>> vrfid: 0
>> xvrfid: 0
>> fpid 0x004a
>> fp_output_blade 1
>> 10.0.0.2 10.0.0.1
>> esp spi -806604046(0xcfec32f2) reqid 1 tunnel
>> A:md5 dbbdbbd5 2a4b3e2c 99585
Re: [strongSwan] Query regarding route based security
On Tue, Nov 2, 2010 at 12:35 PM, vivek bairathi wrote: > Hi Andreas, > > Thanks for your quick reply. > > I have some more queries regarding kernel_netlink interface: > > If I use auto=route in ipsec.conf file for a connection: > Q1. Does the stack after reading the ipsec.conf file for this connection > installs SPD and route entries into the kernel? If yes then is the SPI and > reqid written in SPD are the one that is sent to IKEv2 stack by kernel in > XFRM ACQUIRE message? > > If I do not use auto=route in ipsec.conf file for a connection: > Q2. I send an XFRM ACQUIRE message to IKEv2 stack using my application will > the IKEv2 stack be able to trigger an IKE/IPSEC SA. I think in this case > there will be no kernel traps installed by IKEv2 stack. So will it be able > to trigger an SA for that connection? > > Thanks & Regards, > Vivek > > On Mon, Nov 1, 2010 at 6:45 PM, Andreas Steffen < > andreas.stef...@strongswan.org> wrote: > >> Hello Vivek, >> >> this event is signalled by an XFRM ACQUIRE message via the netlink >> kernel interface: >> >> >> http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libhydra/plugins/kernel_netlink/kernel_netlink_ipsec.c;h=8cc9a6283014a9b237f8a16b2146b73742ac;hb=HEAD#l514 >> >> The netlink socket is registered to receive this kind of events: >> >> >> http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libhydra/plugins/kernel_netlink/kernel_netlink_ipsec.c;h=8cc9a6283014a9b237f8a16b2146b73742ac;hb=HEAD#l2199 >> >> Best regards >> >> Andreas >> >> On 11/01/2010 01:34 PM, vivek bairathi wrote: >> > Hi All, >> > >> > I want to know that if I set auto=route in ipsec.conf for a connection. >> > >> > The IKEv2 stack will install kernel traps for that connection and will >> > initiate an SA only when it gets a packet between the leftsubnet and the >> > rightsubnet. >> > >> > For this the IKEv2 stack needs trigger from kernel so which interface >> > will be used to tell IKEv2 Stack that a packet has hit its kernel traps >> > and now you have to init an IKE_SA? >> > >> > Thanks & Regards >> > Vivek >> >> == >> Andreas Steffen andreas.stef...@strongswan.org >> strongSwan - the Linux VPN Solution!www.strongswan.org >> Institute for Internet Technologies and Applications >> University of Applied Sciences Rapperswil >> CH-8640 Rapperswil (Switzerland) >> ===[ITA-HSR]== >> > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
