Bug in pool definition routes all traffic to a roadwarrior tunnel?

[zviratko]

Hi,
i am in the process of converting my ipsec.conf configuration to swanctl

In the process I made an error and defined an IP pool like this

pools {
        pool-users {
                addrs = 10.64.24.127/28
                dns = 10.64.10.1
        }
}

Which looks like this when loaded

# swanctl --list-pools
pool-users          10.64.24.127                          0 / 0 / 0

get-pools reply {
  pool-users {
    base = 10.64.24.127
    size = 0
    online = 0
    offline = 0
    leases {
    }
  }
}

This is what the connection using it looks like when defined

  child: TUNNEL, rekeying every 3600s or 17179869184 bytes, dpd action is restart
    local:  0.0.0.0/0 ::/0
    remote: dynamic

This connection is for roadwarrior scenario, the client is macOS.
"dynamic" is usually substituted for the assigned VIP from the pool in this case, but because I defined the pool wrong, it ended up doing this instead:

Apr 11 20:12:42 n6 ipsec[2735]: 06[IKE] scheduling rekeying in 13886s
Apr 11 20:12:42 n6 ipsec[2735]: 06[IKE] maximum IKE_SA lifetime 15326s
Apr 11 20:12:42 n6 ipsec[2735]: 06[IKE] peer requested virtual IP %any
Apr 11 20:12:42 n6 ipsec[2735]: 06[IKE] assigning virtual IP %any to peer 'someclient@somewhere'
Apr 11 20:12:42 n6 ipsec[2735]: 06[IKE] peer requested virtual IP %any6
Apr 11 20:12:42 n6 ipsec[2735]: 06[IKE] assigning virtual IP %any6 to peer 'someclient@somewhere'
Apr 11 20:12:42 n6 ipsec[2735]: 06[CFG] selected proposal: ESP:CHACHA20_POLY1305/NO_EXT_SEQ
Apr 11 20:12:42 n6 charon[2735]: 06[IKE] CHILD_SA child{1} established with SPIs cb32453e_i 0e938c4b_o and TS 10.0.0.0/8 1.2.3.4/28 (actually a public IP block) === 0.0.0.0/0 ::/0

Notice the remote traffic selector of 0.0.0.0/0. Ouch.

The result was absolutely catastrophic. I'm not sure how catastrophic exactly, because the machine immediatelly stopped responding on network (to anything except maybe ARP) and somehow also took the KVM console with it or at least the console wasn't responding. When I retried to investigate, it resumed after probably the child tunnel timed-out but I can't see anything except that log above and "kernel: IPv4: martian source" messages that make no sense (I am quite careful about routing and filtering). I am not keen on trying that again in case I'm causing some sort of network loop, which would explain the general unresponsiveness of everything...

Did I just stumble upon a massive bug caused by IP Pool running out of addresses in general, or was it caused by defining a pool with 0 addresses in the first place?
Also, I'd excpect the subnet to be interpreted as "10.64.24.112/28" (this is the first software I've seen that doesn't). I'll probably just file a bug for this rightaway.

Should I file a bug? I was about to but maybe someone here can comment first. It's possible I'm doing something wrong with swanctl but I don't think so, because once I fixed the subnet to 10.64.24.128/28 it started working just fine.
Anybody willing to replicate it in their setup?
And for the record: Ubuntu 22.04.4, strongswan 5.9.5-2ubuntu2.2

[tobiasbrunner]

Also, I'd excpect the subnet to be interpreted as "10.64.24.112/28" (this is the first software I've seen that doesn't).

That's because strongSwan allows configuring the base address from where the assignment to clients starts (e.g. to keep the lower addresses reserved for manual assignment to internal hosts like the server itself).

By configuring the "broadcast" address of that subnet as base, you inadvertently configured an empty pool. Which is basically like configuring rightsourceip=%config in the old ipsec.conf backend (i.e. you found a way to configure this in swanctl.conf, which doesn't officially support this feature). There is actually a unit test that points out this behavior, but I guess it might not be expected by users.

Such an empty pool will confirm whatever IP address the client proposes (the base address is ignored), which obviously only works correctly if the client actually requests a specific IP address. If it doesn't, i.e. requests 0.0.0.0, then that will be confirmed by the pool and in turn results in a remote traffic selector of 0.0.0.0/0. However, that's not because we're actually setting %any on the traffic selector, which would explicitly result in that traffic selector and not 0.0.0.0/32 (of course that wouldn't make sense either), but because we specifically avoid setting %any on traffic selectors to make them larger. Of course, since the traffic selector is already 0.0.0.0/0, because the client expects an unknown virtual IP address, that has the same result.

So it's not really a bug (or at least not unknown behavior), but could be surprising to users.

[zviratko]

Thanks a lot for a comprehensive explanation.

That's because strongSwan allows configuring the base address from where the assignment to clients starts (e.g. to keep the lower addresses reserved for manual assignment to internal hosts like the server itself).

Ok, makes sense, though I'd call it unorthodox. But it should be documented at least :-)

So it's not really a bug (or at least not unknown behavior), but could be surprising to users.

I wouldn't call this behaviour surprising, I'd still call it catastrophic. The only reason someone would set it is by mistake, and the results were not good at all. I'm not that familiar with how people use pools, but if someone were to provide something like a "sliding subnet" (similiar to what you said the use case for subnet calculation is) by a script or from SQL, then this could easily happen just because a pool is exhausted.

[tobiasbrunner]

But it should be documented at least :-)

Yeah, interesting that it isn't. It's been supported since the beginning as the code never enforced that the base address is the actual network ID of the subnet. However, only since 5.2.2 is the size of the pool correctly calculated if it isn't.

The only reason someone would set it is by mistake, and the results were not good at all.

And since configuring an empty pool doesn't really make sense, we should probably reject such configs. I've pushed a commit that does so to the 2205-mem-pool branch.

[zviratko]

Thank you on behalf of all absent minded admins :-)

Btw I'm assuming you are receiving security@strongswan.org, I stumbled upon another "issue"...