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