[strongSwan] Issue with IKE_SA rekey towards Cisco

Tue Jan 16 18:56:15 CET 2018

Hi,

> Note: Iam not using the option "forceencaps=yes"...i dont think its required...and my personal opinion...it shouldnt be used..

You'll end up using UDP encapsulation anyway if either of the peer proposes it. Might be because of NAT.

Kind regards

Noel

On 15.01.2018 20:13, Rajiv Kulkarni wrote:
> Hi
> 
> If iam correct...these tunnels to be established are Cisco-ezvpn tunnels using the Cisco-unity plugin..
> 
> The Cisco EzVPN IPSec Tunneling work only with IKEv1...and if PSK is used..with GroupID...then it has to be aggressive-mode only. And ofcourse XAUTH is needed
> 
> By the way the Groupnames fall under KEYID so...why dont you try the below on the strongswan client?
> 
> Note: Iam not using the option "forceencaps=yes"...i dont think its required...and my personal opinion...it shouldnt be used..
> 
> 
> ====================
> ipsec.conf
> ====================
> conn client1
>         auto=start
>         left=%any
>         right=33.33.33.4
>         leftauth=psk
>         rightauth=psk
>         aggressive=yes
>         leftid=keyid:Group1
>         rightid=%any
>         modeconfig=pull
>         leftsourceip=%config
>         rightsubnet=0.0.0.0/0 <http://0.0.0.0/0>
>         xauth=client
>         leftauth2=xauth
>         xauth_identity=rajiv
>         dpddelay=20
>         dpdtimeout=60
>         dpdaction=clear
>         ikelifetime=28800s
>         lifetime=3600s
>         rekeymargin=180s
> 
> 
> ========================
> ipsec.secrets
> =====================
> # auto-generated config file from /tmp/etc/config/strongswan
> @#47726F757031 : PSK "Test$123456789"
> rajiv : XAUTH "config123"
> 
> 
> Please note: The value shown as "47726F757031" (without including @# chars which are strongswan-specific), is actually a converted "hex-value" of the ASCII-characters "Group1" (without the quotes and not including the "keyid:" which is strongswan-specific option)
> 
> - use a ASCII to Hex converter...and convert "Group1" groupid to its hex-value...and use it as shown in the ipsec.secrets file above
> - In the ipsec.conf file...always use the "keyid:groupid" method to set the leftid on the client
> 
> Always use this way with strongswan...it works better.. 
> 
> I havent tried the above client config with Cisco-ASA applianc....BUT...the above works with the Cisco2951-IOS-Router (as the EzVPN-server)...and i dont have any issues with rekeying (either with IPsec-SA or the IKEv1-SAs)
> 
> 
> Hope this above info is of some use
> 
> 
> thanks & regards
> Rajiv
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, Jan 11, 2018 at 5:43 PM, Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting <mailto:noel.kuntze+strongswan-users-ml at thermi.consulting>> wrote:
> 
>     Hi,
> 
>     I'm absolutely baffled why you choose a weak PSK-Xauth authentication scheme with aggressive mode.
>     You're basically doing everything wrong. At least use Pubkey-Xauth with hybrid mode authentication. That way,
>     the clients don't need a certificate and an attacker listening in on the KEX can not use an offline dictionary attack on the PSK
>     and other client's can't perform MITM attacks.
> 
>     And please use a modern cipher suite. It's very cheap and your auditors will thank you. It also looks better and is more professionally.
> 
>     The problem is with the responder. It doesn't answer and deletes reauthed IKE_SAs. Read or provide its logs.
> 
>     > Thu, 2018-01-04 21:22 06[ENC] <home|2> generating TRANSACTION request 238578509 [ HASH CPRQ(ADDR DNS U_SPLITINC U_LOCALLAN) ]
>     > Thu, 2018-01-04 21:22 06[NET] <home|2> sending packet: from 192.168.10.23[4500] to <CONCENTRATOR IP>[4500] (92 bytes)
>     > Thu, 2018-01-04 21:22 02[IKE] <home|2> sending retransmit 1 of request message ID 238578509, seq 3
> 
>     > Thu, 2018-01-04 21:27 13[NET] <home|4> received packet: from <CONCENTRATOR IP>[4500] to 192.168.10.23[4500] (92 bytes)
>     > Thu, 2018-01-04 21:27 13[ENC] <home|4> parsed INFORMATIONAL_V1 request 3161543286 [ HASH D ]
>     > Thu, 2018-01-04 21:27 13[IKE] <home|4> received DELETE for IKE_SA home[4]
> 
>     Please keep attaching the logs to your emails.
> 
>     Kind regards
> 
>     Noel
> 
>     On 10.01.2018 16:44, Henrik Juul Pedersen wrote:
>     > Hi StrongSwan community,
>     >
>     > I'm implementing a VPN based on StrongSwan for the client side (an
>     > embedded linux board) for a customer. Currently we are testing against
>     > a Cisco ASA5506.
>     >
>     > Our requirements:
>     >  - Clients must be able to uniquely identify themselves
>     >  - Clients has unique passwords generated from secrets known in both ends.
>     >  - Clients must get IP and DNS information from the concentrator
>     >  - Clients must function behind NAT
>     >
>     > We have implemented it with IKEv1 and XAUTH, we use a secret shared
>     > between all clients for the first stage IKE_SA, and we use a generated
>     > password and a unique username for XAUTH.
>     >
>     > The clients connect and are able to rekey CHILD_SA on expiry every
>     > hour, but when reauthenticating IKE_SA after 4 hours, some
>     > miscommunication result in loss of connection.
>     >
>     > I can't disclose the customer, or their application, but I've supplied
>     > sanitized configuration- and log-files, which should show the setup
>     > and the runtime results. If I've removed some important context please
>     > let me know, and I'll try and present the needed information.
>     >
>     > We have enabled 'cisco_unity' in charon.conf, and for testing we have
>     > enabled 'i_dont_care_about_security_and_use_aggressive_mode_psk', so
>     > this shouldn't be the thing stopping us.
>     >
>     > We have tested the setup with a Shrew Soft client on a Windows
>     > machine, which seems to be able to keep the connection alive
>     > indefinitely (possibly with minor interruptions - we haven't been able
>     > to test with a long-running connection on Windows).
>     >
>     > These logs are made from a Linux PC with newest available StrongSwan client:
>     >  - IKE charon daemon (strongSwan 5.6.1, Linux 4.14.10-1-ARCH, x86_64)
>     >
>     > We are not using swanctl as that isn't the default for our embedded
>     > target. We control StrongSwan using the ipsec script.
>     >
>     > I've tried to follow
>     > "https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests <https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests>",
>     > and have supplied full (sanitized) log files as MIME attachments.
>     > Please let me know if you prefer them externally hosted, or supplied
>     > inline in future communication.
>     >
>     > I hope some of you have an idea of what the issue might be. I'm sure
>     > we've just made some misconfiguration.
>     >
>     > Thank you in advance,
>     > Best regards
>     > Henrik Juul Pedersen
>     > LIAB ApS
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180116/9a86b191/attachment.sig>