Re: [strongSwan] How to specify AES128-XCBC as the PRF in strongswan-5.0.1?
On Thursday 18 October 2012 03:12 PM, Martin Willi wrote: >> I have also expressed the concern to do similar provisioning for >> esp= param as well. Can the check be extended for PROTO_ESP too ? > There is no PRF involved in ESP SAs, nor is a dedicated PRF used in > CHILD_SA establishment. Hence I see no reason what we could configure > there. Correct. I could infer it now as in RFC 4306 Sec 3.3 (and 2.10) that, prf algorithm is chosen only in IKE exchange (not in CHILD SA). Thanks, Gowri Shankar > Regards > Martin > > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] How to specify AES128-XCBC as the PRF in strongswan-5.0.1?
Hi Martin, On Thursday 18 October 2012 01:12 PM, Martin Willi wrote: > Hi, > >> Is there any support if strongswan can provide to explicitly mention >> IKE integrity and PRF, in future ? > Yes. I've implemented this last week (the last three patches from [1]), > it will be available in the next release. Great. Thank you. Btw, I have also expressed the concern to do similar provisioning for esp= param as well. Can the check be extended for PROTO_ESP too ? Regards, Gowri Shankar > Regards > Martin > > [1]http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/prf-keywords > > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] How to specify AES128-XCBC as the PRF in strongswan-5.0.1?
Hi Andreas, Is there any support if strongswan can provide to explicitly mention IKE integrity and PRF , in future ? Below is what from earlier discussion, but not concluded. http://thread.gmane.org/gmane.network.vpn.strongswan.user/2240 Will there be similar support to mention in ESP cipher suites as well ? Thanks, Gowri Shankar On Tuesday 16 October 2012 11:21 AM, Andreas Steffen wrote: > Hello Robert, > > in ipsec.conf currently the IKEv2 PRF cannot be configured > independently of the IKEv2 integrity method. > > ike=aes128-aesxcbc-modp2048! > > configures both. > > Regards > > Andreas > > On 10/16/2012 07:43 AM, Robert Lee wrote: >> Hi, >> >> How can I specify AES128-XCBC as the Pseudo Random Function in ipsec.conf? >> >> In the testing folder under >> ~/strongswan-5.0.1/testing/tests/ikev2/alg-aes-xcbc/evaltest.dat, I >> see the following two lines from moon and carol: >> moon:: ipsec statusall 2> /dev/null::rw.*IKE >> proposal.*AES_CBC_128/AES_XCBC_96/PRF_AES128_XCBC/MODP_2048::YES >> carol::ipsec statusall 2> /dev/null::home.*IKE >> proposal.*AES_CBC_128/AES_XCBC_96/PRF_AES128_XCBC/MODP_2048::YES >> >> Looks like they are using PRF_AES128_XCBC already. But in the >> corresponding moon's or carol's ipsec.conf, I only see >> ike=aes128-aesxcbc-modp2048! >> esp=aes128-aesxcbc-modp2048! >> >> So how can I make strongswan use AES128-XCBC as the designated PRF? Thank >> you! >> >> Robert > > == > 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 > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] charon unable to handle rekeying with multiple transforms
Hi,
I am looking for clarification in strongswan implementation (v4.6.4 or
above) about its proposal on encryption (ENCR) algorithms while rekeying
IKE_SA using CHILD_SA. In my test, I have configured localnode running
strongswan, with ESP as:
ESP:3DES_CBC/AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
Remote node responded for IKE_AUTH to the local node on algorithms
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
While rekeying IKE_SA using CHILD_SA, it is found that, strongswan
places always 3DES transform in its CHILD_SA request. Is this not
wrong ? While rekeying IKE_SA (using CHILD_SA), should this not be again
sending its configuration to remote node ? (i.e 3DES and AES_CBC be sent).
I have not yet gone through any other RFCsthan 4306 to understand
anything else here. But, if someone clarifies me, that will be much helpful.
Below are ipsec.conf entries relevant to this problem.
esp=aes128-3des-sha1!
ike=3des-integrity_sha1-prf_sha1-modp1024!
ikelifetime="60s"
keylife="300s"
rekeymargin=5s
reauth="no"
Below are portion of charon.log for better explanation.
Sep 30 07:08:32 15[ENC] generating IKE_AUTH request 1 [ IDi
N(INIT_CONTACT) IDr AUTH N(USE_TRANSP) SA TSi TSr N(EAP_ONLY) ]
...
..
Sep 30 07:08:32 15[ENC] generating payload of type TRANSFORM_SUBSTRUCTURE
...
..
Sep 30 07:08:32 15[ENC] generating rule 5 U_INT_16
Sep 30 07:08:32 15[ENC]=> => 2 bytes @ 0x7fe92e9516ae
Sep 30 07:08:32 15[ENC]0: 00 03 (3DES)
Sep 30 07:08:32 15[ENC] generating rule 6 TRANSFORM_ATTRIBUTES
Sep 30 07:08:32 15[ENC] generating TRANSFORM_SUBSTRUCTURE payload finished
Sep 30 07:08:32 15[ENC] generated data for this payload => 8 bytes @
0x7fe91000434c
Sep 30 07:08:32 15[ENC]0: 03 00 00 08 01 00 00
03
Sep 30 07:08:32 15[ENC] generating payload of type TRANSFORM_SUBSTRUCTURE
...
..
Sep 30 07:08:32 15[ENC] generating rule 5 U_INT_16
Sep 30 07:08:32 15[ENC]=> => 2 bytes @ 0x7fe92e9516ae
Sep 30 07:08:32 15[ENC]0: 00 0C (AES_CBC)
Sep 30 07:08:32 15[ENC] generating rule 6 TRANSFORM_ATTRIBUTES
Sep 30 07:08:32 15[ENC] generating payload of type TRANSFORM_ATTRIBUTE
...
..
Now, IKE_AUTH request is initiated and charon received response from
remote node.
Sep 30 07:08:32 16[ENC] parsed IKE_AUTH response 1 [ IDr AUTH
N(USE_TRANSP) SA TSi TSr ]
...
..
Sep 30 07:08:32 16[IKE] maximum IKE_SA lifetime 60s
Sep 30 07:08:32 16[CFG] selecting proposal:
Sep 30 07:08:32 16[CFG] proposal matches
Sep 30 07:08:32 16[CFG] received proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
Sep 30 07:08:32 16[CFG] configured proposals:
ESP:3DES_CBC/AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
Sep 30 07:08:32 16[CFG] selected proposal:
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
...
..
Sep 30 07:08:32 16[CHD] adding inbound ESP SA
Sep 30 07:08:32 16[CHD] SPI 0xc126599d, src 2001:db8:f:1::1 dst
2001:db8:1:1::1
Sep 30 07:08:32 16[KNL] adding SAD entry with SPI c126599d and reqid {1}
Sep 30 07:08:32 16[KNL] using encryption algorithm AES_CBC with key
size 128
Sep 30 07:08:32 16[KNL] using integrity algorithm HMAC_SHA1_96 with
key size 160
Sep 30 07:08:32 16[KNL] sending XFRM_MSG_UPDSA: => 420 bytes @
0x7fe92df505d0
...
..
Sep 30 07:08:32 16[CHD] adding outbound ESP SA
Sep 30 07:08:32 16[CHD] SPI 0xa856a478, src 2001:db8:1:1::1 dst
2001:db8:f:1::1
Sep 30 07:08:32 16[KNL] adding SAD entry with SPI a856a478 and reqid {1}
Sep 30 07:08:32 16[KNL] using encryption algorithm AES_CBC with key
size 128
Sep 30 07:08:32 16[KNL] using integrity algorithm HMAC_SHA1_96 with
key size 160
Sep 30 07:08:32 16[KNL] sending XFRM_MSG_NEWSA: => 420 bytes @
0x7fe92df505d0
So, local node SPI is updated with ENCR algorithm AES_CBC as a chosen one.
Now, rekeying IKE_SA (having set reauth=no) using CHILD_SA takes place
after ike_lifetime-rekey_margin.
Sep 30 07:09:27 11[IKE] queueing IKE_REKEY task
...
..
Sep 30 07:09:27 11[ENC] generating CREATE_CHILD_SA request 2 [ SA No KE ]
...
..
Sep 30 07:09:27 11[ENC] generating rule 8 TRANSFORMS
Sep 30 07:09:27 11[ENC] generating payload of type TRANSFORM_SUBSTRUCTURE
Sep 30 07:09:27 11[ENC] generating rule 0 U_INT_8
Sep 30 07:09:27 11[ENC]=> 3
Sep 30 07:09:27 11[ENC] generating rule 1 RESERVED_BYTE
Sep 30 07:09:27 11[ENC]=> 0
Sep 30 07:09:27 11[ENC] generating rule 2 PAYLOAD_LENGTH
Sep 30 07:09:27 11[ENC]=> => 2 bytes @ 0x7fe9311557be
Sep 30 07:09:27 11[ENC]0: 00
08..
Sep 30 07:09:27 11[ENC] generating rule 3 U_INT_8
Sep 30 07:09:27 11[ENC]=> 1 (ENCR)
Sep 30 07:09:27 11[ENC] generating rule 4 RESERVED_BYTE
Sep 30 07:09:27 11[ENC]=> 0
Sep 30 07:09:27 11[ENC] generating rule 5 U_INT_16
Sep 30 07:09:27 11[ENC]=> => 2 bytes @ 0x7fe9311557be
Sep 30 07:09:27 11[ENC]0: 00 03 (3DES)
Sep 30 07:09:27 11[ENC] generating rule 6 TRANSFORM_ATTRIBUTES
Sep 30 07:09:27 11[ENC] generating TRANSFORM_S
Re: [strongSwan] incorrect notification data for critical invalid payload type
Hi Tobias, On Saturday 29 September 2012 02:04 AM, Tobias Brunner wrote: > Hi Gowri, > >> Here, this payload is of 9 bytes as payload length also mentions >> correctly. But, my doubt is on notification data which is 2D. >> It is always 2D even if I set notification data on sending node (say 01). > This value has nothing to do with the notification data, but with the > payload type of the unsupported payload. In your case it should be 01, > as can be seen here: I learnt this now. >> Sep 28 07:08:16 16[ENC] parsing (1) payload, 178 bytes left > When starting to parse the unknown payload the type is just printed as > number. So you are right the value (2D) is incorrect. The attached > patch and [1] should fix this issue for 4.6.4 and 5.0.x, respectively. > The problem was that the UNSUPPORTED_CRITICAL_PAYLOAD notify would > always contain the payload type of the last payload in the message (in > your case TSr) instead of the actually unsupported critical payload. I had a look at this code now. Yes, your fix solves this problem. Thanks both of you for your attention on here. Regards, Gowri Shankar > Regards, > Tobias > > [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=48651d8d > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] incorrect notification data for critical invalid payload type
.. Sep 28 07:08:16 16[ENC] generating rule 13 SPI Sep 28 07:08:16 16[ENC]=> => 0 bytes @ (nil) Sep 28 07:08:16 16[ENC] generating rule 14 NOTIFICATION_DATA Sep 28 07:08:16 16[ENC]=> => 1 bytes @ 0x7f03d4000b50 Sep 28 07:08:16 16[ENC]0: 2D - Sep 28 07:08:16 16[ENC] generating NOTIFY payload finished Here, this payload is of 9 bytes as payload length also mentions correctly. But, my doubt is on notification data which is 2D. It is always 2D even if I set notification data on sending node (say 01). Sep 28 06:43:57 16[ENC] parsing rule 14 NOTIFICATION_DATA Sep 28 06:43:57 16[ENC]=> => 1 bytes @ 0x7fdec80010b0 Sep 28 06:43:57 16[ENC]0: 01 and Sep 28 06:43:57 16[ENC] generating rule 12 U_INT_16 Sep 28 06:43:57 16[ENC]=> => 2 bytes @ 0x7fded914285e Sep 28 06:43:57 16[ENC]0: 00 01.. Sep 28 06:43:57 16[ENC] generating rule 13 SPI Sep 28 06:43:57 16[ENC]=> => 0 bytes @ (nil) Sep 28 06:43:57 16[ENC] generating rule 14 NOTIFICATION_DATA Sep 28 06:43:57 16[ENC]=> => 1 bytes @ 0x7fdec8000db0 Sep 28 06:43:57 16[ENC]0: 2D - Sep 28 06:43:57 16[ENC] generating NOTIFY payload finished I could not get what you said earlier for this value "received and rejected". As I am new in this area, can you please help me to understand it more. Thanks, Gowri Shankar > > Andreas > > On 07/01/2012 01:39 PM, gowrishankar wrote: >> Hi, >> >> I am testing IKEv2 implementation for invalid but critical payload type. >> strongswan seems to be sending notification payload of message type >> "UNSUPPORTED_CRITICAL_PAYLOAD" as expected. But, notification data is >> corrupted where as it should be a "one-octet payload type" as per >> Section 2.5 of RFC 5996 (or 4306). >> >> From charon.log: >> >> Jun 30 22:45:07 16[ENC] payload type (100) is not supported, but its >> critical! >> Jun 30 22:45:07 16[IKE] critical unknown payloads found >> Jun 30 22:45:07 16[ENC] added payload of type NOTIFY to message >> Jun 30 22:45:07 16[ENC] added payload of type NOTIFY to message >> Jun 30 22:45:07 16[ENC] generating CREATE_CHILD_SA response 2 [ N(CRIT) ] >> Jun 30 22:45:07 16[ENC] insert payload NOTIFY to encryption payload >> ... >> .. >> Jun 30 22:45:07 16[ENC] generating payload of type NOTIFY >> ... >> .. >> Jun 30 22:45:07 16[ENC] generating rule 14 NOTIFICATION_DATA >> Jun 30 22:45:07 16[ENC]=> => 1 bytes @ 0xad7005a8 >> Jun 30 22:45:07 16[ENC]0: >> 2D - >> Jun 30 22:45:07 16[ENC] generating NOTIFY payload finished >> >> Also, I found this problem might have been fixed in 5.0.0 version (thou- >> gh I have not yet tested), by a rework applied to handle variable >> length of payload data. >> >> http://wiki.strongswan.org/projects/strongswan/repository/revisions/95a26523afc0d2a997cd1d4f738c287ae045ae4e >> >> >> Can someone confirm if this was already reported (if so, strongswan >> bug id?) or I can open a defect to down-stream the patch in 4.6.x ? >> >> Thanks, >> Gowri Shankar > == > 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] Looking for clarification on charon handling new IKE_SA
Hi All, Please let us know if any one has thoughts about this problem. Thanks, Gowri Shankar On Monday 30 July 2012 12:21 PM, Kumuda wrote: Hi, In our test setup, IKE initiator rekeys IKE_SA using CREATE_CHILD_SA just before ike_lifetime expires and rekey request is successfully received by responder node and response is sent back. Initiator has below configuration: rekeymargin=20s ikelifetime="60s" keylife="300s" reauth="no" Also, INFORMATIONAL exchange for DELETE payload by initiator and responder is successfully completed at this time. Now, responder sends INFORMATIONAL request with Encrypted payload to verify new IKE SA session. Responder also makes sure that, new SPIs are used in this request. Here, we observe in charon.log (Initiator), below failure message. Jul 26 01:26:45 12[ENC] parsing ENCRYPTED payload finished Jul 26 01:26:45 12[ENC] verifying payload of type ENCRYPTED Jul 26 01:26:45 12[ENC] ENCRYPTED payload verified. Adding to payload list Jul 26 01:26:45 12[ENC] ENCRYPTED payload found. Stop parsing Jul 26 01:26:45 12[ENC] process payload of type ENCRYPTED Jul 26 01:26:45 12[ENC] found an encryption payload Jul 26 01:26:45 12[ENC] encryption payload decryption: Jul 26 01:26:45 12[ENC]0: DD 1A BC AA D5 54 FB E0 .T.. Jul 26 01:26:45 12[ENC] encrypted => 20 bytes @ 0x7f7b3c000bf8 Jul 26 01:26:45 12[ENC]0: D0 6D 64 EE F6 1D AA 1E D8 FA CD D5 2D FF DF 74 .md.-..t Jul 26 01:26:45 12[ENC] 16: 10 D5 1C 93 Jul 26 01:26:45 12[ENC] ICV => 12 bytes @ 0x7f7b3c000c00 Jul 26 01:26:45 12[ENC]0: D8 FA CD D5 2D FF DF 74 10 D5 1C 93 -..t Jul 26 01:26:45 12[ENC] assoc => 32 bytes @ 0x7f7b3c000c70 Jul 26 01:26:45 12[ENC]0: A4 27 73 19 9E F2 69 56 E5 F6 D2 48 C2 E9 CD 9E .'s...iV...H Jul 26 01:26:45 12[ENC] 16: 2E 20 25 00 00 00 00 00 00 00 00 3C 00 00 00 20 . %<... Jul 26 01:26:45 12[LIB] MAC verification failed Jul 26 01:26:45 12[ENC] verifying encryption payload integrity failed Jul 26 01:26:45 12[ENC] could not decrypt payloads Jul 26 01:26:45 12[IKE] integrity check failed Jul 26 01:26:45 12[IKE] INFORMATIONAL request with message ID 0 processing failed Jul 26 01:26:45 12[MGR] checkin IKE_SA tahi_ikev2_test[2] Jul 26 01:26:45 12[MGR] check-in of IKE_SA successful. Jul 26 01:26:45 09[NET] waiting for data on raw sockets What could have gone wrong with the INFORMATIONAL request sent from responder? Please provide some pointers for the above failure. Thanks and Regards, Kumuda G ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan: clarification needed on rekeying failure
Hi Martin,
Thought of checking with "keyingtries=1" when NO_PROPOSAL_CHOSEN is in
CREATE_CHILD_SA response.
From charon.log:
[IKE] CHILD_SA tahi_ikev2_test{1} established with SPIs cdee854a_i
e31e56a3_o and TS X:X:X:1::1/128 === Y:Y:Y:1::1/128
..
[KNL] received a XFRM_MSG_EXPIRE
[KNL] creating rekey job for ESP CHILD_SA with SPI cdee854a and reqid {1}
...
..
[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
[IKE] failed to establish CHILD_SA, keeping IKE_SA
[IKE] CHILD_SA rekeying failed, trying again in 24 seconds
[JOB] next event in 3s 930ms, waiting
[KNL] deleting SAD entry with SPI cb23d44e
...
[KNL] sending XFRM_MSG_DELSA: => 40 bytes @ 0x7fabc6b4a830
...
[KNL] creating rekey job for ESP CHILD_SA with SPI e31e56a3 and reqid {1}
[MGR] checkout IKE_SA by ID
[MGR] IKE_SA tahi_ikev2_test[1] successfully checked out
[IKE] queueing CHILD_REKEY task
[IKE] activating new tasks
[IKE] activating CHILD_REKEY task
...
..
I would like to know if "keyingtries" is applicable just after one
CREATE_CHILD_SA
attempt or its count is including even first attempt to rekey. As I set
its value to one
and I see in two places rekeying attempted, I am slightly confused here.
Can you
clarify please.
Thanks,
Gowri Shankar
On Thursday 28 June 2012 01:27 PM, Martin Willi wrote:
> Hi,
>
>>10[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
>>10[IKE] CHILD_SA rekeying failed, trying again in 24 seconds
>> Hence, is sending notify payload (no proposal chosen) not treated as
>> failure for rekey attempt?
> NO_PROPOSAL_CHOSEN usually indicates a permanent error, yes, but there
> are corner cases where a retry makes sense.
>
> RFC 5996 defines a TEMPORARY_FAILURE to indicate that rekeying is
> currently not possible (most likely because of an exchange collision),
> and the peer should try again. Before RFC 5996, there was no such
> specific notify, and NO_PROPOSAL_CHOSEN was used.
>
> We ourself still use a NO_PROPOSAL_CHOSEN notify in some of these
> situations. I think we should update to the new RFC 5996 notifies, but
> we haven't done this yet.
>
>> "If an SA has expired or is about to expire and rekeying attempts
>> using the mechanisms described here fail, an implementation MUST close
>> the IKE_SA and any associated CHILD_SAs and then MAY start new ones."
> Another reason for retrying is that the responder might have updated the
> configuration (for example, due to manual intervention). The hard SA
> lifetime still applies, and the SA gets deleted once expired. So I think
> we are fine with the above paragraph.
>
> Regards
> Martin
>
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] how to force re-try if received NO_PROPOSAL_CHOSEN notify error
On Thursday 05 July 2012 09:40 PM, Shukla, Sanjay wrote: I have a host to host configuration The initiator tried to create a tunnel to the peer, however a corresponding configuration was not found. Later on the peer updated its configuration and ipsec was restarted on the peer. However for my requirement I need the initiator to keep trying but it does not re-try if it receives if received NO_PROPOSAL_CHOSEN notify error for that connection. Are there any setting I can do for this. Initiator config. conn LocalIP_VIP_10.204.74.68 left=10.204.74.189 leftcert=ServLcl.pem leftsendcert=yes right=10.204.74.68 rightid=%any keyexchange=ikev2 type=transport reauth=no Not very sure what could happened in initiator side. Can you enable verbose level 4 for charon.log and see what happens after ipsec is reastarted in peer. http://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration dpddelay=5s dpdaction=restart closeaction=restart Hope, ipsec is restarted with in dpdtimeout . Regards, Gowri Shankar keyingtries=%forever auto=start -sanjay Please consider the environment before printing this email. -- DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] incorrect notification data for critical invalid payload type
Hi, I am testing IKEv2 implementation for invalid but critical payload type. strongswan seems to be sending notification payload of message type "UNSUPPORTED_CRITICAL_PAYLOAD" as expected. But, notification data is corrupted where as it should be a "one-octet payload type" as per Section 2.5 of RFC 5996 (or 4306). From charon.log: Jun 30 22:45:07 16[ENC] payload type (100) is not supported, but its critical! Jun 30 22:45:07 16[IKE] critical unknown payloads found Jun 30 22:45:07 16[ENC] added payload of type NOTIFY to message Jun 30 22:45:07 16[ENC] added payload of type NOTIFY to message Jun 30 22:45:07 16[ENC] generating CREATE_CHILD_SA response 2 [ N(CRIT) ] Jun 30 22:45:07 16[ENC] insert payload NOTIFY to encryption payload ... .. Jun 30 22:45:07 16[ENC] generating payload of type NOTIFY ... .. Jun 30 22:45:07 16[ENC] generating rule 14 NOTIFICATION_DATA Jun 30 22:45:07 16[ENC]=> => 1 bytes @ 0xad7005a8 Jun 30 22:45:07 16[ENC]0: 2D - Jun 30 22:45:07 16[ENC] generating NOTIFY payload finished Also, I found this problem might have been fixed in 5.0.0 version (thou- gh I have not yet tested), by a rework applied to handle variable length of payload data. http://wiki.strongswan.org/projects/strongswan/repository/revisions/95a26523afc0d2a997cd1d4f738c287ae045ae4e Can someone confirm if this was already reported (if so, strongswan bug id?) or I can open a defect to down-stream the patch in 4.6.x ? Thanks, Gowri Shankar ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan: charon not reacting for higher major version in IKE header
Hi Andreas, I also realised now that, both charon and pluto can now be enabled together wrt socket receiving side (and it was earlier a problem as in http://wiki.strongswan.org/issues/123 and fixed in 4.5.0. My another question here is, should charon-raw plugin report invalid version notification instead of dropping the packet ? Thanks, Gowri Shankar On Sunday 01 July 2012 10:45 AM, gowrishankar wrote: > Hi Andreas, > Thanks a lot! Yes, It was using socket-raw (as pluto is also > configured) . I disabled > explicitly in configure option and enabled socket-default, and seeing > invalid version > notification correctly. > > Jun 30 17:04:35 09[ENC] parsing rule 3 U_INT_4 > Jun 30 17:04:35 09[ENC]=> 3 > ... > Jun 30 17:04:35 09[ENC] parsing HEADER payload finished > Jun 30 17:04:35 09[ENC] parsed a IKE_SA_INIT request > Jun 30 17:04:35 09[NET] received unsupported IKE version 3.0 from > y:y:y:1::1, sending INVALID_MAJOR_VERSION > > > Thanks, > Gowri Shankar > > On Sunday 01 July 2012 12:11 AM, Andreas Steffen wrote: >> Are you using the charon daemon with the socket-raw plugin which >> filters and processes IKE major version 2 only or the socket-default >> plugin which processes all IKE packets irrespective of the major >> version? ipsec statusall shows which plugin is loaded. >> >> Regards >> >> Andreas >> >> On 30.06.2012 20:05, gowrishankar wrote: >>> Hi Andreas, >>> >>> I tested in strongswan-5.0.0rc1 as well, but same problem. >>> I'll debug some more and post here updates. >>> >>> Thanks, >>> Gowri Shankar >>> >>> On Saturday 30 June 2012 08:38 PM, Andreas Steffen wrote: >>>> Hi Gowri, >>>> >>>> have a look at the following piece of code in the git repository >>>> >>>> http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/network/receiver.c;h=f0cb0b2d17d153205e97f880e7daa0fdea89f974;hb=HEAD#l409 >>>> >>>> >>>> >>>> >>>> which is the basis of today's strongSwan 5.0.0 release. >>>> >>>> Regards >>>> >>>> Andreas >>>> >>>> On 06/30/2012 09:13 AM, gowrishankar wrote: >>>>> strongswan: charon not reacting for higher major version in IKE >>>>> header >>>>> >>>>> strongswan libcharon is found to be not reacting for invalid (or >>>>> higher) major version in IKE header of received packet. >>>>> >>>>> As per RFC 4306 Section 2.5: >>>>> If an endpoint receives a message with a higher major version >>>>> number, >>>>> it MUST drop the message and SHOULD send an unauthenticated >>>>> notification message containing the highest version number it >>>>> supports. >>>>> >>>>> and RFC 5996 Section 2.5 clarifies the notification message type as >>>>> "INVALID_MAJOR_VERSION". Though current implementation shows >>>>> portion of code libcharon/network/receiver.c, but it is not executing >>>>> while sending IKE_SA_INIT request with invalid major version (and >>>>> I am not seeing any debug info in charon.log for received packet >>>>> by net or enc threads). >>>>> >>>>> I tested with strongswan based on 4.6. >>>>> >>>>> Can some one have a look on this ? >>>>> >>>>> Thanks, >>>>> Gowri Shankar >> == >> 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] strongswan: charon not reacting for higher major version in IKE header
Hi Andreas, Thanks a lot! Yes, It was using socket-raw (as pluto is also configured) . I disabled explicitly in configure option and enabled socket-default, and seeing invalid version notification correctly. Jun 30 17:04:35 09[ENC] parsing rule 3 U_INT_4 Jun 30 17:04:35 09[ENC]=> 3 ... Jun 30 17:04:35 09[ENC] parsing HEADER payload finished Jun 30 17:04:35 09[ENC] parsed a IKE_SA_INIT request Jun 30 17:04:35 09[NET] received unsupported IKE version 3.0 from y:y:y:1::1, sending INVALID_MAJOR_VERSION Thanks, Gowri Shankar On Sunday 01 July 2012 12:11 AM, Andreas Steffen wrote: > Are you using the charon daemon with the socket-raw plugin which > filters and processes IKE major version 2 only or the socket-default > plugin which processes all IKE packets irrespective of the major > version? ipsec statusall shows which plugin is loaded. > > Regards > > Andreas > > On 30.06.2012 20:05, gowrishankar wrote: >> Hi Andreas, >> >> I tested in strongswan-5.0.0rc1 as well, but same problem. >> I'll debug some more and post here updates. >> >> Thanks, >> Gowri Shankar >> >> On Saturday 30 June 2012 08:38 PM, Andreas Steffen wrote: >>> Hi Gowri, >>> >>> have a look at the following piece of code in the git repository >>> >>> http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/network/receiver.c;h=f0cb0b2d17d153205e97f880e7daa0fdea89f974;hb=HEAD#l409 >>> >>> >>> which is the basis of today's strongSwan 5.0.0 release. >>> >>> Regards >>> >>> Andreas >>> >>> On 06/30/2012 09:13 AM, gowrishankar wrote: >>>> strongswan: charon not reacting for higher major version in IKE header >>>> >>>> strongswan libcharon is found to be not reacting for invalid (or >>>> higher) major version in IKE header of received packet. >>>> >>>> As per RFC 4306 Section 2.5: >>>> If an endpoint receives a message with a higher major version >>>> number, >>>> it MUST drop the message and SHOULD send an unauthenticated >>>> notification message containing the highest version number it >>>> supports. >>>> >>>> and RFC 5996 Section 2.5 clarifies the notification message type as >>>> "INVALID_MAJOR_VERSION". Though current implementation shows >>>> portion of code libcharon/network/receiver.c, but it is not executing >>>> while sending IKE_SA_INIT request with invalid major version (and >>>> I am not seeing any debug info in charon.log for received packet >>>> by net or enc threads). >>>> >>>> I tested with strongswan based on 4.6. >>>> >>>> Can some one have a look on this ? >>>> >>>> Thanks, >>>> Gowri Shankar > == > 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] strongswan: charon not reacting for higher major version in IKE header
Hi Andreas, I tested in strongswan-5.0.0rc1 as well, but same problem. I'll debug some more and post here updates. Thanks, Gowri Shankar On Saturday 30 June 2012 08:38 PM, Andreas Steffen wrote: > Hi Gowri, > > have a look at the following piece of code in the git repository > > http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/network/receiver.c;h=f0cb0b2d17d153205e97f880e7daa0fdea89f974;hb=HEAD#l409 > > which is the basis of today's strongSwan 5.0.0 release. > > Regards > > Andreas > > On 06/30/2012 09:13 AM, gowrishankar wrote: >> strongswan: charon not reacting for higher major version in IKE header >> >> strongswan libcharon is found to be not reacting for invalid (or >> higher) major version in IKE header of received packet. >> >> As per RFC 4306 Section 2.5: >> If an endpoint receives a message with a higher major version number, >> it MUST drop the message and SHOULD send an unauthenticated >> notification message containing the highest version number it >> supports. >> >> and RFC 5996 Section 2.5 clarifies the notification message type as >> "INVALID_MAJOR_VERSION". Though current implementation shows >> portion of code libcharon/network/receiver.c, but it is not executing >> while sending IKE_SA_INIT request with invalid major version (and >> I am not seeing any debug info in charon.log for received packet >> by net or enc threads). >> >> I tested with strongswan based on 4.6. >> >> Can some one have a look on this ? >> >> Thanks, >> Gowri Shankar >> >> >> ___ >> Users mailing list >> Users@lists.strongswan.org >> https://lists.strongswan.org/mailman/listinfo/users > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] strongswan: charon not reacting for higher major version in IKE header
strongswan: charon not reacting for higher major version in IKE header strongswan libcharon is found to be not reacting for invalid (or higher) major version in IKE header of received packet. As per RFC 4306 Section 2.5: If an endpoint receives a message with a higher major version number, it MUST drop the message and SHOULD send an unauthenticated notification message containing the highest version number it supports. and RFC 5996 Section 2.5 clarifies the notification message type as "INVALID_MAJOR_VERSION". Though current implementation shows portion of code libcharon/network/receiver.c, but it is not executing while sending IKE_SA_INIT request with invalid major version (and I am not seeing any debug info in charon.log for received packet by net or enc threads). I tested with strongswan based on 4.6. Can some one have a look on this ? Thanks, Gowri Shankar ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan: clarification needed on rekeying failure
Hi Martin, On Thursday 28 June 2012 01:27 PM, Martin Willi wrote: > Hi, > >>10[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built >>10[IKE] CHILD_SA rekeying failed, trying again in 24 seconds >> Hence, is sending notify payload (no proposal chosen) not treated as >> failure for rekey attempt? > NO_PROPOSAL_CHOSEN usually indicates a permanent error, yes, but there > are corner cases where a retry makes sense. > > RFC 5996 defines a TEMPORARY_FAILURE to indicate that rekeying is > currently not possible (most likely because of an exchange collision), > and the peer should try again. Before RFC 5996, there was no such > specific notify, and NO_PROPOSAL_CHOSEN was used. > > We ourself still use a NO_PROPOSAL_CHOSEN notify in some of these > situations. I think we should update to the new RFC 5996 notifies, but > we haven't done this yet. > Yes, it is better explained in RFC 5996. So, any suggestion that if I should raise a bug to improve this error handling in strongswan ? >> "If an SA has expired or is about to expire and rekeying attempts >> using the mechanisms described here fail, an implementation MUST close >> the IKE_SA and any associated CHILD_SAs and then MAY start new ones." > Another reason for retrying is that the responder might have updated the > configuration (for example, due to manual intervention). The hard SA > lifetime still applies, and the SA gets deleted once expired. So I think > we are fine with the above paragraph. > Agree. Thanks for the very useful reference you shared, Gowri Shankar > Regards > Martin > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] strongswan: clarification needed on rekeying failure
Hi,
I am looking for a clarification wrt "rekeying SA" in strongswan
implementation. During a rekeying negotiation to a remote peer, if local
node receives "NO_PROPOSAL_CHOSEN" in notify payload as a response to
CREATE_CHILD_SA request, should n't the current IKE SA be destroyed and
created once again ? but I observe that, CREATE_CHILD_SA is again
requested.
From charon.log: (X is local system and Y is remote system)
01[ENC] generating CREATE_CHILD_SA request 2 [ N(REKEY_SA)
N(USE_TRANSP) SA No TSi TSr ]
01[NET] sending packet: from X:X:X:1::1[500] to Y:Y:Y:1::1[500]
10[NET] received packet: from Y:Y:Y:1::1[500] to X:X:X:1::1[500]
10[ENC] parsed CREATE_CHILD_SA response 2 [ N(NO_PROP) ]
10[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
10[IKE] failed to establish CHILD_SA, keeping IKE_SA
10[IKE] CHILD_SA rekeying failed, trying again in 24 seconds
05[KNL] creating rekey job for ESP CHILD_SA with SPI 8a8cefdc and
reqid {1}
12[IKE] establishing CHILD_SA ikev2_test{1}
12[ENC] generating CREATE_CHILD_SA request 3 [ N(REKEY_SA)
N(USE_TRANSP) SA No TSi TSr ]
12[NET] sending packet: from X:X:X:1::1[500] to Y:Y:Y:1::1[500]
From ipsec.conf, timing settings:
ikelifetime="120s"
rekeymargin=5s
keylife="60s"
As per RFC 4306 (http://www.ietf.org/rfc/rfc4306.txt) Section 2.8,
"An implementation
MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA
has expired or is about to expire and rekeying attempts using the
mechanisms described here fail, an implementation MUST close the
IKE_SA and any associated CHILD_SAs and then MAY start new ones."
Hence, is sending notify payload (no proposal chosen) not treated as
failure for rekey attempt ? It can not be considered as packet loss as
initiator received the response anyway.
I am a newbie and please correct my understanding if you have better
answer.
Thanks,
Gowri Shankar
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] SHA2_256_128
On Wednesday 28 March 2012 11:51 PM, eric_c_john...@dell.com wrote: Hi. I have a situation where ESP packets appear to be getting mangled on the remote peer whenever I use SHA2-256-128 for Phase2 (ESP). I can establish the SAs from the Strongswan to the remote peer no problem. However, I get no packets returned after establishing the tunnel. The problem I am seeing is specific to this algorithm as I can get SHA1 working without any issue. I can also get SHA2_256_128 to work for P1 negotiations as well. What I am trying to find out is if there is any additional logging that I can enable on the Strongswan host Did you have a chance to check: http://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration Regards, Gowri Shankar that could shed some light as to what is being mangled. I am reversing the test to initiate from the remote peer thinking the logging on Strongswan can help me understand what is wrong with the ESP packets being sent. I've confirmed via traces that the peer sends the ESP packet to the Strongswan host but the logging doesn't show any indication that it received the packet. All I see are the regular DPD log entries. When I decrypt the trace using wireshark the packets are not being interpreted correctly. They should be IPv6 packets with an attempt to establish an ftp session. But wireshark interpret them as IPv4 packets (???) with a bogus IP length. Can anybody help? Thanks in advance. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Charon hangs after failing to delete Rekeyed IPsec SAs
Hi Anand, wrt RFC 4306 Page 22: If the two ends have the same lifetime policies, it is possible that both will initiate a rekeying at the same time (which will result in redundant SAs). To reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered (delayed by a random amount of time after the need for rekeying is noticed). Not a concrete suggestion, but to make sure that, strongswan 4.3(.6) is not having any bug (or improper handling) to gitter rekeymargin. Can it be searched quickly in git tree (for any such commit)? Second, after reading few following paragraphs (and importantly last para of Sec2.8), the timing window for rekeymargin is also associated to CREATE_CHILD_SA request handled by rekey responder. You may need to look closely in charon.log at this situation. I also observed that, you are setting keyingtries=1. Can it be the default 3 and tried once again, if there is any packet drop observed ? Thanks, Gowri Shankar On Tuesday 20 March 2012 06:24 PM, anand rao wrote: > Hi Tobias, > >I have already enabled both kernel-pfkey and kernel-netlink plugins. Both > the plugins are loaded. > This was suggested by Andreas for my earlier query about pfkey plugin usage > for IKEv1. > > Since 4.5.3 is causing kernel-panic in my environment for unknown reasons, i > want to resolve > the redundant child SA issue on 4.3.6. Please suggest me in resolving this > issue. > > Thanks, > Anand > > - Original Message - > From: Tobias Brunner > To: anand rao > Cc: "users@lists.strongswan.org" > Sent: Tuesday, March 20, 2012 2:25 PM > Subject: Re: [strongSwan] Charon hangs after failing to delete Rekeyed IPsec > SAs > > Hi Anand, > >> On my environment there is no support for kernel-netlink interface >> for IPsec, >> >> I have to use kernel-pfkey interface only as I have my hooks >> registered in PFKEY to XFRM for IPsec. >> >> I have tried latest versions of strongswan (4.5.1 and 4.5.3) both >> resulted in kernel panic after running for a while. I think there is >> not much support for kernel-pfkey plugin in latest strtongswan >> versions, and since latest versions require kernel-netlink plugin to >> function properly migrating to newer versions might be not helpful in >> my case. > You actually need both plugins on Linux, even if using kernel-pfkey to > install IPsec SAs and policies. The reason for this is that the > kernel-netlink plugin also implements the kernel_net_t interface which > is used for address and route lookups etc. You can enable both plugins, > the kernel-pfkey plugin is then loaded first by default (otherwise make > sure it is loaded first), which means that its kernel_ipsec_t > implementation is used while the kernel-netlink plugin can still provide > the required kernel_net_t implementation. > > Regards, > Tobias > > > ___ > Users mailing list > Users@lists.strongswan.org > https://lists.strongswan.org/mailman/listinfo/users > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] charon: [15]CFG trap not found, unable to acquire reqid 0
Hi Vilhelm, On Wednesday 21 March 2012 03:24 PM, Vilhelm Jutvik wrote: > Hello Gowri, > > this seems to be the same problem (however I cannot confirm that > SIGSEGV is the culprit in my case). > So, can you check/paste what is happening while ENC parsing IKE_SA_INIT response for SA payload. You can get it from charon.log with strongswan.conf setting as in http://wiki.strongswan.org/issues/184 If you see that, charon restarts just after that, following a error message something like "killing ourself, received critical signal", this confirms the SIGSEGV issue. Thanks, Gowri Shankar > I saw that you hadn't been able to reproduce the error on x86. My > error occurred on x86 while running on virtualized hardware (virtual > box). > > Sincerely, > Vilhelm Jutvik > > 2012/3/21 gowrishankar: >> Hi Tobias, >> >> >> On Wednesday 21 March 2012 12:44 AM, Vilhelm Jutvik wrote: >>> Dear Tobias, >>> >>> thank you very much. I thought that charon was signalled by the IPsec >>> stack's SPD when a new SA was to be negotiated, not that it itself set >>> the policy. >>> >>> Your solution didn't work right away though. I found that "ipsec >>> start" only started the starter process and nothing more. It was not >>> until I removed the charondebug option of the config section (as seen >>> below) that it started. It works though if you limit the debugging >>> level and / or the number of debugging options. I've reproduced this >>> several times just to be sure. Why is this? >>> >> I have observed the same problem recently and posted a patch in >> issue tracker. Can you please have a check. >> >> http://wiki.strongswan.org/issues/184 >> >> Thanks, >> Gowri Shankar >> >>> The problem line was (in full): >>> charondebug="asn 3,knl 3,mgr 3,ike 3,chd 3,net 3,enc 3" >>> It works if you change it so (e.g.) charondebug="ike 3" >>> >>> My strongswan version is 4.5.2 as included in Ubuntu 11.10 >>> >>> Sincerely, >>> Vilhelm Jutvik >>> MS Thesis Student at SICS >>> >>> 2012/3/13 Tobias Brunner: >>>> Hi Vilhelm, >>>> >>>>> config setup >>>>>crlcheckinterval=180 >>>>>strictcrlpolicy=no >>>>>plutostart=no >>>>>charondebug="asn 4, knl 4,mgr 4,ike 4,chd 4,net 4,enc 4" >>>>> >>>>> conn %default >>>>>auth=esp >>>>>authby=psk >>>>>esp=aes128ctr-aesxcbc! >>>>>ikelifetime=60m >>>>>keylife=20m >>>>>keyingtries=1 >>>>>rekeymargin=3m >>>>>keyexchange=ikev2 >>>>>ike=aes128ctr-aesxcbc-ecp192! >>>>>type=transport >>>> Your config file looks incomplete. You have to specify at least one >>>> conn section (other than %default) with the auto keyword (auto can be >>>> specified in %default, though). Where auto=route might be what you >>>> want, as charon will then install policies in the kernel's SPD and an SA >>>> will automatically be negotiated upon matching traffic. You also need >>>> to specify right and optionally left (the endpoints of the IKE_SA) in >>>> that conn section. If you only want specific traffic to be tunneled use >>>> the left|rightsubnet and left|rightprotoport keywords (see the example >>>> at [1]). >>>> >>>> Also if you want to configure the policies in the kernel yourself make >>>> sure you use a reqid>0 and then specify reqid=and >>>> installpolicy=no in the respective conn section. >>>> >>>> Regards, >>>> Tobias >>>> >>>> [1] http://www.strongswan.org/uml/testresults/ikev2/protoport-route/ >>> ___ >>> Users mailing list >>> Users@lists.strongswan.org >>> https://lists.strongswan.org/mailman/listinfo/users >>> >>> > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] charon: [15]CFG trap not found, unable to acquire reqid 0
Hi Tobias, On Wednesday 21 March 2012 12:44 AM, Vilhelm Jutvik wrote: > Dear Tobias, > > thank you very much. I thought that charon was signalled by the IPsec > stack's SPD when a new SA was to be negotiated, not that it itself set > the policy. > > Your solution didn't work right away though. I found that "ipsec > start" only started the starter process and nothing more. It was not > until I removed the charondebug option of the config section (as seen > below) that it started. It works though if you limit the debugging > level and / or the number of debugging options. I've reproduced this > several times just to be sure. Why is this? > I have observed the same problem recently and posted a patch in issue tracker. Can you please have a check. http://wiki.strongswan.org/issues/184 Thanks, Gowri Shankar > The problem line was (in full): > charondebug="asn 3,knl 3,mgr 3,ike 3,chd 3,net 3,enc 3" > It works if you change it so (e.g.) charondebug="ike 3" > > My strongswan version is 4.5.2 as included in Ubuntu 11.10 > > Sincerely, > Vilhelm Jutvik > MS Thesis Student at SICS > > 2012/3/13 Tobias Brunner: >> Hi Vilhelm, >> >>> config setup >>>crlcheckinterval=180 >>>strictcrlpolicy=no >>>plutostart=no >>>charondebug="asn 4, knl 4,mgr 4,ike 4,chd 4,net 4,enc 4" >>> >>> conn %default >>>auth=esp >>>authby=psk >>>esp=aes128ctr-aesxcbc! >>>ikelifetime=60m >>>keylife=20m >>>keyingtries=1 >>>rekeymargin=3m >>>keyexchange=ikev2 >>>ike=aes128ctr-aesxcbc-ecp192! >>>type=transport >> Your config file looks incomplete. You have to specify at least one >> conn section (other than %default) with the auto keyword (auto can be >> specified in %default, though). Where auto=route might be what you >> want, as charon will then install policies in the kernel's SPD and an SA >> will automatically be negotiated upon matching traffic. You also need >> to specify right and optionally left (the endpoints of the IKE_SA) in >> that conn section. If you only want specific traffic to be tunneled use >> the left|rightsubnet and left|rightprotoport keywords (see the example >> at [1]). >> >> Also if you want to configure the policies in the kernel yourself make >> sure you use a reqid> 0 and then specify reqid= and >> installpolicy=no in the respective conn section. >> >> Regards, >> Tobias >> >> [1] http://www.strongswan.org/uml/testresults/ikev2/protoport-route/ > ___ > Users mailing list > Users@lists.strongswan.org > https://lists.strongswan.org/mailman/listinfo/users > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] IKEv2 - IKE_AUTH request problem
Hi, Appreciating anyone willing to suggest possible cause(s) for the below problem found in Test "IKEv2.EN.I.1.1.1.3: Use of CHILD_SA" (TAHI IKEv2 test suite). I am using strongswan version of 4.5.2, for a endnode- endnode test, in RHEL6.2 environment. IKE_SA_INIT is established between NUT (node under test) and TN (test node), but IKE_AUTH request created by NUT is not observed by TN. Some settings used in ipsec.conf are below (and I can share others if needed for more debugging). # Attempt to rekey 5 seconds before the SA expires. rekeymargin=5s # Set the encryption algorithm for the child SA. esp=3des-sha1 # Set the encryption algorithm for the IKE SA. ike=3des-sha1-modp1024 # Set the lifetime for the IKE SA. ikelifetime="64s" # Set the lifetime for the child SA. keylife="128s" # Use perfect forward security on the IKE SA. pfs=no type=transport With debug mode set at level 4, following lines are caught in charon.log (though there are other informations which may not be required here): ... . 05[CFG] added configuration 'tahi_ikev2_test' 10[CFG] stroke message => -2036037751 bytes @ 0xfff80ede300 10[CFG] received stroke: route 'tahi_ikev2_test' . ... 10[KNL] adding policy === out 10[KNL] sending XFRM_MSG_NEWPOLICY: => 252 bytes @ 0xfff80edda28 10[KNL] unable to add policy === out 10[CFG] installing trap failed I am suspecting over stroke message which is shown as negative bytes. Before I dig something more deeper, I just liked to check this up with anyone who has seen this problem earlier. Thanks for the attention, Gowri Shankar ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Telnet over a tunnel using Local IP (rather than Public IP)
On Friday 23 December 2011 03:47 PM, Anupam Malhotra wrote:
> Hi Thomas
>
> The IKE_SA-negotiation is not failing. The tunnel is coming up. Only issue
> is that the local IP is being seen at the remote end (rather than the public
> IP).
>
> @Gowrishankar: I added the below snippet in strongsan.conf. But I do not see
> /var/log/charon.log getting created. Is there anything else that needs to be
> done so that this log file is created?
>
Hope you are running with charonstart=yes in ipsec.conf. Some more info
abt logger in
http://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration
Can you check if this helps ? But I could able to see ipsec creating
charon.log in /var/log/
with this option (as in link).
Thanks,
Gowri Shankar
> Best Regards
> Anupam Malhotra
>
>
> -----Original Message-
> From: gowrishankar [mailto:gowrishanka...@linux.vnet.ibm.com]
> Sent: Friday, December 23, 2011 3:20 PM
> To: Anupam Malhotra
> Cc: Thomas Egerer; users@lists.strongswan.org
> Subject: Re: [strongSwan] Telnet over a tunnel using Local IP (rather than
> Public IP)
>
> On Friday 23 December 2011 03:12 PM, Thomas Egerer wrote:
>> On 12/23/2011 09:40 AM, Anupam Malhotra wrote:
>>> Hi Thomas
>>>
>>> I did try "left=xp.xp.xp.xp". In that case, even the tunnel is not
>>> established. Is there anything else which I can try here?
>> Make sure that right on your cloud-server is xp.xp.xp.xp, too or
>> %any. If that doesn't do the trick, why don't you post the config
>> files on both of the servers and append the logs of the failed
>> IKE_SA-negotiation.
>>
> BTW, can you also try to check if charon.log shows any interesting error ?
> If strongswan.conf does not have filelog, you can try below one
> and share your findings (imp errors).
>
> filelog {
> /var/log/charon.log {
> # add a timestamp prefix
> time_format = %b %e %T
>
> # loggers to files also accept the append option to open
> files in
> # append mode at startup (default is yes)
> append = no
>
> # the default loglevel for all daemon subsystems (defaults
> to 1).
> default = 4
>
> # flush each line to disk
> flush_line = yes
>
> }
> default = 4
>
> # prepend connection name, simplifies grepping
> ike_name = yes
> }
> }
>
>
> Thanks,
> Gowri Shankar
>> Cheers
>> Thomas
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Telnet over a tunnel using Local IP (rather than Public IP)
On Friday 23 December 2011 03:12 PM, Thomas Egerer wrote:
> On 12/23/2011 09:40 AM, Anupam Malhotra wrote:
>> Hi Thomas
>>
>> I did try "left=xp.xp.xp.xp". In that case, even the tunnel is not
>> established. Is there anything else which I can try here?
> Make sure that right on your cloud-server is xp.xp.xp.xp, too or
> %any. If that doesn't do the trick, why don't you post the config
> files on both of the servers and append the logs of the failed
> IKE_SA-negotiation.
>
BTW, can you also try to check if charon.log shows any interesting error ?
If strongswan.conf does not have filelog, you can try below one
and share your findings (imp errors).
filelog {
/var/log/charon.log {
# add a timestamp prefix
time_format = %b %e %T
# loggers to files also accept the append option to open
files in
# append mode at startup (default is yes)
append = no
# the default loglevel for all daemon subsystems (defaults
to 1).
default = 4
# flush each line to disk
flush_line = yes
}
default = 4
# prepend connection name, simplifies grepping
ike_name = yes
}
}
Thanks,
Gowri Shankar
> Cheers
> Thomas
>
>
>
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Telnet over a tunnel using Local IP (rather than Public IP)
Hi Anupam, On Wednesday 21 December 2011 10:53 AM, Anupam Malhotra wrote: > > Hi All > > We have successfully established a tunnel from a server hosted in > cloud to a remote server. On executing “ipsec status”, we can see the > “IPsec SA established” message. The cloud server has a local IP (say > xl.xl.xl.xl) and we have also assigned a public IP (xp.xp.xp.xp) to > this cloud server. The remove server has an IP of say xr.xr.xr.xr. The > remote server’s firewall allows requests from xp.xp.xp.xp (public IP). > Requests from any other IP are blocked in the firewall. > > Now, when we do a telnet or ping to the remote server from the local > server, it times out without any response. The reason is that the > remote server’s firewall sees the request coming from the cloud > server’s local IP (xl.xl.xl.xl) and the firewall does not allow > requests from this IP. The firewall allows only the public IP > (xp.xp.xp.xp). Since the tunnel is successfully established, shouldn’t > the telnet or ping take the public IP (rather than the local IP)? > Did you get a chance to check SAD, using "ip xfrm state list" ?? or can you paste here ? Next check is in ipsec.conf for variable "mode". If it is transport, SA will be created in transport mode, for which authentication (and integrity too) are not provided , i.e remote firewall can easily drop the local source address as it is in IP header now. So to let SA cover it with tunnel end point IP, you need to set mode as tunnel. Please correct me if I am wrong. Thanks, Gowri Shankar > Any help would be really appreciated. > > Best Regards > > Anupam Malhotra > > > ___ > Users mailing list > Users@lists.strongswan.org > https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
