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 > <[email protected] > <mailto:[email protected]>> 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 > >
signature.asc
Description: OpenPGP digital signature
