There are two kinds of remote access which you may use in order to provide remote access for teleworkers in your company, namely IPSec and SSL. Both of them are reliable, secure and work very well but … there is always the catch. Based on one simple example of live, let me familiar you with advantages of IPSec and SSL and reveal their downsides.
Before I go over the next part, for those of you that are not familiar or weakly familiar with IPSEC I recommend reading another post http://itbundle.net/archives/268 and also recommend reading http://itbundle.net/archives/280 regarding how Firewall and statefull filtering work.
Let’s check how in Cisco world (not only) IPSec and SSL protocols might by used
As we can see, SSL we are going to use in case of end user remote access: Clientless (via web browser) on the port TCP 443, Full-Tunnel Client Based (via Anyconnect Client) with using SSL/TLS/DTLS. IPSec we are going to use in case of Remote Access and Site to Site connection : Full-Tunnel Client Based on IPsec VPN (via old Cisco VPN client or Anyconnect), Remote Site based on IPSec (via ASA appliance or Cisco router).
TLS (Transport Layer Security) is a newer version of SSL (Secure Socket Layer) protocol, DTLS stands for (Datagram Transport Layer Security) and may by used in case we want to increase speed of our secure connection, then packets are being encapsulated in UDP not TCP.
Ok, now let’s go over our case.
Let’s assume that one of an employees from your company has went on delegation and he wants to establish secure connection with company from the outside world via the Internet. I assumed that on the edge of the hotel infrastructure may be any device with Statefull Filtering and we don’t know network engineer who works for them. Your employee may do that in two ways via IPSec or SSL.
In order to establish IPSec connection we need to fulfill 2 things: via UDP port 500 we negotiate Security Association by ISAKMP and via ESP (Encapsulating Security Payload), protocol number 50 we transfer encapsulated, secured data. ESP protocol works on the top of IP and doesn’t work based on port numbers but instead of that it uses SPI (Security Parameter Index – 32 bit long value). During the first phase which needs UDP port 500 opened everything usually will be going seamlessly, during next phase we may encounter a problem. If PAT uses TCP ports to translate, IPSec uses SPI instead of TCP ports, there is nothing to translate. An employee in the Hotel, tries establish connection and what happen is: in the Anyconnect an employee sees that connection has been established, he even gets an IP address from the internal pool, but he will notice also in statistics that a lot of packets are going out but none packets return, because the Hotel firewall doesn’t allow for establishing the second phase of IPSec. Can we handle with that ? Sure, we may use NAT-T (NAT traversal) which allows us to send traffic in both direction via UDP port 4500, then we don’t have to worry about PAT (Port Address Translation). As I mentioned, PAT requires TCP ports number which are being translated as a socket with IP addresses, if we don’t use TCP but SPI with ESP on the top of IP, then we don’t have any port numbers (TCP port stands behind encrypted original IP header). Our port numbers are encrypted in secured payload and IP NAT service on the firewall doesn’t have access to them. Of course we need to have opened port 4500 on the Hotel firewall and it might be an another problem.
SSL uses TCP protocol, usually it will be port 443, it doesn’t have to be, in case of remote access but is strongly recommended, because port 443 will be always opened on firewalls (otherwise any hotel guest won’t be able to get to any sites that uses HTTPS protocol – bank, facebook etc). Of course using TCP causes greater overhead then IPSec, data retransmission and is less efficient owing to that, but probably you won’t encounter any problems with SSL Remote Access.