potential automatic mangle rules issues w.r.t. mark_in and mark_out settings

[msoltyspl]

System:

• OS: Debian 12
• Kernel version (if applicable): 6.1.67-1 (debian)
• strongSwan version(s): 5.9.8-5+deb12u1 (debian)
• Tested/confirmed with the latest version: no, but further changelogs don't mention potential fixes

Describe the bug / To Reproduce
While testing how exactly mark_in / mark_out / mark_sa_in options behave, I've found few potential issues. Consider simple child definition under a site-site tunnel. Full swanctl config (with public ips and password redacted):

p1-defs {
        version = 2
        local_addrs = 1.2.3.4
        unique = replace
        proposals = aes256-sha256-modp2048

        reauth_time = 77760s
        over_time = 8640s
        rand_time = 8640s
        dpd_delay = 60s

        local {
                id = 1.2.3.4
                auth = psk
        }
}
p2-defs {
        mode = tunnel
        hostaccess = yes
        start_action = start
        close_action = start
        dpd_action = restart

        life_time = 3600s
        rekey_time = 3240s
        rand_time = 360s

        esp_proposals = aes256-sha256-modp2048
}
connections {
        customer: p1-defs {
                remote_addrs = 4.3.2.1
                remote {
                        id = 4.3.2.1
                        auth = psk
                }
                children {
                        to_172: p2-defs {
                                policies_fwd_out = no
                                mark_in = 10
                                # mark_out = 11
                                # mark_in_sa = yes
                                local_ts = 10.217.144.0/21
                                remote_ts = 172.16.0.0/14
                        }
                }
        }
}

secrets {
        ike-sec {
                secret = 0sredacted==
                id-sec = 4.3.2.1
        }
}

1) automatic mangle rules are added only if mark_in and mark_out are both defined.

• If we add mark_in = 10 or mark_out = 11 (not both) in child's definition, no rules will be added automatically. BUT relevant xfrm state/policy will be present (for in: policy and state if mark_in_sa is set, for out: policy and state); using %unique or %unique-dir instead of a fixed value doesn't change this behavior
• If we add mark_in = 10 and mark_out = 11 in child's definition, mangle rules will be added but only for value 10 (see the next point)

2) mark_out value is missing - it seems that mark_in value is always used instead

Following the case with mark_in = 10 and mark_out = 11 the iptables-legacy -t mangle -S output shows:

-A PREROUTING -d 172.16.0.0/14 -j MARK --set-xmark 0xa/0xffffffff
-A PREROUTING -s 4.3.2.1/32 -d 1.2.3.4/32 -p esp -m esp --espspi 3250345412 -j MARK --set-xmark 0xa/0xffffffff
-A OUTPUT -d 172.16.0.0/14 -j MARK --set-xmark 0xa/0xffffffff

On the xfrm side we have:

src 1.2.3.4 dst 4.3.2.1
        proto esp spi 0x1c9b90c2 reqid 1 mode tunnel
        replay-window 0 flag af-unspec
        mark 0xb/0xffffffff 
        auth-trunc hmac(sha256) 0x0acf33350936b02e8876bd726529c0aa887020b797be6a51d7b3da566f665a3a 128
        enc cbc(aes) 0x731f459b3e44537f0cef85e9848d705933f03fc7027a23fcb59fbd57bbe94285
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 4.3.2.1 dst 1.2.3.4
        proto esp spi 0xc1bc55c4 reqid 1 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha256) 0xfc0e10729bcfe9387347087e0063a89226d6e0c6bb872fb53fa55e9c773d4005 128
        enc cbc(aes) 0xa844a7a5012798c7153c4e11229debcf968b5a5269f874a5ffcf9e560cbabe16
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

and

src 10.217.144.0/21 dst 172.16.0.0/14 
        dir out priority 382079 ptype main 
        mark 0xb/0xffffffff 
        tmpl src 1.2.3.4 dst 4.3.2.1
                proto esp spi 0x1c9b90c2 reqid 1 mode tunnel
src 172.16.0.0/14 dst 10.217.144.0/21 
        dir fwd priority 382079 ptype main 
        mark 0xa/0xffffffff 
        tmpl src 4.3.2.1 dst 1.2.3.4
                proto esp reqid 1 mode tunnel
src 172.16.0.0/14 dst 10.217.144.0/21 
        dir in priority 382079 ptype main 
        mark 0xa/0xffffffff 
        tmpl src 4.3.2.1 dst 1.2.3.4
                proto esp reqid 1 mode tunnel

Relatively to added mangle rules:

• dir out policy (and dir fwd if policies_fwd_out is set) as well as the related state requires 11 mark, but both 1st and 3rd mangle rule set 10 mark

Expected behavior
While I'm new to strongswan so obviously I might be missing something, but:

• mark_in alone should probably install relevant mangle rules
• mark_out alone should probably install relevant mangle rules
• if mark_in and mark_out differ, automatically added rules should reflect correct mark values

Additional context

Haven't tested how it behaves in context of vti devices (though they are kind of obsoleted by xfrm interfaces for ipsec purpose) - just a classic approach.

Other / unrelated
There is one more issue I noticed, but not sure if it's more a debian 12's or strongswan's one - namely debian defaults to iptables-nft api but strongswan relies on legacy api while setting marks - I had to set iptables to legacy to have everything consistent, but iptables-legacy will likely be gone at some point (as eb/arptables-legacy already is).

[tobiasbrunner]

automatic mangle rules are added only if mark_in and mark_out are both defined.

What are you referring to exactly? The default updown script does not configure any marks at all but you don't seem to have configured an updown script in your config anyway. So what exactly installs those rules? Some plugin? (It won't be connmark as that only works with transport mode, maybe forecast? If so, maybe read the docs.)

In general, if you use marks, you are on your own and have to mark packets yourself.

[msoltyspl]

I wasn't using updown script or forecast plugin (also mark= option without suffixes mentioned on the forecast page doesn't even work (anymore?) recollecting the tests I did) - or any other plugin for that matter, at least not explicitly. mark_in / mark_out are documented in swanctl.conf - these are the ones I used - I assumed it was actually installed by charon without any help of a plugin and/or its script if applicable (which otherwise would be required to handle %unique / %unique-dir). That to say ... debian by default enables quite a lot.

I'll double check the configs later and see how it behaves on the latest version (and likely on different distro).

[tobiasbrunner]

I assumed it was actually installed by charon without any help of a plugin and/or its script

On the SAs and policies, but no firewall rules are installed because of these options.