Re: [pfSense] pfsense 2.2 Strongswan rekeying issues
On 24/02/2015 20:33, Chris Buechler wrote: That's this: https://redmine.pfsense.org/issues/4178 disabling Unity on the Advanced tab, followed by a manual stop and start (not just restart) of strongswan may resolve that. There was one person reporting that wasn't adequate, the plugin had to be not loaded at all, not just disabled like that. I haven't yet had a chance to try to duplicate that circumstance. Many thanks. I've made that change now and I'll see over the next few days if it stays up. Regards, Brian. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] pfsense 2.2 Strongswan rekeying issues
On Tue, Feb 24, 2015 at 8:02 AM, Brian Candler wrote:
> We appear to have the same problem here after upgrading a box from pfSense
> 2.1.5 to 2.2. The other side is a Cisco ASA5505.
>
> X.X.X.219 = pfSense, internal subnet 10.19.0.0/16
> Y.Y.Y.155 = Cisco, internal subnet 10.26.0.0/16
>
> Here is the log we get from the Cisco:
>
> 2015 Feb 24 13:20:03 Group = X.X.X.219, IP = X.X.X.219, Error: dynamic map
> SYSTEM_DEFAULT_CRYPTO_MAP: * to any not permitted.
> 2015 Feb 24 13:20:03 Group = X.X.X.219, IP = X.X.X.219, Rejecting IPSec
> tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0
> local proxy 10.26.0.0/255.255.0.0/0/0 on interface outside
> 2015 Feb 24 13:20:03 Group = X.X.X.219, IP = X.X.X.219, QM FSM error (P2
> struct &0xcc9648f8, mess id 0x4c6e71f9)!
> 2015 Feb 24 13:20:03 Group = X.X.X.219, IP = X.X.X.219, Removing peer from
> correlator table failed, no match!
>
> From this, it looks pretty clear that the phase 2 request from pfSense is
> wrong: it is requesting 0.0.0.0/0 <-> 10.26.0.0/16, instead of
> 10.19.0.0/16 <-> 10.26.0.0/16
>
> Here is the log from the pfSense side:
>
> Feb 24 13:20:03charon: 08[IKE] received INVALID_ID_INFORMATION error
> notify
> Feb 24 13:20:03charon: 08[IKE] received
> INVALID_ID_INFORMATION error notify
> Feb 24 13:20:03charon: 08[ENC] parsed INFORMATIONAL_V1 request
> 3283507075 [ HASH N(INVAL_ID) ]
> Feb 24 13:20:03charon: 08[NET] received packet: from Y.Y.Y.155[500] to
> X.X.X.219[500] (260 bytes)
> Feb 24 13:20:03charon: 08[NET] sending packet: from X.X.X.219[500] to
> Y.Y.Y.155[500] (204 bytes)
> Feb 24 13:20:03charon: 08[ENC] generating QUICK_MODE request
> 1282306553 [ HASH SA No ID ID ]
> Feb 24 13:20:03charon: 14[KNL] creating acquire job for policy
> X.X.X.219/32|/0 === Y.Y.Y.155/32|/0 with reqid {1}
>
That's this:
https://redmine.pfsense.org/issues/4178
disabling Unity on the Advanced tab, followed by a manual stop and start
(not just restart) of strongswan may resolve that. There was one person
reporting that wasn't adequate, the plugin had to be not loaded at all, not
just disabled like that. I haven't yet had a chance to try to duplicate
that circumstance.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] pfsense 2.2 Strongswan rekeying issues
if i had such rekeying issues one or more of the following was may be not
in the right shape:
Key times to live, different TTL on both sides for the resp. Component
(DH,AH ... )
Key lenghts/Algorithms (rare)
Timing issues due to Packet-Flow (very often, due to policy based routing
in the net)
Check with mtr for different routes for out and in packets, if they have
different routes, the tunnels will struggle.
= = = http://michael-schuh.net/ = = =
Projektmanagement - IT-Consulting - Professional Services IT
Postfach 10 21 52
66021 Saarbrücken
phone: 0681/8319664
@: m i c h a e l . s c h u h @ g m a i l . c o m
= = = Ust-ID: DE251072318 = = =
2015-02-24 15:38 GMT+01:00 Bob Gustafson :
> Excellent clue!
>
> On 02/24/2015 08:15 AM, Brian Candler wrote:
>
> 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
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] pfsense 2.2 Strongswan rekeying issues
Excellent clue!
On 02/24/2015 08:15 AM, Brian Candler wrote:
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
Re: [pfSense] pfsense 2.2 Strongswan rekeying issues
Interestingly, if we kick the tunnel from the pfSense GUI, it negotiates
both P1 and P2 successfully.
pfSense log:
Feb 24 14:06:42charon: 07[ENC] generating QUICK_MODE request
1807616002 [ HASH ]
Feb 24 14:06:42charon: 07[IKE] CHILD_SA con1000{1} established with
SPIs _i _o and TS 10.19.0.0/16|/0 === 10.26.0.0/16|/0
Feb 24 14:06:42charon: 07[IKE] CHILD_SA con1000{1}
established with SPIs _i _o and TS 10.19.0.0/16|/0 ===
10.26.0.0/16|/0
Feb 24 14:06:42charon: 07[ENC] parsed QUICK_MODE response 1807616002
[ HASH SA No ID ID ]
Feb 24 14:06:42charon: 07[NET] received packet: from Y.Y.Y.155[500]
to X.X.X.219[500] (164 bytes)
Feb 24 14:06:42charon: 07[NET] sending packet: from X.X.X.219[500]
to Y.Y.Y.155[500] (204 bytes)
Feb 24 14:06:42charon: 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
Re: [pfSense] pfsense 2.2 Strongswan rekeying issues
We appear to have the same problem here after upgrading a box from
pfSense 2.1.5 to 2.2. The other side is a Cisco ASA5505.
X.X.X.219 = pfSense, internal subnet 10.19.0.0/16
Y.Y.Y.155 = Cisco, internal subnet 10.26.0.0/16
Here is the log we get from the Cisco:
2015 Feb 24 13:20:03 Group = X.X.X.219, IP = X.X.X.219, Error: dynamic
map SYSTEM_DEFAULT_CRYPTO_MAP: * to any not permitted.
2015 Feb 24 13:20:03 Group = X.X.X.219, IP = X.X.X.219, Rejecting IPSec
tunnel: no matching crypto map entry for remote proxy
0.0.0.0/0.0.0.0/0/0 local proxy 10.26.0.0/255.255.0.0/0/0 on interface
outside
2015 Feb 24 13:20:03 Group = X.X.X.219, IP = X.X.X.219, QM FSM error (P2
struct &0xcc9648f8, mess id 0x4c6e71f9)!
2015 Feb 24 13:20:03 Group = X.X.X.219, IP = X.X.X.219, Removing peer
from correlator table failed, no match!
From this, it looks pretty clear that the phase 2 request from pfSense
is wrong: it is requesting 0.0.0.0/0 <-> 10.26.0.0/16, instead of
10.19.0.0/16 <-> 10.26.0.0/16
Here is the log from the pfSense side:
Feb 24 13:20:03charon: 08[IKE] received INVALID_ID_INFORMATION error
notify
Feb 24 13:20:03charon: 08[IKE] received
INVALID_ID_INFORMATION error notify
Feb 24 13:20:03charon: 08[ENC] parsed INFORMATIONAL_V1 request
3283507075 [ HASH N(INVAL_ID) ]
Feb 24 13:20:03charon: 08[NET] received packet: from Y.Y.Y.155[500]
to X.X.X.219[500] (260 bytes)
Feb 24 13:20:03charon: 08[NET] sending packet: from X.X.X.219[500]
to Y.Y.Y.155[500] (204 bytes)
Feb 24 13:20:03charon: 08[ENC] generating QUICK_MODE request
1282306553 [ HASH SA No ID ID ]
Feb 24 13:20:03charon: 14[KNL] creating acquire job for policy
X.X.X.219/32|/0 === Y.Y.Y.155/32|/0 with reqid {1}
which basically just says that pfSense tried to negotiate phase 2 and
the Cisco rejected it.
The output of setkey -D -P on pfSense currently looks reasonable: we
have a number of other tunnels but it includes
...
10.26.0.0/16[any] 10.19.0.0/16[any] any
in ipsec
esp/tunnel/Y.Y.Y.155-X.X.X.219/unique:1
created: Feb 24 13:26:35 2015 lastused: Feb 24 13:44:50 2015
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=912 seq=4 pid=18754
refcnt=1
...
10.19.0.0/16[any] 10.26.0.0/16[any] any
out ipsec
esp/tunnel/X.X.X.219-Y.Y.Y.155/unique:1
created: Feb 24 13:26:35 2015 lastused: Feb 24 13:49:56 2015
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=911 seq=0 pid=57004
refcnt=1
I don't see any policies with 0.0.0.0/0 in them.
When the tunnels had failed to negotiate the SA appeared to still be
there, although the time between 'created' and 'lastused' was more than
1 hour, so this may have been showing a stale SA.
This *is* reproducible, unfortunately reproducing several times per day
:-( We need to manually kick the tunnel to get it to come up again.
When the tunnel is up, the Cisco shows:
asa1# sh crypto ipsec sa peer X.X.X.219
peer address: X.X.X.219
Crypto map tag: outside_map0, seq num: 4, local addr: Y.Y.Y.155
access-list outside_cryptomap_3 extended permit ip 10.26.0.0
255.255.0.0 10.19.0.0 255.255.0.0
local ident (addr/mask/prot/port): (10.26.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.19.0.0/255.255.0.0/0/0)
current_peer: X.X.X.219
...
The configuration in the pfSense GUI shows the tunnel with a single
phase 2 entry (mode tunnel; local subnet 10.19.0.0/16; remote subnet
10.26.0.0/16; P2 Protocol ESP; P2 Transforms AES (128 bits), 3DES; P2
Auth Methods SHA1)
Regards,
Brian.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
