Introduction

When AFM is placed between two IPSec peers, so that it handles the IPSec traffic, we must create specific firewall rules in order to allow IPSec tunnel to be set up and data traffic can be exchanged between clients. The number of firewall rules just as its direction depends on non specifically AFM IPSec configuration. This article explain how these settings can affect to AFM working in passthrough IPSec mode.

How to

There are two different configuration options that will define how many AFM firewall rules will be needed in our passthrough firewall:

• DB key ipsec.lookupspi.
• IPSec ALG profile (ipsecalg).

Combinations between these options will make AFM behaves in different ways.

Note that there are more IPSec configuration options availables for Big-IP but in this article I only describe those that can affect how AFM firewall handles IPSec traffic when it is sited between two IPSec peers. As a brief summary of both:

• DB key ipsec.lookupspi defines if we want to take into account SPI in order to forward packet to one or other TMM. In other words depending on the value for this variable Big-IP will use SPI for load balancing traffic among TMMs. This variable will cause flow ports to be 0 instead of using the SPI from the ESP packet, you can confirm this in the log examples below. Also a side-effect of enabling ipsec.lookupspi is that TMM will create two flows per ESP session, one for each direction, this is the reason why this DB key affects to AFM.
• IPSecALG profile is configured inside the virtual server and it is integrated into AFM and CGNAT so it helps AFM to handle connections. The IPSecALG profile provides network address translation and flow management for Internet Protocol Security (IPSec) and Internet Key Exchange (IKE) flows. I will not describe pros/cons of this ALG in this document, please read specific articles to find out if this ALG really fits into your environment.

In this section I will detail with examples how these two options can affect to AFM.

It is important to note that we will need as many AFM firewall rules as flows for IPSec are expected to exist in the flow connections table, no flow will be created if packet is not allowed by AFM.

Attending to diagram below, when there is not hit in any flow table (HW or SW) packet must be allowed by a firewall rule (and of course by other security filters), if there is a match in a firewall rule that allows the packet then an entry is added to specific flow table. So if Big-IP expects two flows for handling IPSec connections then we need two firewall rules to allow them.

^{*Source: K31591013}

In this article I am going to refer only to below firewall rules:

velascoOUT_ESP {
    action accept-decisively
    ip-protocol esp
    log yes
    rule-number 9
    destination {
        addresses {
            2.2.2.2/32 { }
        }
    }
    source {
        addresses {
            1.1.1.1/32 { }
        }
    }
}
velascoOUT500 {
    action accept-decisively
    ip-protocol udp
    log yes
    rule-number 11
    destination {
        addresses {
            2.2.2.2/32 { }
        }
        ports {
            isakmp { }
        }
    }
    source {
        addresses {
            1.1.1.1/32 { }
        }
    }
}
velascoIN_ESP {
    action accept-decisively
    ip-protocol esp
    log yes
    rule-number 10
    destination {
        addresses {
            1.1.1.1/32 { }
        }
    }
    source {
        addresses {
            2.2.2.2/32 { }
        }
    }
}
velascoIN500 {
    action accept-decisively
    ip-protocol udp
    log yes
    rule-number 12
    destination {
        addresses {
            1.1.1.1/32 { }
        }
        ports {
            isakmp { }
        }
    }
    source {
        addresses {
            2.2.2.2/32 { }
        }
    }
}

And the following virtual servers:

ltm virtual VS-FWD {
   destination 0.0.0.0:any
   mask any
   profiles {
       fastL4 { }
   }
   security-log-profiles {
       varLogLtm
   }
   serverssl-use-sni disabled
   source 0.0.0.0/0
   translate-address disabled
   translate-port disabled
}

Note: Logs shown in tests can vary depending on what fields you are configured to log. I only chose the required ones that help to explain this article.

ipsec.lookupspi enabled

We could say that this DB key breaks firewall stateful inspection ability for ESP. This means that by enabling this DB key (default) two flows are created for ESP traffic, one per direction. Therefore we need to configure three firewall rules in order to allow IPSec tunnel to work as expected (in this example rules velascoOUT_ESP, velascoOUT500 and velascoIN_ESP). By doing this we will get below flow connections table :

Sys::Connections
1.1.1.1:500 2.2.2.2:500 1.1.1.1:500 2.2.2.2:500 udp 6 (tmm: 0) none none
2.2.2.2:44    1.1.1.1:47625 2.2.2.2:44    1.1.1.1:47625 esp 5 (tmm: 1) none none
1.1.1.1:2762 2.2.2.2:33901  1.1.1.1:2762 2.2.2.2:33901  esp 5 (tmm: 1) none none
Total records returned: 3

As you can see these flows match with AFM rules configured.

