Project

General

Profile

Issue #3560

PSK tunnel working - Cert fails with fragmention errors

Added by alex johnson about 2 months ago. Updated about 1 month ago.

Status:
Feedback
Priority:
Normal
Category:
configuration
Affected version:
5.6.2
Resolution:

Description

Hi,
We have an issue with Swanct 5.6.2. We have a vpn which works on psk however as soon as we switch to Foundation level certificate it fails.
We have other tunnels working on Foundation and it uses the same certficates without a problem.
Please see the config as below – I’ve changed the cert details slightly to hide the customer and removed the IPs.
The remote site is using a checkpoint (again it works on PSK).
If I remove the remote cert I still get the same error (and leave out PSK as well).
customerx {
local_addrs = x.x.x.x
remote_addrs = x.x.x.x

local {
auth = pubkey
certs = vpnrsa.production.onecloud.us.cloud.07-08-2021.pem
}
remote {
auth = pubkey
id = "OID.2.5.4.15 = Government Entity, serialNumber = Government Entity, OID.1.3.6.1.4.1.311.60.2.1.3 = GB, C = GB, ST = customerx, L = Tempchester, STREET = *, OU = IT Services, O = customerx Council, CN = customerxusvpn.customerxcouncil.gov.uk"
}
children {
customerx-azure {
local_ts = 172.26.0.85/32
remote_ts = 172.21.251.0/24
rekey_bytes = 4608000
esp_proposals = aes256-sha256-modp2048 #phase 2
start_action = trap
dpd_action = restart
rekey_time = 1h
}
}
#version = 2
version = 1
mobike = no
reauth_time = 1440
proposals = aes256-sha256-modp2048 #phase 1
encap = yes #turned off
#fragmentation = force
}
}

The debug log file shows

root@s00C-vpn-uks-01:/etc/swanctl/conf.d# sudo swanctl -i customerx -c customerx-azure -l 3
[MGR] checkout IKE_SA by config
[MGR] found existing IKE_SA 24149 with a 'customerx' config
[IKE] queueing QUICK_MODE task
[IKE] delaying task initiation, ID_PROT exchange in progress
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[IKE] sending retransmit 3 of request message ID 0, seq 3
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1184 bytes)
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[IKE] sending keep alive to x.x.x.x4500
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[IKE] sending retransmit 4 of request message ID 0, seq 3
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1184 bytes)
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[IKE] sending keep alive to x.x.x.x4500
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[IKE] sending keep alive to x.x.x.x4500
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[IKE] sending retransmit 5 of request message ID 0, seq 3
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
[NET] sending packet: from 172.26.0.854500 to x.x.x.x4500 (1184 bytes)
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[IKE] sending keep alive to x.x.x.x4500
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[IKE] sending keep alive to x.x.x.x4500
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[IKE] sending keep alive to x.x.x.x4500
[MGR] checkin IKE_SA customerx24149
[MGR] checkin of IKE_SA successful
[IKE] giving up after 5 retransmits
[IKE] establishing IKE_SA failed, peer not responding
[MGR] checkin and destroy IKE_SA customerx24149
[IKE] IKE_SA customerx24149 state change: CONNECTING => DESTROYING
initiate failed: establishing CHILD_SA 'customerx-azure' failed
root@s00C-vpn-uks-01:/etc/swanctl/conf.d#

charon log

