IPSec tunnel works until rekeying, then gets NO_PROPOSAL_CHOSEN

Question

Context

I have set up a site-to-site IPSec tunnel between a Raspberry Pi located in an office and a pfSense firewall in the cloud. I am using Strongswan for the Raspberry Pi side.

Issue

My tunnel establishes and works fine for a while, but when it has to rekey itself, the negotiation fails.

Is there something obvious I am missing?

Logs (Raspberry side)

Initial connection

raspberrypi charon[2422]: 09[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
raspberrypi charon[2422]: 09[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ
raspberrypi charon[2422]: 09[IKE] CHILD_SA net-net{1} established with SPIs c3eaa3c7_i c944ab71_o and TS RASPI_NET/24 === PFSENSE_NET/16
raspberrypi charon[2422]: 09[IKE] CHILD_SA net-net{1} established with SPIs c3eaa3c7_i c944ab71_o and TS RASPI_NET/24 === PFSENSE_NET/16

Rekeying (that's where it goes wrong)

raspberrypi charon[507]: 11[NET] received packet: from PFSENSE_IP[4500] to RASPI_LOCAL_IP[4500] (80 bytes)
raspberrypi charon[507]: 11[ENC] parsed INFORMATIONAL request 153 [ D ]
raspberrypi charon[507]: 11[IKE] received DELETE for ESP CHILD_SA with SPI ce632e5b
raspberrypi charon[507]: 11[IKE] closing CHILD_SA net-net{1} with SPIs ccc38dd0_i (94042284 bytes) ce632e5b_o (5169556 bytes) and TS RASPI_NET/24 === PFSENSE_NET/16
raspberrypi charon[507]: 11[IKE] closing CHILD_SA net-net{1} with SPIs ccc38dd0_i (94042284 bytes) ce632e5b_o (5169556 bytes) and TS RASPI_NET/24 === PFSENSE_NET/16
raspberrypi charon[507]: 11[IKE] sending DELETE for ESP CHILD_SA with SPI ccc38dd0
raspberrypi charon[507]: 11[IKE] CHILD_SA closed
raspberrypi charon[507]: 11[ENC] generating INFORMATIONAL response 153 [ D ]
raspberrypi charon[507]: 11[NET] sending packet: from RASPI_LOCAL_IP[4500] to PFSENSE_IP[4500] (80 bytes)
raspberrypi charon[507]: 12[NET] received packet: from PFSENSE_IP[4500] to RASPI_LOCAL_IP[4500] (80 bytes)
raspberrypi charon[507]: 12[ENC] parsed INFORMATIONAL request 154 [ ]
raspberrypi charon[507]: 12[ENC] generating INFORMATIONAL response 154 [ ]
raspberrypi charon[507]: 12[NET] sending packet: from RASPI_LOCAL_IP[4500] to PFSENSE_IP[4500] (80 bytes)
raspberrypi charon[507]: 06[NET] received packet: from PFSENSE_IP[4500] to RASPI_LOCAL_IP[4500] (640 bytes)
raspberrypi charon[507]: 06[ENC] parsed CREATE_CHILD_SA request 155 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
raspberrypi charon[507]: 06[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
raspberrypi charon[507]: 06[CFG] received proposals: ESP:AES_GCM_16_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_12_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_8_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_16_128/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
raspberrypi charon[507]: 06[CFG] configured proposals: ESP:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/NO_EXT_SEQ
raspberrypi charon[507]: 06[IKE] no acceptable proposal found
raspberrypi charon[507]: 06[IKE] failed to establish CHILD_SA, keeping IKE_SA
raspberrypi charon[507]: 06[ENC] generating CREATE_CHILD_SA response 155 [ N(NO_PROP) ]
raspberrypi charon[507]: 06[NET] sending packet: from RASPI_LOCAL_IP[4500] to PFSENSE_IP[4500] (80 bytes)
raspberrypi charon[507]: 01[JOB] CHILD_SA ESP/0xccc38dd0/RASPI_LOCAL_IP not found for rekey
raspberrypi charon[507]: 08[JOB] CHILD_SA ESP/0xccc38dd0/RASPI_LOCAL_IP not found for rekey

What I have tried to do

If I SSH to the Raspberry and run ipsec restart, the tunnel establishes again and works fine until the next rekeying.

I am having trouble understanding why the proposals do not match on rekeying if they do for the initial connection. Furthermore, I did ask for different algorithms inside of my swanctl configuration file.

I tried changing the configuration both sides, but it seems that the issue is always located on the side of the Raspberry (by the way, the pfSense is responder-only).

Configuration files

/etc/swanctl/conf.d/myfile.conf

connections {
  gw-gw {
    local_addrs = RASPI_LAN_IP
    remote_addrs = PFSENSE_IP
    local {
      auth = psk
      id = RASPI_PUBLIC_IP
    }
    remote {
      auth = psk
      id = PFSENSE_IP
    }
    children {
      net-net {
        local_ts = RASPI_NET/24
        remote_ts = PFSENSE_NET/16
        start_action = start
        dpd_action = restart
      }
    }
    version = 2
    dpd_delay = 60
    mobike = no
    proposals = aes128-sha256-modp2048,default
  }
}

secrets {
  ike-1 {
    id-1 = RASPI_PUBLIC_IP
    id-2 = PFSENSE_IP
    secret = "MYPSK"
  }
}

pfSense

Phase 1

Phase 2

Answer 1

Furthermore, I did ask for different algorithms inside of my swanctl configuration file.

You have only done so for IKE, not for ESP/IPsec.

I am having trouble understanding why the proposals do not match on rekeying if they do for the initial connection.

That's a common misconception with IKEv2. The proposal that's negotiated for the CHILD_SA (IPsec SA) created during IKE_AUTH doesn't contain any key exchange methods (e.g. DH groups) because the keys are always derived from the key material of the IKE_SA.

Therefore, if one peer (in your case pfSense) configures one or more DH groups (and doesn't include NONE as well) and the other (strongSwan) does not, this won't be a problem until that CHILD_SA is actually rekeyed and the key exchange methods have to be negotiated. The strongSwan doc on rekeying CHILD_SAs describes this as well.

So what you want to configure on the strongSwan client is e.g. this:

connections {
  gw-gw {
    ...
    children {
      net-net {
        ...
        esp_proposals = aes128gcm16-modp2048
      }
    }
    ...
  }
}