If instead enabling the above three commented firewall rules we would only enable firewall rules named 'velascoOUT500' and 'velascoOUT_ESP' then return traffic from remote peer would not be allowed by any firewall rule and this traffic would be dropped, therefore incoming ESP flow would not be created:

In this situation by running a ping from internal client to external client we would see how ICMP reply is rejected by default virtual firewall rule:

Aug 31 04:23:10 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Global","/Common/global-firewall-rules","1.1.1.1","2.2.2.2","500","500","/Common/INTERNAL","UDP","0","1.1.1.1","2.2.2.2","500","500","/Common/EXTERNAL","UDP","0","Enforced","/Common/GLOBAL-FW-POLICY","velascoOUT500","","Accept decisively","","","","0000565666c4e0a4"
 
Aug 31 04:23:10 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Global","/Common/global-firewall-rules","1.1.1.1","2.2.2.2","3196","14741","/Common/INTERNAL","ESP","0","1.1.1.1","2.2.2.2","3196","14741","/Common/EXTERNAL","ESP","0","Enforced","/Common/GLOBAL-FW-POLICY","velascoOUT_ESP","","Accept decisively","","","","000156576ebc4564"
 
Aug 31 04:23:10 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Virtual Server","/Common/VS-FWD","2.2.2.2","1.1.1.1","3057","3998","/Common/EXTERNAL","ESP","0","","","","","","","","Enforced","","(Default)","","Reject","Policy","","","0000000000000000"

And only one ESP flow is created. In this situation IPSec tunnel would be set-up but no return traffic would be allowed:

# tmsh sho net ipsec | grep State
  Tunnel State : up
  Tunnel State : up
 
Sys::Connections
1.1.1.1:500 2.2.2.2:500 1.1.1.1:500 2.2.2.2:500 udp 29 (tmm: 0) none none
1.1.1.1:3196 2.2.2.2:14741 1.1.1.1:3196 2.2.2.2:14741 esp 0 (tmm: 1) none none
Total records returned: 2

ipsec.lookupspi disabled

In this case only one flow is created for ESP what it ease the firewall configuration:

Sys::Connections
1.1.1.1:any 2.2.2.2:any 1.1.1.1:any 2.2.2.2:any esp 39 (tmm: 0) none none
1.1.1.1:500 2.2.2.2:500 1.1.1.1:500 2.2.2.2:500 udp 26 (tmm: 0) none none
Total records returned: 2

So we only need one AFM firewall rule for ESP and another one for ISAMKP ('velascoOUT500' and 'velascoOUT_ESP').

With these two rules if we repeat the ICMP request we will see only one match in firewall rule since return traffic, ICMP reply, will match ESP flow shown above:

Aug 30 08:09:28 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Global","/Common/global-firewall-rules","1.1.1.1","2.2.2.2","500","500","/Common/INTERNAL","UDP","0","1.1.1.1","2.2.2.2","500","500","/Common/EXTERNAL","UDP","0","Enforced","/Common/GLOBAL-FW-POLICY","velascoOUT500","","Accept decisively","00005656596f3a50"
 
Aug 30 08:09:28 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Global","/Common/global-firewall-rules","1.1.1.1","2.2.2.2","0","0","/Common/INTERNAL","ESP","0","1.1.1.1","2.2.2.2","0","0","/Common/EXTERNAL","ESP","0","Enforced","/Common/GLOBAL-FW-POLICY","velascoOUT_ESP","","Accept decisively","00005656596f3a04"

Note that for both provided examples only one internal peer can start the IPSec tunnel since we are only allowing ISAKMP in one direction. If we try to initiate the IPSec from the remote peer then traffic will be dropped. But once local peer (1.1.1.1 in this case) establishes the IPSec tunnel clients behind both IPSec peers will be able to send traffic through the tunnel with no issues:

Sys::Connections
Total records returned: 0
 
Aug 31 03:40:37 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Virtual Server","/Common/VS-FWD","2.2.2.2","1.1.1.1","500","500","/Common/EXTERNAL","UDP","0","Enforced","(Default)","Reject","Policy","0000000000000000"

IPSec ALG attached

We can enable IPSec ALG by attaching IPSecALG profile to an Standard virtual server. This is one of the two main restrictions for this ALG and it causes some disadvantages.

Since you will not be able to assign this ALG profile to FastL4 virtual servers, you will not be able to accelerate flows using ePVA chip.

Also Standard virtual servers make use of LTM pools by default what it could be a problem in some environments. For example, if our requirement is that both IPSec peers must be able to initiate the IPSec tunnel then we will need to create two standard virtual servers each with a pool where the pool member is the remote IPSec.

This has another handicap, what if our set of remote IPSec peers are not previously known?

