This is the way I understand these protocols, it may not be 100% accurate, and I'm looking to see what the /r/networking metamind has to say on these topics, and hopefully gain some more insight in the process. Feel free to comment/correct wherever you feel like.
IPsec operates at layer 3 and as such seems a good candidate for LAN to LAN connectivity (though Client to LAN IPsec VPN is also reasonably common). It can handle multicast and broadcast traffic (though I never used this). Riding on top of IP (either as ESP or UDP when using NAT traversal mode) it provides a connectionless service, much like plain IP. When used in interface/VTI mode, it provides for a fair bit of flexibility in terms of dynamic routing. Though the way I see it interface or policy mode isn't something that's intrinsic to IPSec itself, but rather to the specific implementation. At the end of the day IKE sets up the tunnel parameters and the encrypted ESP (or UDP) packets flow between the endpoints. The other endpoint neither knows nor cares if the other side used an interface style configuration or a policy style configuration to decide which packets to encrypt and send over. Initially I thought SSLVPN can't be this flexible, but now that I think about it, OpenVPN is essentially SSLVPN and it can do LAN to LAN just fine (including dynamic routing), though I've never come across a commercial SSLVPN that can do this.
IPsec provides for tunnel and transport modes. The way I used these is usually I go for tunnel mode (and except for Cisco routers the other devices I played with don't even seem to have a transport mode, unless you dig very deep into the nerd knobs). I've only seen transport mode on Cisco and Mikrotik. The only use case I see for transport mode is, when using GRE over IPSEC, it saves you a bit of overhead, since GRE already has the inner IP header. Though afaik you can run GRE over IPsec with tunnel mode IPsec and it works just fine. Is anyone aware of any other use cases for transport mode? Also, transport mode unless it has GRE on top of it is pretty much useless (you could use it to manage the device itself, but SSH does the same thing just fine so why reinvent the wheel).
IPsec is a bit more of a standard than SSLVPN in that a firewall from vendor A will most of the times be able to build a tunnel to a firewall from vendor B (or a Windows/Linux station), whereas SSLVPN implementations are vendor specific and you either need and application from that vendor on the client (or sometimes a browser plugin). But then again, there's OpenVPN
SSLVPN uses the same TLS as HTTPS so it works at layer 4 (or above if you want to consider the TLS as a separate session layer). I would say this makes it easier to use from behind a firewall you don't control. Any hotel/airport Guest Wifi will likely allow TCP 443 to pass through without much hassle, and the same can definitely not be said for IKE and ESP.
I've never had this happen to me, but I think I read somewhere that it's possible for the TCP flow control/retransmission mechanism governing the SSL connection to interfere with the TCP flow control/retransmission running in the TCP sessions in the tunnel. I imagine that there should be no issues with UDP inside traffic other than negating any advantages that the lightweightnes of UDP may bring. However a scenario in which two flow control/retransmission mechanisms are working independently may do more harm than good seems plausible.
The SSLVPN implementations I used were solely for Client to server traffic.
All SSLVPN implementations (that I've seen) are essentially tunnel mode.
I've not seen any LAN to LAN SSLVPN implementation from the major vendors (which isn't to say such a thing does not exist). What I do remember seeing was an OpenVPN + BGP (using Quagga) though at the time I really did not understand the details of how it worked. Looking back on it though I think it was pretty close to DMVPN in terms of dynamic failover capabilities - though it couldn't go as far as dynamic spoke-to-spoke tunnels, an orchestration layer build on top of it with Puppet took it pretty close. And if I understand correctly OpenVPN is essentially an open SSLVPN implementation.
Come to think of it, what do proprietary SSLVPN implementations offer that OpenVPN does not? I'm probably wrong but the only thing I see coming with a proprietary SSLVPN implementation, is the inability to operate with other vendors.
SSH "VPN" though I only very rarely used this, seems much like SSLVPN. Any comments welcome here.
Writing this post I had to reevaluate how things actually work. In the beginning I thought IPsec was for LAN to LAN whereas SSLVPN was for host to LAN, but midway through I realized that OpenVPN (which is SSLVPN) can do LAN to LAN and host to LAN (and I knew from the start that client IPsec VPN was an option). Functionality wise at least when comparing OpenVPN with IKE/IPsec VPN, I find no meaningful differences (though when it comes to specific implementation there may be significant differences). It may be that the IKE/IPsec offers a bit more interoperability(but I suppose this is due to firewall vendors choosing to invest more into IT, probably the same could have been done with SSLVPN) and that SSLVPN will have an easier time traversing firewalls, but that's about it.
Now I'm asking myself, why did we end up with two different protocols that basically do the same thing? Which came first, and why was there another invented when there was already a first one?
No comments:
Post a Comment