IPsec profiles
With IPsec profiles, you can specify the phase 1 and phase 2 IKE (Internet Key Exchange) parameters for establishing IPsec and L2TP tunnels between two firewalls.
Note
With Sophos Firewall version 18.5 and earlier, IPsec profiles were called IPsec policies.
The default profiles support some common scenarios. You can also configure custom profiles.
- To specify the phase 1 and phase 2 security parameters, go to Profiles > IPsec profiles.
- To clone an IPsec profile, click Clone .
-
Click Show additional properties above the name column to select additional settings for the list view. You can drag and drop the properties to rearrange the list view.
Tip
You may need the IPsec profile's properties to troubleshoot IPsec tunnels in connections and failover groups.
-
You can apply IPsec profiles to the following configurations:
- Remote access VPN > IPsec and L2TP
- Site-to-site VPN > IPsec
You can create IPsec tunnels between two Sophos Firewall devices or between a Sophos Firewall and a third-party firewall.
IKE and SAs
Internet Key Exchange: IKE helps you set up a Security Association (SA) for shared, secure IPsec communication. IKE enables both firewalls to generate the same symmetric key privately. The firewalls use the symmetric key to encrypt and decrypt IP packets.
You can specify IKEv1 and IKEv2 protocols for key exchange. Aggressive mode isn't available for IKEv2.
Security Association: The firewalls establish an SA based on the IKE negotiation with each other and maintain a list of SAs until the corresponding tunnels remain connected. SAs contain the source and destination IP addresses, encryption and authentication algorithms, key life, and the SPI.
Security Parameter Index: SPI is a unique local identifier each firewall generates. The SPI refers to each SA, identifying the tunnel to which a packet belongs.
Phase 1 parameters
IKE SA: The firewall initiating the tunnel sends its phase 1 parameters, and the peers negotiate the parameters they'll use. These parameters include the encryption algorithm, hash (data authentication) algorithm, key length, DH group, peer authentication method, and key life.
In main mode, IKE SAs use six messages and encrypted authentication. In aggressive mode, they use three messages and unencrypted authentication.
When the peers come to an agreement, each has a common IKE SA policy for setting up the phase 1 tunnel and a Security Parameter Index (SPI), the unique identifier for each tunnel. The peers then perform a Diffie-Hellman (DH) key exchange and locally generate the shared secret key.
Peer authentication: The peers then authenticate each other using the authentication type you've specified in IPsec.
The local and remote interfaces or gateways you've specified authenticate each other using one of the following options based on the connection type:
-
IPsec connections: Preshared key, digital certificate, or RSA key.
Additionally, you can use local and remote IDs, such as DNS name, IP address, or email address, for the peers to authenticate each other if you use preshared or RSA keys. If you use digital certificates, you can use DER ASN1 DN (x.509) for the local and remote IDs.
-
L2TP: Preshared key or digital certificate. IKEv2 isn't available for L2TP tunnels.
You can specify the tunnel's local and remote peers, peer authentication mechanism, and additional authentication parameters, such as local and remote IDs, on IPsec and L2TP.
The phase 1 negotiation is complete with the peers authenticating each other, and the firewalls establish a two-way phase 1 tunnel between the peers. The firewalls use the phase 1 tunnel to negotiate the phase 2 parameters. If phase 1 negotiations fail, the firewalls can't negotiate phase 2 parameters.
Phase 2 parameters
Sophos Firewall uses Encapsulating Security Payload (ESP) protocol in tunnel mode, offering data integrity and data origin authentication, and anti-replay service.
IPsec SAs: The firewalls use the phase 1 tunnel to negotiate phase 2 SAs, including the encryption algorithm, authentication algorithm, key life, and optionally, DH key exchange with Perfect Forward Secrecy (PFS). When the peers agree on these parameters, they establish an IPsec SA, identifying it with a local SPI, the unique identifier.
Perfect Forward Secrecy: You can use PFS to generate new shared secret keys for the phase 2 tunnels.
Traffic selectors: If the traffic selectors, that is, the subnets or hosts (example: servers), match on both firewalls, the firewalls establish a tunnel between each subnet pair (or host pair). Phase 2 SAs encrypt and authenticate the data traffic between the corresponding hosts and subnets.
Since phase 2 SAs and tunnels are established between each subnet and host pair, their number is a multiple of the local and remote subnets (or hosts) you specify. See the following example:
Local subnets: Subnet L1 and subnet L2
Remote subnets: Subnet R3 and subnet R4
In this example, the firewalls establish the following four phase 2 tunnels:
- L1 to R3
- L1 to R4
- L2 to R3
- L2 to R4
Incoming packets are then decapsulated and decrypted. After the matching firewall rule applies the security policies, traffic is sent to the destination. Outgoing packets are encapsulated and encrypted after applying the matching firewall rule.
XAuth: Additionally, you can specify user and group authentication using XAuth (Extended Authentication) if you configure the VPN in client-server mode. You can configure the firewall in the central location in server mode. XAuth uses your current authentication mechanism, such as AD, RADIUS, or LDAP, to authenticate users after the phase 1 exchange. You then configure the remote firewall in client mode with a username and password to authenticate with the firewall that's in server mode.
You can select the traffic selectors and XAuth settings on IPsec and L2TP.
Encryption, authentication, shared secret, and key life
Encryption: You can use encryption algorithms, such as AES. These are symmetric keys, encrypting and decrypting packet data.
Authentication: You can use authentication algorithms, such as SHA2 to authenticate data, that is, ensure its integrity. Sophos Firewall uses HMAC (Hash-based Message Authentication Code), using the authentication algorithm to compute a hash value based on the packets and the shared secret key. It sends the hash value with the packets. The remote firewall recalculates the hash value from the message and its shared secret key to confirm that the hash values are identical.
You can select a combination of up to three encryption and authentication algorithms to make sure you have a common set. Sophos Firewall uses the most secure combination to negotiate with the remote firewall.
Diffie-Hellman: DH key exchange enables the firewalls to securely exchange the symmetric key over an insecure channel, such as the internet. Each firewall generates a public-private key pair and shares the public key with the remote firewall over the insecure channel. Each firewall then privately computes a common shared secret based on the local private key and the remote firewall's public key. The private keys and the shared secret key aren't exchanged. The firewalls use the shared secret key to derive the symmetric key independently.
Perfect Forward Secrecy: PFS derives the phase 2 keys independent from the phase 1 keys. When you specify PFS, the firewalls generate a new key for each phase 2 tunnel with a new DH key exchange for each. Alternatively, you can use the phase 1 DH groups to generate a new key or choose not to use a new DH key exchange for phase 2. If you don't select a DH group, the firewalls use the phase 1 secret key for phase 2 exchanges. PFS is the most secure, generating an independent shared key with a different DH group from the phase 1 group for each phase 2 tunnel.
Key life: You can allow the firewalls to start the negotiation process automatically before the current shared secret key expires. Either of the firewalls can start the renegotiation. If you turn off rekeying on the local firewall, it can still respond to a rekeying request from the remote firewall. If you turn it off on both, the connection uses the same key during its lifetime.
The key life and rekey settings you specify in phase 1 are also used for phase 2 rekeying. Depending on PFS, the negotiation uses the regenerated phase 1 key or generates a new key for phase 2.
You can specify the maximum number of retries if a key exchange doesn't succeed. Alternatively, you can choose not to have any retries.
Tip
Sophos Firewall supports only time-based rekeying. To configure an IPsec connection between Sophos Firewall and a third-party firewall, select time-based rekeying on the third-party firewall.
NAT traversal
Sophos Firewall automatically detects NAT devices in the IPsec path and performs NAT traversal (NAT-T) by default.
NAT-T enables firewalls to establish IPsec connections when one or both firewalls are behind a NAT device, such as a router. The router may be your network router or an ISP router.
Sophos Firewall devices perform NAT-T for IKEv1 and IKEv2 and remote access, policy-based, and route-based IPsec VPNs.
Note
If you're using a third-party firewall at one end, make sure you've selected their NAT-T setting. You don't need to select it on Sophos Firewall devices.
How to configure
You can't see a NAT-T setting on Sophos Firewall devices since it's performed automatically when the firewalls detect a NAT device in the IPsec VPN path.
To establish IPsec connections when Sophos Firewall devices are behind a NAT device, configure the following settings on the NAT device:
- Create a DNAT rule to translate incoming IPsec VPN traffic from the public IP address to the private IP address, which is the listening interface on Sophos Firewall.
-
Allow the following services:
- UDP port 500: Phase 1 IKE exchanges use this service. Phase 2 exchanges use this service when there's no NAT device.
- IP protocol 50: ESP packets use this service when there's no NAT device.
- UDP port 4500: When the firewalls detect a NAT device, they use this service for subsequent phase 1 negotiations, phase 2 IKE exchanges, and ESP packets.
See IPsec VPN with firewall behind a router.
Why encapsulate IPsec packets with UDP
Firewalls detect the presence of a NAT device during the phase 1 IKE exchange.
No NAT device: If the firewalls don’t detect a NAT device on the IPsec path, they continue the phase 1 exchange and conduct the phase 2 IKE exchange over UDP port 500. Additionally, they send the data (ESP) packets using IP protocol 50.
NAT device on the IPsec path: If the firewalls detect a NAT device, both firewalls agree to NAT-T during the phase 1 IKE negotiation. They conduct subsequent phase 1 negotiations over UDP port 4500. Additionally, they use UDP encapsulation to wrap the phase 2 IKE exchange and ESP data packets in IP headers and send them over UDP 4500.
The NAT device translates the IP address in this header. The remote firewall strips the header and processes the original IPsec packet.
NAT devices translate the private source IP address to a public address. Additionally, they may translate the port if Port Address Translation (PAT) is configured. ESP, a layer 3 protocol, doesn't carry the layer 4 port information. UDP encapsulation with 4500 as the source and destination port enables the firewalls to identify the packets. In the absence of UDP encapsulation, the remote firewall discards the IPsec packets it receives from a NAT device.
More resources