Are VPN and IPSec similar

IPsec - Security Architecture for IP

IPsec is an extension of the Internet Protocol (IP) to include encryption and authentication mechanisms. This gives the Internet Protocol the ability to transport IP packets cryptographically secured over public and insecure networks. IPsec was developed by the Internet Engineering Task Force (IETF) as an integral part of IPv6. Because version 4 of the Internet protocol originally had no security mechanisms, IPsec was specified for IPv4 at a later date.

Components of IPsec VPNs

  • Interoperability
  • Cryptographic protection of the transmitted data
  • Access control
  • Data integrity
  • Authentication of the sender (user authentication)
  • Encryption
  • Authentication of keys
  • Management of keys (key management)

These components are based on processes that, when combined, offer reliable security for data transmission over public networks. VPN security solutions with high security requirements generally rely on IPsec.

Deployment scenarios

  • Site-to-Site-VPN / LAN-to-LAN-VPN / Gateway-to-Gateway-VPN
  • End-to-Site-VPN / Host-to-Gateway-VPN / Remote-Access-VPN
  • End-to-End-VPN / Host-to-Host-VPN / Remote-Desktop-VPN / Peer-to-Peer-VPN

In principle, IPsec is suitable for gateway-to-gateway scenarios. In other words, the connection between networks via a third, insecure network. The host-to-gateway scenario, which corresponds to the remote access scenario, is also conceivable. The complexity of IPsec and some shortcomings of TCP / IP can occasionally cause problems here. The host-to-host scenario is rather untypical, but it is also possible.

IPsec has the disadvantage that it can only tunnel IP packets. In addition, it is rather unsuitable for remote access without additional protocols, as the functions for configuring the IP address, subnet mask and DNS server are missing. It therefore makes sense to consider SSL-VPN or other solutions and protocols in addition to IPsec when implementing a VPN.

IPsec: Trusts / Security Association

The main components of IPsec are the trust relationships (Security Association) between two communication partners. A relationship of trust does not necessarily have to be between the endpoints (clients) of a transmission link. It is sufficient if z. B. when coupling two networks, the two routers have a trust relationship. It goes without saying that there can also be several trust relationships for a connection.
The trust relationships regulate the communication of IPsec. The relatively flexible combinations of trust relationships require a great deal of configuration effort.

In order to be able to establish a secure connection between two stations, some parameters must be exchanged on both sides:

  • Type of secure transmission (authentication or encryption)
  • Encryption algorithm
  • key
  • Duration of the key's validity

Trust relationships are established by exchanging pre-defined keys. Another form is the issuing of certificates by a trust center or an installed certificate server. Keys and certificates are intended to ensure that whoever has a key or certificate is who he claims to be. Similar to an identity card, which one person uses to identify himself to another person.

  • PSK - Pre-Shared Keys
  • X.509 certificates

Keys or certificates, it doesn't matter, both methods take a lot of time and care to set up. The simpler variant is the secret key (password or passphrase). It is important that both endpoints are informed about the IP address, subnet mask, tunnel name and the secret key. In addition, there are parameters that define the details of authentication, encryption and the length of the key.

An identifier must be configured for authentication with a pre-shared key. The identifier is additional information that the remote stations (gateway and client) can use to identify themselves. IP addresses, DNS names (FQDN) or e-mail addresses (FQUN) are often used for this.

Tunneling and encryption

The central functions in the IPsec architecture are the AH protocol (Authentication Header), the ESP protocol (Encapsulating Security Payload) and key management. IPsec fulfills authenticity, confidentiality and integrity through AH and ESP.
To set up a VPN, IPsec has the Authentication Header (AH) and the Encapsulating Security Payload (ESP). Both can be used together or independently. Secure transmission takes place in both procedures.
The AH protocol takes care of the authentication of the transmitted data and protocol information. The ESP protocol increases data security depending on the selected encryption algorithm.

IPsec does not require a specific encryption and authentication method. As a result, problems often arise when different VPN products have to work together.

Key management with IKE - Internet Key Exchange Protocol

