Hi,
I am trying to understand out why strongSwan (v5.9.5, el8) in an IKEv2
initiator role chooses to enable NAT-T even though the NATD hashes
received from the responder appear to match the calculated ones.
In particular I am looking at the following debug log from charon:
received packet: from
* Jafar Al-Gharaibeh
> You can NOT have the least significant octet set to zero with a 32-bit
> netmask
Sure you can. There is no fundamental difference between 192.168.10.0/32
and, say, 192.168.10.10/32. Both are equally valid, and both refer to a
single address/host.
Tore
* Tobias Brunner
> Hi Tore,
>
> > There was one thing you mentioned above that gave me some pause
> > though:
> >
> > «some heuristics might have to be used to avoid destroying the old
> > SAs as duplicates»
> >
> > Could you elaborate on how this might be a problem?
>
Hi again,
* Tobias Brunner
> > So is strongSwan here intentionally behaving in a non-compliant
> > manner simply in order to better interoperate with other
> > non-compliant IKEv2 implementations, or is there some other reason
> > why "make before break" isn't the
Hi Tobias,
* Tobias Brunner
> Hi Tore,
>
> > - Is the strongSwan behaving correctly when it is also deleting the
> > ESP CHILD_SA when receiving the DELETE IKE_SA from the FortiGate,
> > instead of "moving" it to the other active IKE_SA as it appears the
> > FortiGate
Hi,
We recently experienced that an IKEv2-negotiated ESP site-to-site
tunnel between strongSwan 5.3.5 running on Ubuntu 16.04 and a Fortinet
FortiGate router broke following the re-auth of the IKE_SA. Just one
out of six ESP CHILD_SAs broke.
I've uploaded config files, charon logs, and other