On Sat, 18 Aug 2018, Reuben Farrelly wrote:
I'm now testing with another router running classic IOS (not-XE) and it is
also seeing some problems establishing an IPSec session. This router is
running the latest released version of classic IOS (15.8(3)M).
The IOS XE router won't connect to any versions at all.
I've posted the debugs for both classic IOS sessions up online for
comparison:
http://www.reub.net/files/libreswan/Libreswan-3.22-working.txt
and
http://www.reub.net/files/libreswan/Libreswan-3.25-NOT-working.txt
The non-working one and the working one both setup an IPsec SA for 0/0
to 0/0 according to the logs using the same IKE and ESP parameters.
The non-working one immediately receives an additional INFORMATIONAL
exchange message with a ISAKMP_NEXT_v2CP Configuration Payload as
defined in https://tools.ietf.org/html/rfc7296#section-3.15
It seems the Informational exchange can contain a CP payload, although
we surely aren't expecting this to happen:
https://tools.ietf.org/html/rfc7296#section-1.4
So we treat the informational as a DPD type and just reply with an
empty informational exchange packet. Then we receive another
informational but now a real empty one, so a real DPD one and we
reply. All seems well. Nothing in the logs you post indicate a problem,
or show that the tunnel is "not working".
Now I know that while this isn't the subject of the original problem, I think
we should get to the bottom of this first, just in case the root causes
happen to be related. The debugs look a little similar in all cases where
things go wrong in that we have retransmits that don't seem to make much
sense.
Do you know what happened on the Cisco end? What error did it log?
Maybe the IPsec SA was up, but somehow you didnt add the proper VTI
routes?
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
