The driver and motivation?
Would like to hear your thoughts.
Plenty of firewalls and third party networks only allow 443 and 80 outbound. The moment a user gets stuck behind such a device, you’ll have a phone call and an issue you can’t fix.
Ssl vpn I use for client to site connect (workstation to server)
IPSec vpn I use for site to site connect, (site A (HQ) talking to site B)
For work-from-home, we offer both, but SSTP tends to work more often. Examples:
- Certain ISPs dropping ESP altogether
- NAT routers getting confused when there’s more than one client behind NAT when those clients are all talking to the same IPSec endpoint
- ability of SSTP to traverse proxies
- cellular networks not returning ICMP fragmentation needed for large ESP packets whereas SSTP does
Fixed site-to-sites I tend to use IPSec but when I don’t have control of the remote end, I’ve found SSTP has a better chance of working.
The reason that companies will use an SSL VPN over IPSec, is for 2 reasons:
- IPSec is not by default, NAT friendly, and requires the networking equipment to support NAT Traversal.
- IPSec, has multiple IP protocol numbers assigned to it, if devices in the middle block the protocols, if they block traffic other than TCP, UDP and ICMP, this will break IPSec.
Because Cisco bloody ASA f*cking AnyConnect shit. Arrrrghh!
IPEC is blocked on some networks. Most hardware providers charge extra for it
We use openvpn, because it works in most cases where IPsec ends up in interoperability hell. IPsec has too many config options and ambigous naming to make it expensive to operate. As ISP we do not always have the same vendor on both ends of a tunnel, and that’s when the fun starts.
It was easy to setup and deploy to my user devices, i have not had any issues with it connecting from behind home routers or hotels.
SSL/TLS VPNs are popular due to their accessibility, though I’m not sure how it compares efficiency wise to IPSEC.
OpenSSL is fairly easily implemented and well developed. Most importantly, TLS traffic usually passes through networks like any other web traffic, and is therefore almost always guaranteed to work. Not so with IPSEC.
Because some field offices of the largest corporations in the world block ipsec protocols at the firewall level - same goes for some hotels
That’s why we had to settle for SSL VPN
It’s been almost ten years since I’ve run a study, but back then we discovered that failure-to-connect happened roughly equally with IPsec-based and TCP-based client VPNs. This was surprising since it was assumed that TCP would “always” work, and that it was thus a safe bet to use just a TCP-based client VPN, but it wasn’t – at least at the time.
Today, many but not all client VPNs fall back from something else, with the least-preferred protocol tunneling over tcp/443. You want to avoid using TCP as first preference because tunning TCP inside TCP leads to unnecessary problems with TCP windowing and other misbehavior.
However, there are no “standard” methods of falling back from one VPN to another, which is why most sites seem to use some variety of proprietary VPN client software on client machines. Microsoft “Always On VPN” only works on W10, and seems to only fall back to SSTP. SSTP is a quasiproprietary protocol, but there are seems to be one client and a couple of servers that run on Linux.
While we still use some client VPNs, we’ve been aggressively replacing them with well-authenticated and authorized TLS/HTTPS connections. The biggest issue is when external or internal stakeholders want to use client VPNs as a quick fix to solve their proximate problem.
I’ve read about ipsec and it seemed the most arduous thing ever to implement and maintain in a complex fast moving environment without very specialized knowledge so I never attempted to use it lol but I’m probably just lazy
cheap licenses
Easy to implement
no major issues when connecting from any location
Every hotel wifi ever.
We once brought up an implementation issue that using RDP could result in users not being able to connect in if a firewall at an airport or hotel blocked that kind of traffic.
We got hard shut down that that was not an issue.
Cue two years later when they switched venues for the big industry show we put on… every salesman and executive in the building, zero RDP Connections. Probably around 200 people with no way to access company systems.
Obviously 100% of the blame was put on IT despite bringing it up as soon a we had access to facilities, asking for a dedicated connection with no firewall that was denied due to cost, and advising 5 times about the issues we had all seen occur.
At each step management made choices, and at each step it was deemed a trivial matter not worthy of any additional cost. We did 25% of our business in those 2 days and saw a 30% reduction in sales year over year.
Same for us. I found the OpenVPN server and client easy to set up for an “always on” VPN. But for site-to-site we use the IPSec built into our (Unifi) routers.
NAT routers getting confused when there’s more than one client behind NAT when those clients are all talking to the same IPSec endpoint
This issue with Unifi’s L2TP/IPSec server I considered an absolute dealbreaker. For us it’s certain two employees could work from the same remote location, and it just wouldn’t let the second connect. I don’t know if that’s affects all implementations but it made it useless.
IPSec, has multiple IP protocol numbers assigned to it, if devices in the middle block the protocols
True for original IPsec, but not true for IKEv2.
IPsec originally uses ip/51 and then ip/50. Most implementations from the last 15 years replaced ip/51 AH with udp/4500, as far as I’ve noticed, but ip/50 was still in use after session initiation. Then the newer “IKEv2” specification of IPsec uses udp/4500 for everything. In common use, “IKEv2” is typically distringuished from regular “IPsec”.
AnyConnect actually uses dTLS over udp/443 first, then only falls back to TLS over tcp/443, as far as I know. This is done because tunneling TCP tends to have issues, specifically with TCP windowing behavior differing between the tunnel and tunneled traffic.
Another factor is that Cisco licenses per-user for AnyConnect, but IPsec was always unlimited users on ASA and PIX. Circa 2010, Cisco stalled in providing a 64-bit Win32 AnyConnect client, seemingly in order to push end-user organizations into licensing AnyConnect. At the time ShrewSoft’s gratis IPsec client had a 64-bit PE32+ version for Windows, but we had problems getting it working reliably and satisfactorily compared to Cisco’s IPsec client. At that time we chose to migrate away from Cisco for client VPN, in favor of something much more open, and that proved to be a good decision.