Interestingly, if we kick the tunnel from the pfSense GUI, it negotiates
both P1 and P2 successfully.
pfSense log:
Feb 24 14:06:42 charon: 07[ENC] generating QUICK_MODE request
1807616002 [ HASH ]
Feb 24 14:06:42 charon: 07[IKE] CHILD_SA con1000{1} established with
SPIs XXXXXXXX_i YYYYYYYY_o and TS 10.19.0.0/16|/0 === 10.26.0.0/16|/0
Feb 24 14:06:42 charon: 07[IKE] <con1000|48> CHILD_SA con1000{1}
established with SPIs XXXXXXXX_i YYYYYYYY_o and TS 10.19.0.0/16|/0 ===
10.26.0.0/16|/0
Feb 24 14:06:42 charon: 07[ENC] parsed QUICK_MODE response 1807616002
[ HASH SA No ID ID ]
Feb 24 14:06:42 charon: 07[NET] received packet: from Y.Y.Y.155[500]
to X.X.X.219[500] (164 bytes)
Feb 24 14:06:42 charon: 07[NET] sending packet: from X.X.X.219[500]
to Y.Y.Y.155[500] (204 bytes)
Feb 24 14:06:42 charon: 07[ENC] generating QUICK_MODE request
1807616002 [ HASH SA No ID ID ]
<< snip all the P1 negotiation >>
However based on Nagios logs, after the tunnel has been up for pretty
much exactly one hour, it drops out again. This would coincide with the
P2 SA expiring and being re-negotiated.
It would be *really* helpful if the debug message "generating QUICK_MODE
request" included the P2 parameters being requested, in the same way the
CHILD_SA message does ("TS 10.19.0.0/16|/0 === 10.26.0.0/16|/0"), as
according to the Cisco, it's asking for the wrong ones.
Regards,
Brian.
_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
