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:03 charon: 08[IKE] received INVALID_ID_INFORMATION error
notify
Feb 24 13:20:03 charon: 08[IKE] <con1000|42> received
INVALID_ID_INFORMATION error notify
Feb 24 13:20:03 charon: 08[ENC] parsed INFORMATIONAL_V1 request
3283507075 [ HASH N(INVAL_ID) ]
Feb 24 13:20:03 charon: 08[NET] received packet: from Y.Y.Y.155[500]
to X.X.X.219[500] (260 bytes)
Feb 24 13:20:03 charon: 08[NET] sending packet: from X.X.X.219[500]
to Y.Y.Y.155[500] (204 bytes)
Feb 24 13:20:03 charon: 08[ENC] generating QUICK_MODE request
1282306553 [ HASH SA No ID ID ]
Feb 24 13:20:03 charon: 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
