Project

General

Profile

Actions

Feature #12397

closed

Distinguish between policy-based and route-based entries on IPsec status SPD tab

Added by Jim Pingle 8 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
Very Low
Assignee:
Category:
IPsec
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.01
Release Notes:
Default

Description

The IPsec Status SPD tab at status_ipsec_spd.php prints information from the security policy database and it currently does not distinguish between policy-based entries (tunnel mode) and route-based entries (VTI mode) which can make it confusing for users as some entries appear to conflict when they actually do not.

This output is from a tunnel mode entry:

10.14.1.0/24[any] 10.8.0.0/24[any] any
        out ipsec
        esp/tunnel/198.51.100.14-198.51.100.8/unique:16
        created: Sep 22 08:33:50 2021  lastused: Sep 22 08:33:50 2021
        lifetime: 9223372036854775807(s) validtime: 0(s)
        spid=156 seq=33 pid=38035 scope=global
        refcnt=1

Note the scope=global

This is an entry from a VTI mode tunnel:

0.0.0.0/0[any] 0.0.0.0/0[any] any
        out ipsec
        esp/tunnel/198.51.100.14-198.51.100.21/unique:5029
        spid=138 seq=3 pid=38035 scope=ifnet ifname=ipsec29
        refcnt=1

Note it has scope=ifnet and also lists the specific VTI interface (ipsec29)

Additionally, at some point the output of the command changed and the reqid is not being properly parsed. This output is from ipsec_dump_spd(), note that reqid should just be the number:

  [69]=>
  array(7) {
    ["srcid"]=>
    string(4) "::/0" 
    ["dstid"]=>
    string(4) "::/0" 
    ["dir"]=>
    string(3) "out" 
    ["proto"]=>
    string(3) "esp" 
    ["src"]=>
    string(13) "198.51.100.14" 
    ["dst"]=>
    string(13) "198.51.100.21" 
    ["reqid"]=>
    string(10) "nique:5029" 
  }

The reqid string is not currently used so it's not a bug yet, but needs fixed since we should display that on the page.

What should happen is:

  • Fix reqid parsing in ipsec_dump_spd()
  • ipsec_dump_spd() should parse and include data for scope and (if present), ifname
  • status_ipsec_spd.php should include columns for reqid and scope as the first two columns. If scope is ifnet, it should display the ifname instead of ifnet.
  • Ideally the output should sort by reqid so that in/out entries for tunnels are grouped.
  • Consider changing the order of "Tunnel Endpoints" and their arrow to match the "Direction" column as it seems confusing to have the arrows pointing different directions on inbound entries
  • Bonus points for displaying P2 descr and linking to P2 edit but that may clutter the page
Actions #1

Updated by Jim Pingle 7 months ago

  • Status changed from New to In Progress
  • Target version changed from CE-Next to 2.6.0
Actions #2

Updated by Jim Pingle 7 months ago

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

Fix committed, will be in images soon.

Actions #3

Updated by Max Leighton 6 months ago

It seems this has made it into images, because I test and see some of this functionality.

Tested in:

2.6.0-DEVELOPMENT (amd64)
built on Sat Nov 27 06:23:02 UTC 2021
FreeBSD 12.3-PRERELEASE

The status_ipsec_spd.php page now shows a column for Mode which distinguishes between tunnel and VTI modes. In VTI mode, I see the name of the ipsec interface in this column as well.
The direction arrows are pointing the same way, so there is no confusion with different directions for inbound.

There isn't a column for reqid or scope, and they seem to be sorted by direction instead of being sorted by reqid.

If that is what is expected, this can be resolved.

Actions #4

Updated by Jim Pingle 6 months ago

  • Status changed from Feedback to Resolved

The scope value is there it's just not called scope, that's what you see differentiating between VTI and tunnel mode in the Mode column.

The reqid parsing is fixed, but it's not in the GUI output. I left that out since it wasn't very useful. We only set reqid static for VTI, and in other cases the dynamic reqid won't match the one in the P2 so it's more confusing than anything.

Since it's all as it should be, it can be closed.

Actions

Also available in: Atom PDF