Project

General

Profile

Actions

Bug #12155

closed

Tunnels with conflicting REQID values can lead to multiple identical Child SA entries

Added by Steve Wheeler over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
IPsec
Target version:
Start date:
07/21/2021
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.01
Release Notes:
Default
Affected Version:
2.5.x
Affected Architecture:
All

Description

Testing in 21.05 and 21.09 it's possible to create IPSec tunnels with the same reqid if both VTI and Tunnel mode connections are used.

This usually doesn't seem to be an issue unless one of the tunnels fails to connect.
In the case where the VTI tunnel is down it continually tries to re-establish and each time it does so it triggers the create_child task on the other tunnel with the same reqid.
This results in numerous identical ChildSAs.

swanctl.conf:

# This file is automatically generated. Do not edit
connections {
    bypass {
        remote_addrs = 127.0.0.1
        children {
            bypasslan {
                local_ts = 192.168.241.0/24
                remote_ts = 192.168.241.0/24
                mode = pass
                start_action = trap
            }
        }
    }
    con200000 {
        fragmentation = yes
        unique = replace
        version = 2
        proposals = aes128-sha256-modp2048
        dpd_delay = 10s
        dpd_timeout = 60s
        rekey_time = 25920s
        reauth_time = 0s
        over_time = 2880s
        rand_time = 2880s
        encap = no
        mobike = no
        local_addrs = 172.21.16.246
        remote_addrs = 172.21.16.1
        local {
            id = 172.21.16.246
            auth = psk
        }
        remote {
            id = 172.21.16.1
            auth = psk
        }
        children {
            con200000 {
                dpd_action = trap
                mode = tunnel
                policies = yes
                life_time = 3600s
                rekey_time = 3240s
                rand_time = 360s
                start_action = trap
                remote_ts = 192.168.126.0/24
                local_ts = 192.168.241.0/24
                esp_proposals = aes128-sha1-modp2048
            }
        }
    }
    con1 {
        fragmentation = yes
        unique = replace
        version = 2
        proposals = aes128-sha256-modp2048
        dpd_delay = 10s
        dpd_timeout = 60s
        rekey_time = 25920s
        reauth_time = 0s
        over_time = 2880s
        rand_time = 2880s
        encap = no
        mobike = no
        local_addrs = 10.65.28.1
        remote_addrs = 10.65.28.2
        local {
            id = 10.65.28.1
            auth = psk
        }
        remote {
            id = 10.65.28.2
            auth = psk
        }
        children {
            con1 {
                dpd_action = restart
                policies = no
                life_time = 3600s
                rekey_time = 3240s
                rand_time = 360s
                start_action = start
                remote_ts = 10.66.10.2,0.0.0.0/0
                local_ts = 10.66.10.1,0.0.0.0/0
                reqid = 1
                esp_proposals = aes128gcm128-modp2048,aes128-sha256-modp2048
            }
        }
    }
    con300000 {
        fragmentation = yes
        unique = replace
        version = 2
        proposals = aes128-sha256-modp2048
        dpd_delay = 10s
        dpd_timeout = 60s
        rekey_time = 25920s
        reauth_time = 0s
        over_time = 2880s
        rand_time = 2880s
        encap = no
        mobike = no
        local_addrs = 172.21.16.246
        remote_addrs = 172.21.16.22
        local {
            id = 172.21.16.246
            auth = psk
        }
        remote {
            id = 172.21.16.22
            auth = psk
        }
        children {
            con300000 {
                dpd_action = trap
                mode = tunnel
                policies = yes
                life_time = 3600s
                rekey_time = 3240s
                rand_time = 360s
                start_action = trap
                remote_ts = 192.168.22.0/24
                local_ts = 192.168.241.0/24
                esp_proposals = aes128gcm128-modp2048,aes128-sha256-modp2048
            }
        }
    }
}

The VTI connection there uses reqid 1 but the first tunnel mode does too:

Routed Connections:
   con300000{2}:  ROUTED, TUNNEL, reqid 2
   con300000{2}:   192.168.241.0/24|/0 === 192.168.22.0/24|/0
   con200000{1}:  ROUTED, TUNNEL, reqid 1
   con200000{1}:   192.168.241.0/24|/0 === 192.168.126.0/24|/0

Despite the fact the config has it defined as reqid 2:

Routed Connections:
   con300000{2}:  ROUTED, TUNNEL, reqid 2
   con300000{2}:   192.168.241.0/24|/0 === 192.168.22.0/24|/0
   con200000{1}:  ROUTED, TUNNEL, reqid 1
   con200000{1}:   192.168.241.0/24|/0 === 192.168.126.0/24|/0


Files

Actions #1

Updated by Jim Pingle over 2 years ago

Likely related to changes made in #11794 and may also be related to #11910

Actions #2

Updated by Jim Pingle over 2 years ago

  • Assignee set to Jim Pingle

To me, I have some ideas on how to address it.

Actions #3

Updated by Jim Pingle over 2 years ago

  • Status changed from New to In Progress
Actions #4

Updated by Jim Pingle over 2 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #5

Updated by Jim Pingle over 2 years ago

  • Subject changed from Duplicate REQIDs can lead to multiple identical ChildSAs to Tunnels with conflicting REQID values can lead to multiple identical Child SA entries

Updating subject for release notes.

Actions #6

Updated by Jim Pingle over 2 years ago

  • Status changed from Feedback to Resolved

This is all working correctly now on current IPsec code.

Actions #7

Updated by Jim Pingle over 2 years ago

  • Plus Target Version changed from 21.09 to 22.01
Actions

Also available in: Atom PDF