OPNsense Forum
Archive => 20.1 Legacy Series => Topic started by: Jürgen Garbe on March 11, 2020, 12:52:51 pm
-
Hi,
I am not able to establisch an IPSec connection with more than one Phase2 definition to a Cisco ASA 5540.
Having enabled only one of both Phase2 definitions at once, everthing is working fine.
Please find attached log files:
ipsecOpnSenseCiscoTestFail.log shows the error N(INVAL_SYN),
ipsecOpnSenseCiscoTest1Phase2_1ok.log shows the successful connection with only Phase2 number 1,
ipsecOpnSenseCiscoTest1Phase2_2ok.log shows the successful connection with only Phase2 number 2.
Source and target addresses have been replaced by A.B.C.D and E.F.G.H.
Split tunnel option is enabled.
Any hint is welcome!
-
Hi,
the remote side does not seem to understand your requests:
charon: 13[IKE] <con5|1> received INVALID_SYNTAX notify error, destroying IKE_SA
charon: 13[ENC] <con5|1> parsed CREATE_CHILD_SA response 2 [ N(INVAL_SYN) ]
Perhaps the remote software/config needs to be upgraded.
Matthias Ferdinand
-
Hm,
how would you explain, that each Phase2 definition (and its traffic) alone is working, but not, if both Phase2 definitions are enabled?
Jürgen Garbe
-
Well, might be a bug on either side, or maybe Cisco limits the number of phase2 SAs per IKE phase1 connection.
You can try with two phase1 proposals, each with a single phase2 entry.
-
Without changing the world try "tunnel isolation" in phase 1 settings. Had the same issue with FortiGate compatibility a couple of years ago. :)
Cheers,
Franco
-
@mfedv: I tried to split into 2 Phase1 connections with only one Phase2 definitions each but ended in the same behaviour (only one of both is working).
@franco: Yes, I am using tunnel isolation and it's not working. That's what I meant with "Split tunnel option is enabled". Sorry for this unclear wording...
-
So with separate phase1 definitions, you can establish either one, but not both at the same time?
Can you post a log of one connecting and the other one failing?
-
Yes, please find attached the log which is showing this.
-
In this log, only a single IKE connection gets established, and the peer seems unwilling to accept the second CHILD_SA on the same IKE_SA.
Do you actually have both tunnels on separate IKE definitions? If so, then perhaps strongswan is too clever and reuses the IKE_SA that it already has:
https://unix.stackexchange.com/questions/351700/strongswan-several-right-subnets
Someone already posted a workaround:
https://forum.opnsense.org/index.php?topic=11735.0 ("IPsec and the Palo Alto Networks PA-3050")
That is a global settings and might have negative impact on other tunnels. The 5540 seems EOL for quite some time (2013!) so they should upgrade anyway, for more reasons than IPsec alone...
-
Well good that you have a OPNsense on one side.. if the box on the other side is EOL since 2013... you may have no luck.
Replace that legacy Cisco box for security and compatibility reasons as soon as possible.
-
@mfedv:
This could be the same problem I am observing! Do you have any hint for me, where exactly I should add this mentioned manual configuration line in the file ipsec.inc?
@banym:
It is a big and mighty customer and we are so small...
No chance to change the other sid (and they never ever had any problems before like this)...
-
Disclaimer: untested
In line 1088 is the call to generate config text from the nested array. So the assignment should go above it.
--------------------------------------------
1088 $strongswan = generate_strongswan_conf($strongswanTree);
1089 $strongswan .= "\ninclude strongswan.opnsense.d/*.conf\n";
1090 @file_put_contents("/usr/local/etc/strongswan.conf", $strongswan);
1091 unset($strongswan);
--------------------------------------------
But less intrusive and with higher chance of surviving the next opnsense update: create a file /usr/local/etc/strongswan.opnsense.d/noreuse_ikesa.conf with a line
charon { reuse_ikesa=no }
and restart ipsec.
-
@mfedv:
You are my hero of the day!
That solved the issue.
Would be worth to be an option in the OPNsense GUI.
Thank you very, very much :)
-
Important additional information:
using this option, there is not need anymore to use 2 different Phase 1 definitions.
Now it works like it should:
Only 1 Phase 1 definition with 2 individual Phase 2 definitions (each for one seperate network to reach at the other side).
Thank you again for helping me! :)
-
Would someone be so kind to open a ticket for this and reference this form thread?
https://github.com/opnsense/core/issues/new?assignees=&labels=&template=feature_request.md&title=
Thanks,
Franco
-
@franco:
I created a feature request https://github.com/opnsense/core/issues/3990
Because it is my first one: if something is missing or unclear, just give me a hint so that I can rewrite it.
-
Thanks, certain core devs are a bit grumpy about this, but I'll add the checkbox for easier use. ;)
Cheers,
Franco