[strongSwan] Issue with IKE_SA rekey towards Cisco

[Rajiv Kulkarni]

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
        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> 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",
> > 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180116/7990bdb2/attachment.html>