Overlapping reqid allocated for old- and newstyle IPsec (also overlapping with automatic allocation)

cluck commented 5 months ago

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

When configuring both newstyle IPsec connections and oldstyle IPsec tunnel settings, independent connections are allocated identical reqid (in /usr/local/etc/swanctl/swanctl.conf).

The newstyle connections have no explicit reqid set, thus implicit reqids are allocated, starting from 1 by default.
The oldstyle connections have explicit reqid configured, allocated from 1 upwards.

To Reproduce

Use two OPNsense instances and create one oldstyle and one newstyle VPN between them. See attached configuration snippets to import for convenience.

Output of established connections:

$ swanctl -l
Connections:
e43911c7-c8a2-41ab-b406-79225d8fe9f4: #5, ESTABLISHED, IKEv2, 1dbe47c51a97041c_i d075581a7ecaff17_r*
  local  'host16' @ 192.0.2.16[4500]
  remote 'host17' @ 192.0.2.17[4500]
  AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
  established 3s ago, rekeying in 13983s
  c58ea3fd-3edb-4430-9f09-88d0f2e376be: #3, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA2_256_128
--------------------------------------------^
    installed 3s ago, rekeying in 3332s, expires in 3957s
    in  cd80c5e3,      0 bytes,     0 packets
    out c7f99c1a,      0 bytes,     0 packets
    local  10.16.2.0/24
    remote 10.17.2.0/24
con1: #4, ESTABLISHED, IKEv2, 732c13f6fef7410a_i 2e2ac7c468c7d55a_r*
  local  '192.0.2.16' @ 192.0.2.16[4500]
  remote '192.0.2.17' @ 192.0.2.17[4500]
  AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
  established 3s ago, rekeying in 14069s
  con1: #4, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
------------^
    installed 3s ago, rekeying in 3374s, expires in 3957s
    in  c608c8ae,      0 bytes,     0 packets
    out cd0f736a,      0 bytes,     0 packets
    local  10.16.1.0/24
    remote 10.17.1.0/24

Expected behavior

I would expect explicit reqid allocation to not collide with implicit allocation. I would also expect oldstyle and newstyle IPsec to now have colliding reqid.

Workaround

As a workaround, which works around both issues, I set charon.reqid_base in a custom configuration snippet:

$ cat /usr/local/etc/strongswan.opnsense.d/fix-reqid.conf
charon {
    reqid_base = 8192
}

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 24.1.6-amd64

cluck commented 5 months ago

Similar reported issues:

6302 (closed without fix)
7122 (labelled support)

This needs improvement as it won't be noticed by operators of the GUI: https://github.com/opnsense/docs/commit/dab8d004d97a452078b25d87c82fa0b70abba612

cluck commented 3 weeks ago

I am confused about the "support" label: what is it's objective and what does it mean for this issue?

opnsense / core

Overlapping reqid allocated for old- and newstyle IPsec (also overlapping with automatic allocation) #7416

6302 (closed without fix)

7122 (labelled support)