In order to avoid this we can force Standard virtual server to route traffic based on destination IP without using a pool by disabling translate-address configuration option, although this could be not possible in some environments (K04116537).

Another important restriction for this ALG is that it is designed for accommodating IPsec endpoints that do not support RFC3947 (Negotiation of NAT-Traversal in the IKE). In other words this profile is not designed to handle UDP port 4500 connections. If IPSec peers are going to use NAT-T then you will need to create another virtual server in order to allow this traffic. Please check K97997482 for more information. It is important to take this into account because we could have an environment without NAT-T being used in any IPSec tunnel and suddenly at some point some IPSec traffic start to fail just because one intermediate device starts to NAT connections, and hence IPSec peers change to NAT-T mode. If we forgot ipsecalg limitations troubleshooting could not be trivial. In other words, when playing with this ALG we rely on its possible changes over time (improvements, bugs or limitations).

Just as a note aside for IPSec ALG, note that if we delete the IPSec flows from AFM flow table we will see below log in /var/log/ltm, this is expected:

Aug 31 05:31:16 VELASCO info tmm[17718]: "IPSEC_TEARDOWN""1.1.1.1:0""1.1.1.1:0""AH""1598875123247""1953384""<null>"
Aug 31 05:31:16 VELASCO info tmm[17718]: "IKE_TEARDOWN""1.1.1.1:500""1.1.1.1:500""1598875123247""1953384""<null>"
Aug 31 05:31:16 VELASCO info tmm[17718]: "IPSEC_TEARDOWN""1.1.1.1:0""1.1.1.1:0""ESP""1598875123247""1953384""<null>"

ALG + ipsec.lookupspi enabled

By having this DB key enable we only need one firewall rule allowing ISAMP traffic from the IPSec peer that will initiate the tunnel, ALG profile will handle the rest.

This is the configuration which requires less number of firewall rules. For an environment where only firewall rule 'velascoOUT500' is enabled the tunnel will work without problem:

Aug 31 04:49:38 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Global","/Common/global-firewall-rules","1.1.1.1","2.2.2.2","500","500","/Common/INTERNAL","UDP","0","1.1.1.1","2.2.2.2","500","500","/Common/EXTERNAL","UDP","0","Enforced","/Common/GLOBAL-FW-POLICY","velascoOUT500","","Accept decisively","","","","0000565668a0f0ef"
 
Sys::Connections
1.1.1.1:any 2.2.2.2:any 1.1.1.1:any 2.2.2.2:500 ah  8 (tmm: 0) none none
1.1.1.1:any 2.2.2.2:any 1.1.1.1:any 2.2.2.2:500 esp 8 (tmm: 0) none none
1.1.1.1:500 2.2.2.2:500 1.1.1.1:500 2.2.2.2:500 udp 8 (tmm: 0) none none
2.2.2.2:2371 1.1.1.1:8606 2.2.2.2:2371 1.1.1.1:8606 esp 8 (tmm: 0) none none
1.1.1.1:190 2.2.2.2:49286 1.1.1.1:190 2.2.2.2:49286 esp 8 (tmm: 0) none none
Total records returned: 5

Note that due to the way the IPSec profile works under the hoods, the ALG creates by default flows for both possible encapsulation modes, AH and ESP, and not only the one you have configured in your IPSec config. In above case I have configured ESP but AFM creates outgoing flow for both, since only ESP got response only ESP incoming flow is added to the connflow table.

ALG + ipsec.lookupspi disabled

In this situation ALG is not able by itself of handling all connections, so it behaves similarly as described at ipsec.lookupspidisabled but with worst results. As in the test case without IPSec ALG profile, response traffic will be dropped because ESP return packets are not allowed by any firewall rule, so no flow will be created, but in this case even creating specifically a firewall rule for allowing this traffic will not make it work. IPSec tunnel will be up, but that's all (check K93873214 for more details, article is still valid). This is because IPSec ALG relies on DB key ipsec.lookupspi to work.:

Sys::Connections
1.1.1.1:any 2.2.2.2:any 1.1.1.1:any 2.2.2.2:500 ah  24 (tmm: 0) none none
1.1.1.1:any 2.2.2.2:any 1.1.1.1:any 2.2.2.2:500 esp 24 (tmm: 0) none none
1.1.1.1:500 2.2.2.2:500 1.1.1.1:500 2.2.2.2:500 udp 24 (tmm: 0) none none
Total records returned: 3

Summary

In this section you can check at a glance all the AFM firewall rule requirements attending to the IPSec LTM configuration you want to deploy.

ipsec.lookupspi

For environments where IPSec ALG profile is NOT used below diagram shows the possible options:

IPSec ALG

For environments where IPSec ALG profile IS used below diagram shows your choices: