Project

General

Profile

Issue #1004

rightid is ignored where right=FQDN

Added by Chris Buechler over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.3.2
Resolution:
No change required

Description

Where a FQDN is used in 'right=', the rightid is apparently ignored. This is a regression/change in behavior somewhere between 5.3.0 and 5.3.2.

Starting at the following scenario:
https://www.strongswan.org/uml/testresults/ikev2/net2net-psk/

Change these lines in sun's ipsec.conf:

    right=moon.strongswan.org
    rightid=192.168.0.1

and in sun's ipsec.secrets:

192.168.0.1 @sun.strongswan.org : PSK 0sv+NkxY9LLZvwj4qCC2o/gGrWDF2d21jL

Change moon accordingly to match. Try to bring up the connection, and you'll end up with:

charon: 15[IKE] <con3|1> no shared key found for 'sun.strongswan.org' - '192.168.0.1'

Change sun's ipsec.secrets to:

@moon.strongswan.org @sun.strongswan.org : PSK 0sv+NkxY9LLZvwj4qCC2o/gGrWDF2d21jL

and it'll work fine. In at least versions 5.2.x and 5.3.0, it worked fine with the IP (matching rightid) in ipsec.secrets.

History

#1 Updated by Chris Buechler over 5 years ago

noticed I flipped left and right in ipsec.secrets, that was just my mistake in manually typing out something. The actual config I was using was correct.

#2 Updated by Chris Buechler over 5 years ago

Sorry, that's a misdiagnosis.

The issue appears to be if you have right=FQDN in ipsec.conf, upon initial start of strongswan during boot, it logs:

charon: 00[CFG] loading secrets from '/etc/ipsec/ipsec.secrets'

but doesn't log loading of specific secrets. Just running 'ipsec rereadall' once bootup is complete fixes the issue. That's the first time it then logs along the lines of:

charon: 12[CFG] loaded IKE secret for x.x.x.x y.y.y.y

then it works. So there is definitely an issue here, just not as originally described. Appears having right=FQDN makes it skip loading IKE secrets.

#3 Updated by Chris Buechler over 5 years ago

Please close - sorry for the noise. Turns out something wasn't writing out the contents of ipsec.secrets by the time strongswan started during boot, leaving it reading a blank file. User error, apologies.

#4 Updated by Tobias Brunner over 5 years ago

  • Category set to configuration
  • Status changed from New to Closed
  • Resolution set to No change required

Also available in: Atom PDF