Current behaviour

An ike-group carries its Diffie-Hellman group per proposal:

set vpn ipsec ike-group EXAMPLE proposal 1 dh-group '19'
set vpn ipsec ike-group EXAMPLE proposal 2 dh-group '14'

so phase 1 can offer several groups and let the peer choose. An esp-group cannot. Its proposals accept only encryption, hash and esn, and PFS is a single value for the whole group:

set vpn ipsec esp-group EXAMPLE pfs <enable|disable|dh-groupN>
set vpn ipsec esp-group EXAMPLE proposal 1 encryption 'aes256'
set vpn ipsec esp-group EXAMPLE proposal 2 encryption 'aes128'

Every generated esp_proposals entry therefore ends with the same group, even though strongSwan accepts a different one per proposal:

esp_proposals = aes256-sha256-ecp256,aes256-sha256-modp2048

Because of this, where one remote device accepts only modp2048 for phase 2, and another accepts only ecp256, phase 1 can cover both from a single IKE group, but phase 2 needs a separate ESP group per peer -- duplicating identical encryption and hash settings solely to vary the DH group. It also rules out offering a modern group with a legacy fallback in one proposal list.

Request

Accept the DH-group on an ESP proposal, mirroring the IKE-group:

set vpn ipsec esp-group EXAMPLE proposal 1 encryption 'aes256'
set vpn ipsec esp-group EXAMPLE proposal 1 hash 'sha256'
set vpn ipsec esp-group EXAMPLE proposal 1 dh-group '19'
set vpn ipsec esp-group EXAMPLE proposal 2 encryption 'aes256'
set vpn ipsec esp-group EXAMPLE proposal 2 hash 'sha256'
set vpn ipsec esp-group EXAMPLE proposal 2 dh-group '14'