SG-3100 21.02 IKEv2 S2S to SG-1100 21.02
-
After some troubleshoot i got the Tunnel up and running. But there are a Problem.
Data going out on both Sides, but no incoming.I try a IPsec to any Rule, to eliminate a change in the Ruleset, as an effekt of the Upgrade. But no.
IPSec is the only VPN i use, but after the Upgdate, i run into this error, and now im out of ideeas to troubleshoot.
I use IPv4 with Dyndns and Distinguished name on both Sides.
Remote GW in P1 is the dyndns name of the Peer.SG-3100 Side:
SG-1100 Side:
SG-3100:
# This file is automatically generated. Do not edit connections { bypass { remote_addrs = 127.0.0.1 children { bypasslan { local_ts = 192.168.10.0/24 remote_ts = 192.168.10.0/24 mode = pass start_action = trap } } } con-mobile : con-mobile-defaults { # Stub to load con-mobile-defaults } con500000 { fragmentation = yes unique = replace version = 2 proposals = aes256-sha256-modp2048 dpd_delay = 10s dpd_timeout = 60s rekey_time = 25920s reauth_time = 0s over_time = 2880s rand_time = 2880s encap = no mobike = yes local_addrs = WAN-IP remote_addrs = xxx.spdns.org pools = local { id = fqdn:yyy.spdns.org auth = psk } remote { id = fqdn:xxx.spdns.org auth = psk } children { con500000 { dpd_action = trap mode = tunnel policies = yes life_time = 3600s rekey_time = 3240s rand_time = 360s start_action = trap remote_ts = 192.168.166.0/21 local_ts = 192.168.0.0/18 esp_proposals = aes256-sha256-modp2048 } } } }SG-1100
# This file is automatically generated. Do not edit connections { bypass { remote_addrs = 127.0.0.1 children { bypasslan { local_ts = 192.168.166.0/24 remote_ts = 192.168.166.0/24 mode = pass start_action = trap } } } con-mobile : con-mobile-defaults { # Stub to load con-mobile-defaults } con300000 { fragmentation = yes unique = replace version = 2 proposals = aes256-sha256-modp2048 dpd_delay = 10s dpd_timeout = 60s rekey_time = 25920s reauth_time = 0s over_time = 2880s rand_time = 2880s encap = no mobike = yes local_addrs = WAN-IP remote_addrs = yyy.spdns.org pools = local { id = fqdn:xxx.spdns.org auth = psk } remote { id = fqdn:yyy.spdns.org auth = psk } children { con300000 { dpd_action = trap mode = tunnel policies = yes life_time = 3600s rekey_time = 3240s rand_time = 360s start_action = trap remote_ts = 192.168.0.0/18 local_ts = 192.168.160.0/21 esp_proposals = aes256-sha256-modp2048 } } }Any Ideas?
-
Here are one try from Syslog.
charon[38059]: 08[NET] <1477> received packet: from 203.0.113.0[500] to 198.51.100.0[500] (464 bytes) charon[38059]: 08[ENC] <1477> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] charon[38059]: 08[CFG] <1477> looking for an IKEv2 config for 198.51.100.0...203.0.113.0 charon[38059]: 08[CFG] <1477> candidate: 198.51.100.0...0.0.0.0/0, ::/0, prio 1052 charon[38059]: 08[CFG] <1477> candidate: 198.51.100.0...Dyndns, prio 3100 charon[38059]: 08[CFG] <1477> found matching ike config: 198.51.100.0...Dyndns with prio 3100 charon[38059]: 08[IKE] <1477> 203.0.113.0 is initiating an IKE_SA charon[38059]: 08[IKE] <1477> IKE_SA (unnamed)[1477] state change: CREATED => CONNECTING charon[38059]: 08[CFG] <1477> selecting proposal: charon[38059]: 08[CFG] <1477> proposal matches charon[38059]: 08[CFG] <1477> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 charon[38059]: 08[CFG] <1477> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 charon[38059]: 08[CFG] <1477> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 charon[38059]: 08[CFG] <1477> received supported signature hash algorithms: sha256 sha384 sha512 identity charon[38059]: 08[CFG] <1477> sending supported signature hash algorithms: sha256 sha384 sha512 identity charon[38059]: 08[IKE] <1477> sending cert request for "CN=Dyndns, C=DE, ST=Place, L=Cloudtown, O=Cloudcorp" charon[38059]: 08[ENC] <1477> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ] charon[38059]: 08[NET] <1477> sending packet: from 198.51.100.0[500] to 203.0.113.0[500] (497 bytes) charon[38059]: 08[NET] <1477> received packet: from 203.0.113.0[4500] to 198.51.100.0[4500] (352 bytes) charon[38059]: 08[ENC] <1477> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ] charon[38059]: 08[IKE] <1477> received cert request for unknown ca with keyid 6d:d3:e9:ba:51:59:24:60:34:9e:b3:64:2b:28:98:13:fd:5b:24:c7 charon[38059]: 08[IKE] <1477> received 1 cert requests for an unknown ca charon[38059]: 08[CFG] <1477> looking for peer configs matching 198.51.100.0[Dyndns]...203.0.113.0[Dyndns] charon[38059]: 08[CFG] <1477> candidate "con-mobile", match: 20/1/1052 (me/other/ike) charon[38059]: 08[CFG] <1477> candidate "con500000", match: 20/20/3100 (me/other/ike) charon[38059]: 08[CFG] <con500000|1477> selected peer config 'con500000' charon[38059]: 08[IKE] <con500000|1477> authentication of 'Dyndns' with pre-shared key successful charon[38059]: 08[IKE] <con500000|1477> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding charon[38059]: 08[IKE] <con500000|1477> peer supports MOBIKE charon[38059]: 08[IKE] <con500000|1477> got additional MOBIKE peer address: 192.168.100.10 charon[38059]: 08[IKE] <con500000|1477> got additional MOBIKE peer address: 192.168.166.1 charon[38059]: 08[IKE] <con500000|1477> authentication of 'Dyndns' (myself) with pre-shared key charon[38059]: 08[IKE] <con500000|1477> successfully created shared key MAC charon[38059]: 08[IKE] <con500000|1477> IKE_SA con500000[1477] established between 198.51.100.0[Dyndns]...203.0.113.0[Dyndns] charon[38059]: 08[IKE] <con500000|1477> IKE_SA con500000[1477] state change: CONNECTING => ESTABLISHED charon[38059]: 08[IKE] <con500000|1477> scheduling rekeying in 23520s charon[38059]: 08[IKE] <con500000|1477> maximum IKE_SA lifetime 26400s charon[38059]: 08[CFG] <con500000|1477> looking for a child config for 192.168.0.0/18|/0 === 192.168.160.0/21|/0 charon[38059]: 08[CFG] <con500000|1477> proposing traffic selectors for us: charon[38059]: 08[CFG] <con500000|1477> 192.168.0.0/18|/0 charon[38059]: 08[CFG] <con500000|1477> proposing traffic selectors for other: charon[38059]: 08[CFG] <con500000|1477> 192.168.160.0/21|/0 charon[38059]: 08[CFG] <con500000|1477> candidate "con500000" with prio 5+5 charon[38059]: 08[CFG] <con500000|1477> found matching child config "con500000" with prio 10 charon[38059]: 08[CFG] <con500000|1477> selecting proposal: charon[38059]: 08[CFG] <con500000|1477> proposal matches charon[38059]: 08[CFG] <con500000|1477> received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ charon[38059]: 08[CFG] <con500000|1477> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ charon[38059]: 08[CFG] <con500000|1477> selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ charon[38059]: 08[CFG] <con500000|1477> selecting traffic selectors for us: charon[38059]: 08[CFG] <con500000|1477> config: 192.168.0.0/18|/0, received: 192.168.0.0/18|/0 => match: 192.168.0.0/18|/0 charon[38059]: 08[CFG] <con500000|1477> selecting traffic selectors for other: charon[38059]: 08[CFG] <con500000|1477> config: 192.168.160.0/21|/0, received: 192.168.160.0/21|/0 => match: 192.168.160.0/21|/0 charon[38059]: 08[CHD] <con500000|1477> CHILD_SA con500000{20} state change: CREATED => INSTALLING charon[38059]: 08[CHD] <con500000|1477> using AES_CBC for encryption charon[38059]: 08[CHD] <con500000|1477> using HMAC_SHA2_256_128 for integrity charon[38059]: 08[CHD] <con500000|1477> adding inbound ESP SA charon[38059]: 08[CHD] <con500000|1477> SPI 0xceb40bab, src 203.0.113.0 dst 198.51.100.0 charon[38059]: 08[CHD] <con500000|1477> adding outbound ESP SA charon[38059]: 08[CHD] <con500000|1477> SPI 0xcc34b838, src 198.51.100.0 dst 203.0.113.0 charon[38059]: 08[IKE] <con500000|1477> CHILD_SA con500000{20} established with SPIs ceb40bab_i cc34b838_o and TS 192.168.0.0/18|/0 === 192.168.160.0/21|/0 charon[38059]: 08[CHD] <con500000|1477> CHILD_SA con500000{20} state change: INSTALLING => INSTALLED charon[38059]: 08[ENC] <con500000|1477> generating IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ] charon[38059]: 08[NET] <con500000|1477> sending packet: from 198.51.100.0[4500] to 203.0.113.0[4500] (336 bytes) charon[38059]: 10[NET] <con500000|1477> received packet: from 203.0.113.0[4500] to 198.51.100.0[4500] (80 bytes) charon[38059]: 10[ENC] <con500000|1477> parsed INFORMATIONAL request 2 [ N(AUTH_FAILED) ] charon[38059]: 10[IKE] <con500000|1477> received DELETE for IKE_SA con500000[1477] charon[38059]: 10[IKE] <con500000|1477> deleting IKE_SA con500000[1477] between 198.51.100.0[Dyndns]...203.0.113.0[Dyndns] charon[38059]: 10[IKE] <con500000|1477> IKE_SA con500000[1477] state change: ESTABLISHED => DELETING charon[38059]: 10[IKE] <con500000|1477> IKE_SA deleted charon[38059]: 10[ENC] <con500000|1477> generating INFORMATIONAL response 2 [ ] charon[38059]: 10[NET] <con500000|1477> sending packet: from 198.51.100.0[4500] to 203.0.113.0[4500] (80 bytes) charon[38059]: 10[IKE] <con500000|1477> IKE_SA con500000[1477] state change: DELETING => DESTROYING charon[38059]: 10[CHD] <con500000|1477> CHILD_SA con500000{20} state change: INSTALLED => DESTROYING -
Now both Upgraded to 02/21/2 but, AES_CBC don't work.
SG-3100 works fine, but the SG-1100 has a problem with AES_CBC.Tunnel go up, but no data coming in. If I switch the P1 / P2 from AES_CBC to AES_GCM, data flow is normal, but on SG-3100 no longer hardware crypto offloading.
The tunnel between SG-3100 and a x86 test VM works fine with AES_CBC, therefore I assume that the fault is in the SG-1100. The SafeXcel crypto driver is active, but switching it off, no difference.
Can anyone confirm this behavior?
-
Resolved
The SafeXcel Crypto driver was the issue.
After deactivating and Reboot, the SG-1100 works as expected.
At pfsense 21.02 this Driver isn't nessary for the crypto support.IPsec Performance ist very nice, AES-CBC-256 SHA256 DH14, round about 40% CPU at 50MBit/s.
-
Now I have found following system log messages on my SG-3100:
cesa1: TDMA descriptors pool exhaused. Consider increasing CESA_TDMA_DESCRIPTORS.
Somebody saw something similar?
Could be related to that here:
Bug 226682 - ARMADA38X: Running out of CESA TDMA descriptors for disk I/O on GELI SSD
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.