1

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 1

Phase 2

phase 2

Improve this question

1 Answer 1

Reset to default
4

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 } } ... } }
Improve this answer
5
  • Thanks for answering! If I understand well, if I do not specify anything (like I have done), the keys are derived, and therefore do not contain DH groups. If I want DH groups to be included I have to specify them explicitly. I have read the doc but I am not sure to understand why this only happens when rekeying, and not when establishing the first connection. Are the used algorithms different? Commented Jun 29, 2023 at 8:45
  • 2
    Yes, they are. The configured DH groups only apply when creating CHILD_SAs with separate CREATE_CHILD_SA exchanges or during rekeying. The keys for the CHILD_SA created with IKE_AUTH are always derived from the IKE SA's key material, so no DH groups are exchanged, no matter what you configure. The only option to avoid that is creating a childless IKE SA (i.e. no CHILD_SA is created during IKE_AUTH) and then creating the first CHILD_SA with a separate CREATE_CHILD_SA exchange. In that case you'd get an error immediately if the proposals don't match. Commented Jun 29, 2023 at 9:45
  • 1
    Just added these today and worked like a charm: esp_proposals = aes128-sha256-modp2048,aes128gcm16-modp2048 (I wanted to make sure an SHA algorithm was available too). Thanks! Commented Jun 30, 2023 at 12:21
  • 1
    This way you prefer the classic and slower AES/SHA-2 combination over the more modern combined-mode AES-GCM variant. Since you have full control over the proposals on the peer, there is no reason to do that. Commented Jul 3, 2023 at 7:22
  • @ecdsa that is such a nice and well-made explanation, i wish all answers on the internet would be both this helpful and concise and correct. please keep helping people like this. Commented Sep 30, 2023 at 21:08

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.