IPSec Was Interrupted Because the ACLs Were Too General

Publication Date:  2015-07-03 Views:  352 Downloads:  0
Issue Description
Network Topology:

The firewall served as the hub and all branches (spokes) established IPSec tunnels with the firewall.




Symptom:

The networks connected through the IPSec tunnels were interrupted.
Handling Process
The IPSec services had been running for 1 year before the interruption. The maintenance personnel logged in to the firewall at the hub and displayed the IPSec information.

The IPSec SA information of one node was as follows:


HRP_M[MZ_GS_FW_01] display ipsec sa remote 60.165.x1.y1
02:00:40  2012/07/03
  -----------------------------
  ipsec policy name: "pl"
  sequence number: 1
  mode: template
  vpn: public
  -----------------------------
    connection id: 173545
    rule number: 4294967295
    encapsulation mode: tunnel
    tunnel local : 61.178.x2.y2    tunnel remote: 60.165.x1.y1
    flow      source: 10.112.0.0/255.255.0.0 0/0
    flow destination: 172.16.0.0/255.255.0.0 0/0

    [inbound ESP SAs] 
      spi: 2368886412 (0x8d32568c)
      vpn: public  said: 9722  cpuid: 0x0000
      proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5
      sa remaining key duration (bytes/sec): 1887363600/28181
      max received sequence-number: 1211
      udp encapsulation used for nat traversal: Y

    [outbound ESP SAs] 
      spi: 4097 (0x1001)
      vpn: public  said: 9723  cpuid: 0x0000
      proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5
      sa remaining key duration (bytes/sec): 1887331008/28181
      max sent sequence-number: 1641
      udp encapsulation used for nat traversal: Y


Compared with other IPSec SAs:

  -----------------------------
  ipsec policy name: "pl"
  sequence number: 1
  mode: template
  vpn: public
  -----------------------------
    connection id: 365
    rule number: 4294967295
    encapsulation mode: tunnel
    tunnel local : 61.178.x2.y2    tunnel remote: 118.182.x3.y3
    flow      source: 10.112.0.0/255.255.0.0 0/0
    flow destination: 172.16.2.80/255.255.255.240 0/0

    [inbound ESP SAs] 
      spi: 2098881415 (0x7d1a6387)
      vpn: public  said: 314  cpuid: 0x0000
      proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5
      sa remaining key duration (bytes/sec): 1887436800/26573
      max received sequence-number: 1
      udp encapsulation used for nat traversal: Y

    [outbound ESP SAs] 
      spi: 4286 (0x10be)
      vpn: public  said: 315  cpuid: 0x0000
      proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5
      sa remaining key duration (bytes/sec): 1887436800/26573
      max sent sequence-number: 1
      udp encapsulation used for nat traversal: Y


The subnet mask of the data flow protected by the tunnel was 16-bit, which was more general than those protected by other tunnels. To forward traffic to a branch, the hub node must look for a tunnel based on the data flow definition.



As shown in the previous figure, if a branch sends traffic through tunnel 2, the traffic can be received and decrypted. When the return traffic arrives, the device must also look for a tunnel based on the data flow definition. The flow for tunnel 1 is more general than others. Therefore, the traffic matches tunnel 1. As a result, the branch connected to tunnel 2 is interrupted.

Usually, the data flows of branches are subsets of the data flow defined on the hub node. Meanwhile, the ACLs on devices at branches must also be properly configured. The data flows of the branches cannot overlap. Otherwise, the traffic of some branches may not be correctly forwarded.
Root Cause
The new peer devices used the same IPSec configuration, and the data flow defined in the ACL was 72.16.0.0/16, which was more general than the data flows for other tunnels, causing the service interruption. 
Solution
Modify the ACL configurations on peer devices to ensure that the IPSec data flows do not overlap and use a 28-bit mask. 

END