Routing policies, outgoing filter policies and IPsec VPN configuration

When an SNS firewall is used as a VPN gateway, routes and filter rules must be properly configured to guarantee the confidentiality and integrity of traffic. Four functions are closely linked:

• Routing,

• Filter policy,

• NAT before IPsec,

• IPsec policy.

When IPsec VPN tunnels are implemented, a route must be configured to reach the remote networks that can be accessed through tunnels. Otherwise, the packet will be deleted during routing and will not reach the IPsec encryption stage.

To prevent data leaks, it is advisable to configure a route with a fictitious IP as the gateway on its local loopback, e.g. a host object with 127.42.42.42 as its address. This technique is also called blackhole filtering.

After the IPsec policy is applied, the routing policy will be evaluated again based on the encrypted packet. However, if there is an error on the IPsec policy, the packets will be destroyed instead of leaving in plaintext.

The order of the routing, filtering, NAT before IPsec and IPsec policy functions shown on the image below, directly impacts the confidentiality of traffic. This sequence is only part of the packet’s full path in the SNS firewall. Indeed, when it is encrypted, the packet will then be processed by filtering, NAT after IPsec and routing.

The most specific rules must be defined for the filter policy and the least specific for the IPsec policy.

 

Functional components

 

WARNING
Ideally, separate SNS firewalls should be implemented to dissociate encryption functions from the filtering of traffic in plaintext and encrypted traffic.

The examples below illustrate the advantage of the previous recommendation. They apply to the SNS firewall as a VPN gateway for outgoing traffic on the local LAN and to a remote LAN through an IPsec VPN tunnel set up with a remote VPN gateway. The architecture is represented on the image below.

 

Architecture

 

Each example provides the configuration of the SNS functional components that a network packet passes through (Functional components image). The network packet enters with a specific source and destination. Packets pass through these functions in this sequence:

• Pre-routing,

• Filtering,

• NAT before IPsec,

• IPsec policy.

The end result is described by the outgoing packet, whether it is:

• Encrypted,

• Plaintext (not encrypted),

• Destroyed,

• Filtered.

A black, red or green color code is applied to represent respectively: the primary path, error (plaintext), and behavior after correction.

For each example, three cases (C) are represented:

C1	Configuration that does not comply with the recommendation, the input parameters are nominal.
C2	Issues relating to the previous configuration are highlighted. Some entries or the configuration will be modified. Changes are shown in red.
C3	Suggested configuration to avoid reproducing the earlier issue. Changes are shown in red.

Constantly active IPsec policy

The example represented in the image below illustrates the need for remote IPsec networks to use a route to the local loopback. In the case of C1, packets first go into the routing table, which contains a valid route to the remote LAN (the default route in the example). The packets then go through the filter policy, which accepts the packets, which then move on to the IPsec policy, which encapsulates, encrypts and protects the integrity of the traffic. The source and destination of encrypted packets are different from those of plaintext packets. The destination of the encrypted packet in particular is the remote VPN gateway. Packets go through the routing table again (the route to the remote LAN is not used, only the route towards the remote VPN gateway is used), which contains a valid route to the IPsec gateway (default route). Outgoing packets are encrypted.

 

Constantly active IPsec policy, route to the local loopback

 

Next, the IPsec policy switches from enabled (C1) to disabled (C2). It can be disabled permanently or for a transitional period, which occurs when the IPsec policy is disabled then enabled again.

In the case of C2, packets first go into the routing table, which contains a valid route to the remote LAN. The packets then go through the filter policy, which accepts the packets. However, since no IPsec policy was defined, the packets are sent in plaintext at the next hop, i.e., the default gateway defined in the routing table. Data is leaked.

The solution shown in C3 consists of defining a route to the local loopback (taking a particular IP address makes it easier to keep the configuration, e.g., 127.42.42.42), also known as black hole filtering. In the absence of an IPsec policy, the SNS firewall will destroy the packet instead of sending it to the default gateway.

R41+ | SNS-SMC | Do not use the default route
If all the networks used are known, the default route is not recommended. Choose explicit routes instead to reach all remote peers. In this way, only the packets that have an explicitly defined route will be able to leave in plaintext.

WARNING
Address ranges must be chosen to prevent confusion between red and black networks as described in architecture image, and to facilitate the creation of routes.

Filter rules always more specific than the IPsec policy

The example represented in as in the image below illustrates the need to specify a filter policy that is always more specific than the IPsec policy. In the case of C1, the filter policy is defined in /24 while the IPsec policy is in /32. The administrator wants, for example, to define a cryptographic context per IP address pair, while keeping a shared filter policy. At the beginning, only two hosts communicate with each other. Packets pass through the filter policy, then the IPsec policy, and are sent encrypted.

 

Filter rules always more specific than the IPsec policy

 

In the case of C2, an appliance is added to the network, but the SNS firewall configuration does not change. Packets to this new IP address are accepted by the filter policy and not selected by the IPsec policy, so they are sent in plaintext. Data is leaked.

The correction implemented in C3 consists of setting a filter policy in /32 and an IPsec policy in /24. The filter policy is therefore always more restrictive than the IPsec policy. Packets will either be filtered or Encrypt, but cannot be sent in plaintext.

When an IPsec policy is used to interconnect networks, it must not be modified too often and the networks used can be extended, unlike a filter policy, which can be very specific and modified frequently .

NAT before IPsec rules included in the IPsec policy

The example represented in the image below illustrates the need to specify NAT before IPsec rules included in the IPsec policy. In the case of C1, a NAT before IPsec rule is applied. Its result is a selection criterion in the IPsec policy. Modifying this rule will directly affect the confidentiality of data. Packets are accepted by the filter policy then modified by the NAT before IPsec rule and then selected by the IPsec policy. They are encrypted on the way out.

 

NAT before IPsec rules included in the IPsec policy

 

In the case of C2, a NAT before IPsec rule is modified. Packets are accepted by the filter policy then modified by the NAT before IPsec rule. As the outgoing IP address is modified, the IPsec policy will no longer select it, so packets are sent in plaintext. Data is leaked.

The solution shown in C3 consists of defining an IPsec policy broader than the NAT rule used. Even if the outgoing IP address is modified, the IPsec policy will still select the packet, which will be encrypted by the SNS firewall.

INFORMATION
The NAT rule must go together with an ARP publication if the address(es) used do(es) not belong to the SNS firewall’s interfaces.

Filter rules always more specific than NAT before IPsec rules

The example represented in the image below illustrates the need to specify filter rules that are always more specific than NAT before IPsec rules. In C1, the source network of the NAT before IPsec rule is in /25 while the source network in the filter rule is in /24. Packets originate from a source address that is included in both /24 and /25. Packets are accepted by the filter rule then the NAT before IPsec rule is applied, and finally the IPsec policy. Outgoing packets are encrypted.

 

Filter rules always more specific than NAT before IPsec rules

 

In C2, the source IP address is included in /24 but not in /25. Packets are accepted by the filter policy and not selected by NAT before IPsec rules. The IPsec policy is not applied, so packets are sent in plaintext. Data is leaked.

The correction implemented in C3 consists of setting a filter policy in /32. The filter policy is therefore more restrictive than the NAT before IPsec rules. Packets will either be filtered or encrypted.