I was setting up a new site-to-site for a client today with a TZ370. Their vendor had an ASA Virtual firewall, so the vendor basically gave me the particulars the tunnel needed on their end.
To be precise, the IKE Phase 1 settings were:
Exchange: Main Mode
DH Group: Group 5
Encryption AES-256
Authentication: SHA1
Lifetime: 86400
The IKE Phase 2 setting were:
Protocol: ESP
Encryption: AES256
Authentication: SHA1
Perfect Forward Secrecy was ENABLED, with DH Group = 5 and a lifetime of 86,400.
The tunnel came up successfully, but these settings are considerably different than the ones we typically use when we’re going between two Sonicwalls, so I suspect it’s time to revisit those settings.
I setup a lab firewall (a TZ270) on our secondary internet, and created a tunnel to our main firewall (a TZ500) on our primary internet to play around.
To start, I duplicated the settings above on both firewalls, but tunnel would not come up. If I dialed back the Phase 2 settings to 3DES for Encryption, SHA1 for Authentication, and disabled Perfect Forward Secrecy", then the tunnel came up successfully. It also worked when Perfect Forward Secrecy was re-enabled without changing the encryption settings.
There is a lot of information on what every individual setting means, but precious little on the interaction of the settings with each other. Most Sonicwall documentation say something along the lines of “Select the desired item”, without further explanation. So, what are considered reasonable settings in today’s environment?
I’d suggest you take a look at this document from Cisco regarding recommended cryptographic algorithms. Neither the settings requested by the vendor nor your lab settings meet my company’s minimum standards for secure VPN parameters.
I try to align with NGE/QCR and avoid legacy/avoid. Most vendors don’t know much about this stuff and I’ve had pretty good luck pushing back when their preferred parameters don’t meet our standards.
SHA is deprecated in most CIsco stuff. Is it an ASA or Firepower. I ask ask 3DES is not an option in my FP and I would really be shy of anything still using a weak security algorith connecting to my stuff.
Hi I’ve worked last year at sonicwall as a support engineer .Sonicwall had weird issue related to 3Rd party firewalls try every time to have the latest firmware on the sonicwall and Cisco too plus redo the S2S again .Hope it helps
This was another useful resource I stumbled upon years ago: Diffie Hellman Groups - Cisco Community
Thanks for the links. I guess what I was really asking in retrospect was "what are your minimum standards for secure VPN parameters? I’m guessing by the links that the answer is “we follow Cisco’s suggestions”. Fair enough.
Obviously, we have full control over the settings where our clients own the equipment on both ends of the tunnel, but for Vendor stuff like this, we are stuck playing by their rules. I did push back a bit when them mentioned SHA1 authentication, and asked if we could change that - they made it sound like they would have to move heaven and earth and impact dozens of other clients to change the settings. This probably translates to “this sounds like non-billable work, so we’re not doin’ it”.
The vendor told me it was a virtual ASA - I’ve not seen the interface directly, nor do I expect to. The vendor isn’t connecting to my stuff, the are connecting to my client’s stuff. It’s my clients vendor, so I’m fighting two fronts on this problem. I would have to convince my client they should be concerned enough to convince their vendor to tighten security. I can ask and make the case, but I don’t there is a big chance they’ll do it.
These are what I consider minimum & still widely supported by most firewalls/VPN solutions:
Exchange: IKEv2
DH Group: 14
Encryption: AES-256
Authentication: SHA256
Phase 2:
Protocol: ESP
Encryption: AES-256
Authentication: SHA256
PFS: Enabled with DH Group 14
Even better swap out DH group 14 in phase 1 and 2 with an ECP group. And use AESGCM16-128 for the encryption.
Virtual ASA (aka ASAv) will support modern IPsec standards like IKEv2, modern crypto like AES-256 and SHA-256, and interoperating with SonicWall and plenty of others. Just as long as the people configuring it know what they are doing. There isn’t anything inherently wrong the ASAv just like there isn’t with SonicWall’s NSA virtual (NSv) devices.
No one should be using 3DES, IKEv1, disabled PFS, or day-long tunnel lifetimes. It’s ok to politely suggest that there is a safer way to set up these tunnels, that everyone’s using modern gear and can use contemporary configs. You wouldn’t force SSLv3 in favor of TLS 1.2, right? So it’s just as bad of an idea to do the same with IPsec.
that’s what I use myself!