Project

General

Profile

Bug #4785

IKEv2 w/PSK not matching where remote is FQDN

Added by Chris Buechler almost 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Very High
Category:
IPsec
Target version:
Start date:
06/22/2015
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.2.3
Affected Architecture:

Description

Where using IKEv2 with PSK on a site to site VPN, where the identifiers are IPs, and the remote is a FQDN, you end up with something like the following:

Jun 22 16:29:44    charon: 01[NET] <con3|1> sending packet: from 172.27.44.52[500] to 172.27.44.51[500] (300 bytes)
Jun 22 16:29:44    charon: 01[NET] <con3|1> received packet: from 172.27.44.51[500] to 172.27.44.52[500] (76 bytes)
Jun 22 16:29:44    charon: 01[ENC] <con3|1> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
Jun 22 16:29:44    charon: 01[IKE] <con3|1> received AUTHENTICATION_FAILED notify error
Jun 22 16:29:44    charon: 01[IKE] <con3|1> received AUTHENTICATION_FAILED notify error

or:

Jun 22 16:27:14    charon: 05[IKE] <con3|3> no shared key found for '172.27.44.52' - '172.27.44.51'
Jun 22 16:27:14    charon: 05[IKE] <con3|3> no shared key found for '172.27.44.52' - '172.27.44.51'

where ipsec.secrets is configured like:

%any 172.27.44.51 : PSK 0sFjeRIUgndkfjEiufeskFD

Change %any to the specific local identifier and it works fine.

172.27.44.52 172.27.44.51 : PSK 0sFjeRIUgndkfjEiufeskFD

Associated revisions

Revision fe96d725 (diff)
Added by Chris Buechler almost 4 years ago

Use $myid in ipsec.secrets. Ticket #4785

Revision d812e83e (diff)
Added by Chris Buechler almost 4 years ago

Use $myid in ipsec.secrets. Ticket #4785

Conflicts:
etc/inc/vpn.inc

Revision 29c9e140 (diff)
Added by Renato Botelho almost 4 years ago

Add a workaround for ticket #4785:

There was a regression on strongswan between 5.3.0 and 5.3.2 as reported
at [1]. To workaround this issue, add an extra line on ipsec.secrets
with right fqdn.

Revision 019ee2bc (diff)
Added by Renato Botelho almost 4 years ago

Add a workaround for ticket #4785:

There was a regression on strongswan between 5.3.0 and 5.3.2 as reported
at [1]. To workaround this issue, add an extra line on ipsec.secrets
with right fqdn.

Revision dbd43cc2 (diff)
Added by Renato Botelho almost 4 years ago

Instead of sending USR1, just call ipsec reload. And before it, call ipsec rereadsecrets to make sure new secretes are updated. It should fix #4785

Revision a241d6b5 (diff)
Added by Renato Botelho almost 4 years ago

Instead of sending USR1, just call ipsec reload. And before it, call ipsec rereadsecrets to make sure new secretes are updated. It should fix #4785

Revision 9edeadc5 (diff)
Added by Renato Botelho almost 4 years ago

Replace ipsec rereadsecrets + reload by single rereadall, that will re-read also cert changes. Ticket #4785

Revision 8961801d (diff)
Added by Renato Botelho almost 4 years ago

Replace ipsec rereadsecrets + reload by single rereadall, that will re-read also cert changes. Ticket #4785

Revision 2f898d6a (diff)
Added by Renato Botelho almost 4 years ago

rereadall is not enough here, restore reload call to make sure everything works. Ticket #4785

Revision 96072f52 (diff)
Added by Renato Botelho almost 4 years ago

rereadall is not enough here, restore reload call to make sure everything works. Ticket #4785

History

#1 Updated by Chris Buechler almost 4 years ago

  • Status changed from Confirmed to Feedback
  • Assignee set to Chris Buechler

should be fixed, need to double check every type of config to verify all still work.

#2 Updated by Renato Botelho almost 4 years ago

  • % Done changed from 0 to 100

#4 Updated by Chris Buechler almost 4 years ago

  • Status changed from Feedback to Resolved

confirmed good.

Also available in: Atom PDF