root@s00C-vpn-uks-01:/etc/swanctl/conf.d# tail -f /var/log/charon_debug.log | grep customerx
Mon, 2020-09-07 15:27 09[CFG] vici initiate 'customerx-azure'
Mon, 2020-09-07 15:27 12[IKE] <customerx|24158> queueing QUICK_MODE task
Mon, 2020-09-07 15:27 12[IKE] <customerx|24158> delaying task initiation, ID_PROT exchange in progress
Mon, 2020-09-07 15:27 05[IKE] <customerx|24158> sending keep alive to x.x.x.x4500
Mon, 2020-09-07 15:28 05[IKE] <customerx|24158> sending retransmit 4 of request message ID 0, seq 3
Mon, 2020-09-07 15:28 05[NET] <customerx|24158> sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
Mon, 2020-09-07 15:28 05[NET] <customerx|24158> sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
Mon, 2020-09-07 15:28 05[NET] <customerx|24158> sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
Mon, 2020-09-07 15:28 05[NET] <customerx|24158> sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
Mon, 2020-09-07 15:28 05[NET] <customerx|24158> sending packet: from 172.26.0.854500 to x.x.x.x4500 (1152 bytes)
Mon, 2020-09-07 15:28 11[IKE] <customerx|24158> sending keep alive to x.x.x.x4500
Mon, 2020-09-07 15:28 07[IKE] <customerx|24158> sending keep alive to x.x.x.x4500
Mon, 2020-09-07 15:28 11[IKE] <customerx|24158> sending retransmit 5 of request message ID 0, seq 3
Mon, 2020-09-07 15:28 11[NET] <customerx|24158> sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
Mon, 2020-09-07 15:28 11[NET] <customerx|24158> sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
Mon, 2020-09-07 15:28 11[NET] <customerx|24158> sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
Mon, 2020-09-07 15:28 11[NET] <customerx|24158> sending packet: from 172.26.0.854500 to x.x.x.x4500 (1248 bytes)
Mon, 2020-09-07 15:28 11[NET] <customerx|24158> sending packet: from 172.26.0.854500 to x.x.x.x4500 (1152 bytes)
Mon, 2020-09-07 15:29 12[IKE] <customerx|24158> sending keep alive to x.x.x.x4500
Mon, 2020-09-07 15:29 16[IKE] <customerx|24158> sending keep alive to x.x.x.x4500
Mon, 2020-09-07 15:29 05[IKE] <customerx|24158> sending keep alive to x.x.x.x4500
Mon, 2020-09-07 15:30 05[IKE] <customerx|24158> giving up after 5 retransmits
Mon, 2020-09-07 15:30 05[IKE] <customerx|24158> establishing IKE_SA failed, peer not responding
Mon, 2020-09-07 15:30 05[IKE] <customerx|24158> IKE_SA customerx24158 state change: CONNECTING => DESTROYING

History

#1 Updated by Tobias Brunner about 2 months ago

  • Category changed from swanctl to configuration
  • Status changed from New to Feedback
  • Assignee changed from alex johnson to Tobias Brunner
  • Priority changed from High to Normal

Foundation level certificate

What's that?

If I remove the remote cert I still get the same error (and leave out PSK as well).

What do you mean? There is no remote cert configured. However, depending on the size of the local certificate (how big is it exactly?) there might be fragmentation issues if you can't use IKE fragmentation (in which case the only option is to not send the certificate and configure it on the remote host).

charon log

That log looks weird/incomplete. Please use the settings on HelpRequests and post the complete log.

#2 Updated by alex johnson about 1 month ago

Hi

Thanks for the reply - we can't attach the whole log as it contains information for other customers on there as well.

Re removing the cert - if I remove the entry for the remote side and leave it blank I get the same error, so would you say the issue with fragementation is our side. Also, when you say the option maybe to not send the cert and configure it on the remote end - do you mean send them our physical cert? If so, wouldn't this compromise security re private keys.

I've approached Swanstrong re paid for support - is the email address still valid?

thanks

#3 Updated by Tobias Brunner about 1 month ago

if I remove the entry for the remote side and leave it blank I get the same error

What entry? I don't see a cert setting in the remote section.

so would you say the issue with fragementation is our side.

Why do you think there is any fragmentation issue in the first place?

Also, when you say the option maybe to not send the cert and configure it on the remote end - do you mean send them our physical cert? If so, wouldn't this compromise security re private keys.

No, sending the certificate (via IKE or otherwise e.g. to install it on the remote host) does not affect the security of the private key. That's the whole point of asymmetric key pairs.

I've approached Swanstrong re paid for support - is the email address still valid?

No idea what that is, sorry. See CommercialSupport.

Also available in: Atom PDF