With WireGuard, the cryptographic algorithms used are firmly anchored in the protocol, whereas with IPSec they are negotiated dynamically between the remote sites each time a connection is established. WireGuard is therefore simpler and faster, but IPSec allows step-by-step evolution and adaptation of the cryptography without having to fundamentally change the protocol. Older remote sites can remain connected via IPSec without any changes, allowing a slow, uninterrupted migration. Should the cryptographic algorithms defined in WireGuard one day no longer be considered sufficient, a hard break and a fundamentally new and incompatible protocol would be necessary.
IPSec is set to UDP port 500 for the connection setup. However, this port can be used flexibly for all connections, connection and protocol variants and several individual keys. This makes it easier to set up port forwarding, for example. WireGuard requires a separate port number for each private key. However, this port number can be freely selected.
By negotiating the protocol variants and algorithms, IPSec requires the exchange of several packets to establish a connection. This is therefore slower and requires larger UDP packets which may then have to be fragmented. WireGuard uses just one packet to establish a connection and this packet is small enough that it does not normally need to be fragmented. This increases the speed and functionality of WireGuard on limited Internet access.
As IPSec establishes a unique connection at the beginning and this normally only needs to be repeated over a period of several hours, the private keys required for authentication can be stored on external devices such as smartcards or USB tokens and never needs to be stored in the RAM of the client PC. This enables full multi-factor authentication with real read protection of the private keys. Even if the private key is stored on the client PC, IPSec clients usually encrypt it with a special password and request this before each connection is established. For the transmission of private keys to clients, most clients use PKCS#12, which protects the key for transmission with a password.
With WireGuard, the handshake with authentication takes place approximately every 2 minutes. It is not intended or realistic to store the private keys on external hardware for this purpose. The established exchange format for WireGuard configurations (“wg-quick format”) does not provide for the private key to be secured with a password. Most clients for WireGuard also do not provide for this to be added subsequently for the local storage of the keys and rely on any functions provided by the operating system.
IPSec uses standardized X.509 certificates and can therefore be easily connected to existing certification authorities and infrastructure. WireGuard uses its own key format, which is used exclusively for WireGuard.
The X.509 certificates used with IPSec have an expiration date that is set when they are created. This allows regular verification of authorization and the use of appropriate cryptographic standards to be defined and ensured from the outset. A regular change of keys limits the damage in the event of key loss that is not immediately detected or access by unauthorized persons. The keys used with WireGuard have no expiration date and the user must implement their own processes to ensure that the above points are checked at the correct time interval. For WireGuard keys, the Intra2net system displays the time at which a key was created or imported to support such processes.
With IPSec, the source and target networks to be connected are compared at the beginning when the connection is established between the remote sites. A connection is only established if they are exactly identical. Configuration errors are therefore immediately apparent when the connection is established and it is ensured on an additional level to the firewall that only the desired networks are connected. However, as each pair of source and target networks must be configured individually, configuration can be more complex.
With WireGuard, the IP networks are not part of the connection setup and are not compared between the two sides. A configuration error at this point is therefore not noticed when the connection is established and may first have to be identified by comparing the settings and protocols on both sides. However, it is easier to create and adapt the configuration as no pairs of source and target networks need to be defined.
IPSec does not have an established file format for the exchange of configuration data. The common formats PEM and PKCS#12 are used for authentication. However, the details of the certificates required by different remote sites, such as Subject-CN vs. SubjectAlternativeName, chain of trust or CRL, differ. This complicates the configuration of IPSec connections between different remote sites and requires detailed knowledge of the respective products from the administrators. The lack of a common exchange format for configuration data makes communication more difficult, especially if the remote sites are operated and managed by different organizations.
WireGuard has established a manufacturer-independent format for the exchange of configuration data and keys. This can at least be imported by most WireGuard clients and simplifies the configuration considerably.
In most cases, IPSec uses AES to encrypt the user data. Although this is more computationally intensive, it is supported by many CPU models with special hardware acceleration. The ChaCha20-Poly1305 from WireGuard is simpler, but is implemented purely in software. Which of the two methods ultimately delivers the higher data throughput is therefore heavily dependent on the specific CPU, mainboard and network cards used and is difficult to predict without specific tests.
IPSec has been established on the market for many years and therefore has broad, manufacturer-independent and mutually compatible support for router and firewall products. WireGuard is a newer VPN standard and is therefore not yet so widespread, especially with firewall products. However, where WireGuard is supported, we have not yet observed any compatibility problems between different implementations. Here it is helpful to have one cryptography standard only.
Free client programs are available for WireGuard for all common platforms. For IPSec, only paid client programs are recommended for some platforms.
The conclusion is that both standards have their individual strengths and justification for their existence. It should be decided individually for each application which of the two protocols is more suitable.