Project

General

Profile

Actions

Bug #5934

closed

When two distinct Phase 1 are configured, only the first one connects ar startup

Added by Luiz Fernando Cavalcanti almost 9 years ago. Updated over 8 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
02/26/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:
amd64

Description

As the attached files will illustrate if you have two distinct phase 1 entries with equally distinct and respective Phase 2 entries, only the first Phase 1(and it's phase 2) are initialized and connected when the system starts up.

If I go to STATUS > IPSEC and click in the "Connect" button for the respective Phase 1 it connects fine, no problem, no warning. I also tested if generating any traffic towards the remote subnet triggers the Phase 1 to connect, no success.

I confirmed the problem in both 2.2.5 and 2.2.6, I haven't simulated this scenario in the 2.3 snapshots yet.


Files

ipsec.xml (3.16 KB) ipsec.xml Example XML config Luiz Fernando Cavalcanti, 02/26/2016 12:12 PM
example_diagram.png (18 KB) example_diagram.png Example Diagram Luiz Fernando Cavalcanti, 02/26/2016 12:12 PM
Actions #1

Updated by Luiz Fernando Cavalcanti almost 9 years ago

Some clarification...

The two Phase 1 are not going out in the same Interface in the "Central Server" but through two different interfaces, one is a MPLS link between City A and B, the other is a common Internet link that serves the Phase 1 that goes to City C in another country.

As said, these are two distinct Phase 1, with different peers to connect and different Phase 2 subnets.

Actions #2

Updated by Chris Buechler almost 9 years ago

  • Status changed from New to Feedback
  • Assignee deleted (Renato Botelho)
  • Affected Version deleted (2.2.x)

subject is definitely not an issue.

Guessing this is the one using AH (no encryption) rather than ESP that's affected? If there's any actual issue here, it's probably AH-related, as that's very rarely used.

Actions #3

Updated by Chris Buechler over 8 years ago

  • Status changed from Feedback to Not a Bug

no apparent issues here, and no feedback

Actions #4

Updated by Luiz Fernando Cavalcanti over 8 years ago

Hi Chris,

I said to Renato that 2.3.x fixed the issue, but forgot to update the ticket here, my bad!

But just for documentation, it wasn't with AH, it was two ESP P1 with SHA-256, AES-256, DH2.

Since 2.3.x's version of strongSwan fixed it, please consider as fixed and closed... and sorry for not providing the feedback.

Actions

Also available in: Atom PDF