IPsec relies on encrypting and hashing data packets for confidentiality and authentication. For that modern cryptography is being used.
IPFire allows to select a variety of ciphers, hashing algorithms and key exchange algorithms to accommodate for various use-cases and interoperability to other vendors.
By default, a set of highly secure and commonly used algorithms are being used. You should only change those if you know what you are doing as it can substantially weaken the security of your VPN.
Advanced Settings
The settings discussed here can be changed individually for each connection under "Advanced Settings" when editing a connection.
What to use?
The default settings are selected to provide very good security and maximise compatibility to other vendors without sacrificing security. In some scenarios it might be necessary to select a weaker encryption. Those that are considered weak or broken are marked as such in the web user interface and should not be used.
Ciphers
A cipher is being used to encrypt and decrypt packets. It has the biggest performance impact out of all algorithms being used and should be carefully selected.
AES is the most popular algorithm and enabled by default. Most hardware has acceleration for AES which makes it also the fastest algorithm for most users.
AES, like most ciphers, can be used in different ciphers modes and with different key lengths. The longer the key, the stronger the encryption, but also the slower the encryption/decryption. GCM is the preferred cipher mode as it already comes with built-in integrity over the weaker, but more common, CBC mode.
If your hardware does not have hardware acceleration for AES, a good alternative is ChaCha20-Poly1305 which is considered equally strong. It is a stream cipher instead of a block cipher (like AES, DES, ...) and therefore faster to implement in software.
Camellia is another block cipher with very similar performance and strength to AES.
Deprecated/Weak/Broken Ciphers
3DES used to be the most common and only cipher before AES became its successor. It is considered broken but remains supported in IPFire for compatibility with very old equipment from other vendors.
Integrity
Integrity is important to authenticate the sender of a data packet. A VPN does not only encrypt data so that nobody else can read it, it also needs to make sure that nobody can inject any data into the tunnel. This is done using hashing algorithms with HMACs.
The most famous algorithms are SHA-1 and MD5 which are both considered weakened now. It is recommended to use SHA-2 or even better, a cipher that has authentication built-in (e.g. AES in GCM mode or ChaCha20-Poly1305).
Key Exchange
Before the tunnel can transmit any data, it needs to generate keys for the used ciphers. To create a secure channel between both peers, a key exchange is performed.
The most famous key exchange algorithm is the Diffie-Hellman key exchange which is based on RSA. In IPFire, you can select the key length by selecting the one you want (MODP-4096, MODP-2048, ...). The longer the key the better the security, but also the longer the handshake will take. Anything below and including MODP-1024 is considered cryptographically broken.
A better alternative than RSA is using elliptic curve cryptography (ECC) which requires shorter keys and is therefore faster. Since this is fairly modern cryptography, adoption is still not very good. Some equipment only (if even) supports the NIST variants.
Perfect Forward Secrecy
If a VPN would be negotiated with one static key which would be used for forever, an attacker could capture some traffic and use brute-force to find the key and decrypt it. They could then eavesdrop on all communication for forever.
To combat that, Perfect Forward Secrecy (PFS) renegotiates the tunnel in regular intervals so that brute-forcing keys becomes an operation that is too expensive.
It is recommended to enable PFS in all scenarios.
Cipher Negotiation
When two peers connect to establish a VPN tunnel, they will need to negotiate which cipher to use. The peer that initiates the connection makes a proposal of what cipher suites it wants to use and the other peer selects the best one out of those.
IPFire by default uses the settings selected on the "Advanced Settings" page. It can also accept anything it supports by unchecking IKE+ESP: Use only proposed settings. This is only recommended to be used for debugging as it might downgrade the security of the VPN tunnel as it converges to the weakest cipher.