There are two ways to manage and distribute keys within a VPN. In addition to the pure manual key management, the Internet Key Exchange Protocol (IKE) can also be used.
Before the protected communication can take place, the communication partners must agree on the encryption method and key. These parameters are part of the security association (trust relationships) and are automatically negotiated and managed by IKE / IKEv2.
The Internet Key Exchange Protocol is used for automatic key management for IPsec. It uses the Diffie-Hellman method to securely generate keys over an insecure network. On the basis of this procedure, a number of key exchange procedures were developed, some of which form the basis for Internet Key Exchange.
IKE is based on the Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP is a set of rules that precisely defines the behavior of the remote stations involved. IKE determines how this is to be done. The flexibility of IKE is expressed in its complexity. If different IPsec systems cannot exchange security associations, then this is mostly due to a faulty IKE implementation or a lack of encryption methods.

Version 2 of the Internet Key Exchange Protocol (IKEv2) simplifies setting up a VPN. It's much simpler, more flexible, and less error-prone. In particular, the Mobility and Multihoming Protocol (MOBIKE) is intended to ensure that IPSec tunnels function significantly more reliably in mobile applications.
IKEv2 corrects some weaknesses or problems of the previous version. The definition has been summarized in a document, the connection establishment has been simplified and many improvements have been added. Overall, IKEv2 is less complex than the previous version. This simplifies implementation, reduces errors and thus increases security.
However, IKEv2 is not backward compatible with IKE. However, both protocols are operated via the same UDP port.

The terms main mode and aggressive mode are often used in connection with IPsec. There are different methods of key negotiation.

VPN with IPsec in practice

The network participants in LAN 1 can access LAN 2 and, conversely, participants from LAN 2 can access LAN 1. The connection via the Internet is via an encrypted tunnel.
The two firewalls must clearly prove their identity when establishing a connection. This means that unauthorized access is excluded. Communication over the Internet is encrypted. If a third party logs the data packets, he will only receive garbage.

So that both networks can establish a connection to each other, the IP address of the other network must be known. A fixed IP address is therefore required to establish a connection, otherwise establishing a connection will be complicated. If the IP address of a network changes, e.g. B. when establishing a connection to the Internet provider or access network operator, the addresses must be exchanged for new ones. Either manually or via dynamic DNS entries with DDNS.

In order for the routing between the networks to work, the address ranges within the networks must be different. Since the networks behave like one after interconnection, IP addresses must not appear twice. Therefore, a separate address range, i.e. different subnets, must be configured in advance on both sides.

Problems with NAT

If it is ensured that the VPN remote sites support the same encryption method and the IKE implementation is error-free, the key exchange with IKE can still fail on the NAT routers involved.

If network stations in local networks (LAN) have private IP addresses and access the Internet via NAT routers, then IPsec has problems with NAT. NAT gives an IPsec packet a new IP address and a different source port. The problem with this is that if an IPsec packet is changed, it becomes invalid. As a result of the change, the integrity of the package is no longer guaranteed. It must be discarded. Of course, no connection can be established in this way.
Another problem is that original IP addresses and TCP ports are encrypted. So the NAT router cannot get to them. And so it is not possible to assign the IP packets to a network station. The information required for this is transmitted during the secure key exchange. And there the NAT router has no insight. The information is given in the SPI value (Security Parameters Index). The VPN tunnel could thus be assigned to a host. However, because of the encrypted transmission of the SPI, the NAT router cannot read this value.

To avoid both problems, some routers can use the IPsec pass-through method, in which the ports are not changed. Unfortunately, passthrough only works with a single client in the network.

IPsec passthrough (obsolete)

The port assignment (IKE) is not changed with IPsec passthrough. The IP address of the ESP packets is rewritten for a client. This means that the packets handled with ESP can only be assigned to one connection and one client. This is why IPsec passthrough only works with a single client behind a NAT router.
Because usually more than one client always wants to operate an IPsec connection, IPsec passthrough is rarely used any more. The IPsec extension NAT traversal is used. The ESP packets are packed in UDP packets and sent via port 4500. NAT routers can then rewrite IP addresses and ports.

IPsec with NAT traversal

Because the original IPsec does not work via NAT routers, it is usually used with the IPsec extension NAT traversal. In this scenario, both communication partners exchange various information via the NAT traversal protocol. The ESP packets are then packed in UDP packets and sent via port 4500. Then the NAT routers can rewrite IP addresses and ports without any problems.

