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

1 Answer 1

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
      }
    }
    ...
  }
}
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? Jun 29, 2023 at 8:45
  • 1
    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.
    – ecdsa
    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! 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.
    – ecdsa
    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. Sep 30, 2023 at 21:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .