Project

General

Profile

Feature #6324

Improve IKEv2 multiple traffic selector per SA configuration GUI

Added by Jorge Albarenque over 4 years ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
Start date:
05/06/2016
Due date:
% Done:

0%

Estimated time:

Description

On IPsec IKEv2 tunnels, by default all defined Ph2s are configured within a single SA.
This could end up with undesired (and potentially security-compromising) settings (I am aware of the option to disable the single SA behavior, it is not my point)

Example:
Ph2 1: 10.0.0.0/24 <-> 192.168.0.0/24
Ph2 2: 10.0.1.0/24 <-> 192.168.1.0/24

This translates to:
leftsubnet = 10.0.0.0/24,10.0.1.0/24
rightsubnet = 192.168.0.0/24,192.168.1.0/24

Which means that 10.0.0.0/24 and 192.168.1.0/24 now have connectivity although no Ph2 is explicitly defined for them, while on IKEv1 with the same settings they don't.

I believe this is a GUI problem. This is the way I think it should behave:
  • When IKEv2 with single SA is selected, the GUI should let you create only one Ph2 where you specify all the subnets you want, on both sides, altogether.
  • When IKEv2 with split configuration is selected, it should behave as it does right now
  • Upgrades from previous versions should default to split configuration to avoid potential security issues.

----
I also found that this (kind of) breaks the IPsec widget. If you have multiple Ph2s defined with single SA settings, the output doesn't make sense, it shows only one tunnel with single subnets and names (the real problem here is that in fact there is just one SA!). I guess this could be easily fixed with the previous proposed solution.

History

#1 Updated by Chris Buechler over 4 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from IKEv2 multiple traffic selector per SA lead to inappropiate configuration to Improve IKEv2 multiple traffic selector per SA configuration GUI
  • Target version changed from 2.3.1 to 2.3.2

The GUI should be as described so it's more clear what you're actually configuring.

#2 Updated by Chris Buechler over 4 years ago

  • Target version changed from 2.3.2 to 2.4.0

#3 Updated by Jim Thompson almost 4 years ago

  • Assignee set to Matthew Smith

#4 Updated by Renato Botelho about 3 years ago

  • Target version changed from 2.4.0 to 2.4.1

#5 Updated by Jim Pingle about 3 years ago

  • Target version changed from 2.4.1 to 2.4.2

#6 Updated by Jim Pingle about 3 years ago

  • Target version changed from 2.4.2 to 2.4.3

#7 Updated by Jim Pingle over 2 years ago

  • Target version changed from 2.4.3 to 2.4.4

#8 Updated by Steve Beaver about 2 years ago

  • Target version changed from 2.4.4 to 48

#9 Updated by Jim Pingle over 1 year ago

  • Target version changed from 48 to 2.5.0

#10 Updated by Renato Botelho about 1 month ago

  • Assignee deleted (Matthew Smith)

#11 Updated by Renato Botelho about 1 month ago

  • Target version deleted (2.5.0)

#12 Updated by Jim Pingle about 1 month ago

  • Status changed from New to Closed
  • Target version set to 2.5.0

There is no need for a separate option here. If you check Split Connections it does the right thing on 2.5.0.

It may be OK on 2.4.5 even with that option but it's less likely to be correct as the old ipsec.conf format didn't really accommodate this scenario natively.

For example, without split tunnel, you can see there is one Child SA with all networks configured:

    con1000 {
        fragmentation = yes
        unique = replace
        version = 2
        proposals = aes128gcm128-aesxcbc-curve448
        dpd_delay = 10s
        dpd_timeout = 60s
        reauth_time = 25920s
        rekey_time = 0s
        over_time = 2880s
        encap = no
        mobike = no
        local_addrs = 198.51.100.6
        remote_addrs = 198.51.100.14
        pools = 
        local {
            id = 198.51.100.6
            auth = psk
        }
        remote {
            id = 198.51.100.14
            auth = psk
        }
        children {
            con1000 {
                dpd_action = restart
                mode = tunnel
                policies = yes
                life_time = 3600
                start_action = trap
                remote_ts = 10.14.0.0/24,10.14.101.0/24
                local_ts = 10.6.0.0/24,10.6.0.0/24
                esp_proposals = aes128gcm128-curve448
            }
        }
    }

But with Split Tunnel selected, it creates multiple child SA entries with the correct network pairings:

    con {
        fragmentation = yes
        unique = replace
        version = 2
        proposals = aes128gcm128-aesxcbc-curve448
        dpd_delay = 10s
        dpd_timeout = 60s
        reauth_time = 25920s
        rekey_time = 0s
        over_time = 2880s
        encap = no
        mobike = no
        local_addrs = 198.51.100.6
        remote_addrs = 198.51.100.14
        pools = 
        local {
            id = 198.51.100.6
            auth = psk
        }
        remote {
            id = 198.51.100.14
            auth = psk
        }
        children {
            con0 {
                dpd_action = restart
                mode = tunnel
                policies = yes
                life_time = 3600
                start_action = trap
                local_ts = 10.6.0.0/24
                remote_ts = 10.14.0.0/24
                esp_proposals = aes128gcm128-curve448
            }
            con1 {
                dpd_action = restart
                mode = tunnel
                policies = yes
                life_time = 3600
                start_action = trap
                local_ts = 10.6.0.0/24
                remote_ts = 10.14.101.0/24
                esp_proposals = aes128gcm128-curve448
            }
        }
    }

Also available in: Atom PDF