NAT traversal is integrated in the IKE protocol (Negotiation of NAT traversal in the IKE). While an IKE Security Association is being established, an attempt is made to determine whether there is a NAT router between the remote stations. If so, the encapsulation of the IPsec packets in UDP packets is negotiated. This means that a UDP header is inserted between the IP header and the ESP header. The full name for this is UDP Encapsulation of IPsec ESP Packets. This process is usually referred to as IPsec NAT traversal.
For this to work, the responder must have opened port 4500 (UDP and TCP). The responder is the one who responds to the initialization of the IKE Security Association.

IPsec is usually always used with the NAT traversal extension. It works with practically any NAT router.

Procedure for setting up a VPN with IPsec and NAT traversal (simplified)

  1. First of all, it is determined whether the remote station even masters the necessary procedures.
  2. Then an attempt is made to recognize the NAT router on the transmission path.
  3. NAT keep alive is activated on the correct side. This ensures that the entries in the table of the NAT routers involved are not deleted due to timeouts.
  4. If necessary, NAT traversal is activated.
  5. Then the negotiation of the trust relationships begins. To do this, one end of two VPN endpoints generates a request to the target system. The target system responds and initiates the key exchange via Internet Key Exchange (IKE). Both endpoints negotiate encryption and authentication procedures. A relationship of trust is established with one another via a key or a certificate that both systems know. The digital master key is then generated for both sides.
  6. Both sides then define the encryption and authentication procedures for the data transmission. The key for data transmission is generated with the master key.
  7. The data is then exchanged and the connection established.

Problems with a firewall with NAT traversal

In order for IPsec connections with NAT traversal to be possible, the firewalls on both sides must let the encrypted data packets through. Authentication takes place via UDP port 500 or 4500. These ports usually have to be opened in the firewall.
The encrypted data packets are sent via the IP protocol 50, the ESP (Encapsulated Security Payload), or the IP protocol 51, AH (Authentication Header).
The secure transport of UDP packets is achieved through suitable measures in ISAKMP. So you can do without the connection-oriented TCP. In this way, many attack attempts have no chance.

How secure is IPsec?

VPNs based on IPsec are considered to be the most secure VPNs. However, IPsec is comparatively difficult to configure. The structure of an IPsec VPN is complex and prone to errors. For an IPsec VPN to work, many things have to work together smoothly. It's not just about technical, but also organizational things. If something does not work on the technical side, it is very difficult to find out what the problem is and you have to find a solution via trial & error.
Since the introduction of IKEv2, IPSec has caught up tremendously in terms of handling and flexibility. Another advantage is the standardization. Thanks to special processors, VPN gateways have a lot of power, can serve many parallel connections and are therefore scalable and future-proof.

In the VPN sector, IPsec is the standard that cannot be ignored. Because IPsec has been in development for a long time, it is considered very secure. Mainly because security has been improved again and again. But, with IPsec you have to deal with products from different manufacturers, which despite the standard are not or only partially compatible with one another.
In addition, given the revelations surrounding NSA intelligence activities, commercial implementations of IPsec are no longer considered trustworthy. With commercial IPsec solutions and products, the customer acquires a black box that he cannot check. So he cannot check whether the product possibly contains back doors.

Alternatives to IPsec: SSL-VPN, OpenVPN and WireGuard

An alternative to IPsec is SSL-VPN. Behind this is SSL or TLS. The most important advantage of SSL-VPN is a quasi-client-less operation. The connection can be established with any browser. However, if other applications are to use this connection, then you need some kind of gateway on the client side. For example a Java or ActiveX plug-in. Both browser extensions are often gateways for hackers because they contain security holes.

Another alternative is OpenVPN. OpenVPN is an open source solution and is therefore enjoying increasing popularity. Compared to IPsec, you have access to the source code. Compared to SSL-VPN, it can tunnel IP packets and transmit them independently of the application. OpenVPN works on the basis of OpenSSL and exists for all common operating systems.

Another alternative is WireGuard. This combines a protocol with software.

Overview: VPN technology and protocols

Other related topics:

Product recommendations

Everything you need to know about communication technology.

Communication technology primer

The communication technology primer is a book about the basics of communication technology, transmission technology, networks, radio technology, mobile communications, broadband technology and Voice over IP.

I want that!

Everything you need to know about communication technology.

Communication technology primer

The communication technology primer is a book about the basics of communication technology, transmission technology, networks, radio technology, mobile communications, broadband technology and Voice over IP.

I want that!