BETA 4 120910 build: odd IPSec issue with Cisco
-
Have an ASA 5505 (8.05) and while in debug mode and attempting to initiate phase 1 from the pfSense side, I see:
[IKEv1]: Group = 192.168.10.1, IP = 192.168.10.1, Can't find a valid tunnel group, aborting…!
[IKEv1]: Group = 192.168.10.1, IP = 192.168.10.1, Removing peer from peer table failed, no match!
[IKEv1]: Group = 192.168.10.1, IP = 192.168.10.1, Error: Unable to remove PeerTblEntry192.168.10.1 is my real gateway (router) on my LAN; the Cisco has an "outside" IP of 192.168.10.100 and the pfSense 2.0 (on a Hamakua) has a WAN IP of 192.168.10.200. Why I'm seeing a group/IP like that, I don't know, but I've gone over my settings and the racoon.conf looks fine to me, but it's not getting past phase 1 because the Cisco thinks that there's no matching group policy.
For sanity reasons, I grabbed an ALIX running pfSense 1.2.3 stable, gave it the same IP as the Hamakua, and the tunnel worked fine – the debug output on the Cisco side shows Group = 192.168.10.200, IP = 192.168.10.200 as it should. I even went back to the Hamakua and thought that the "My IP address" and the "Peer IP Address" options from the drop-down might be parsing the wrong configuration so I I set those explicitly to the WAN IP and remote peer IP.
I did do an upgrade from an October build to today's build: would there be any chance that the config is hosed? Perhaps I'll factory reset it and start over.
UPDATE:
reset to factory defaults, reconfigured, still seeing Group = 192.168.66.1, IP = 192.168.66.1 and no phase 1.
I'm going to attempt to capture some packets and see where that's in the payload.
UPDATE #2:
For fun and profit, I switched from main mode to aggressive mode, but essentially get the same thing:
Dec 09 16:48:09 [IKEv1]: IP = 192.168.10.1, Received ISAKMP Aggressive Mode message 1 with unknown tunnel group name '192.168.10.1'.
Dec 09 16:48:09 [IKEv1]: Group = DefaultRAGroup, IP = 192.168.10.1, Removing peer from peer table failed, no match!UPDATE #3:
I thought perhaps there was some odd ARP caching going on, so I gave the Hamakua a different WAN IP, but same 192.168.10.1 IP/Group.UPDATE #4:
Think I found a bug… I wanted to take 192.168.10.1 completely out of the equation so on the WAN interface on the Hamakua, I removed the default gateway (changed it to "none") hit save, and voila, tunnel worked. I'm not sure how/why that was the issue, likely a parsing error somewhere?UPDATE #5:
Diff of working racoon.conf and non-working racoon.conf are identical.
Ran a debug output, seeing the following on the working config (no gateway assigned):
2010-12-10 15:02:12: INFO: Hashing 192.168.10.200[500] with algo #2
2010-12-10 15:02:12: DEBUG: hash(sha1)
2010-12-10 15:02:12: INFO: NAT-D payload #-1 verified
2010-12-10 15:02:12: INFO: Hashing 192.168.10.100[500] with algo #2
2010-12-10 15:02:12: DEBUG: hash(sha1)
2010-12-10 15:02:12: INFO: NAT-D payload #0 verified
2010-12-10 15:02:12: INFO: NAT not detected…and here's the non-working config:
2010-12-10 14:57:58: INFO: NAT-D payload #-1 doesn't match
2010-12-10 14:57:58: INFO: Hashing 192.168.10.100[500] with algo #2
2010-12-10 14:57:58: DEBUG: hash(sha1)
2010-12-10 14:57:58: INFO: NAT-D payload #0 verified
2010-12-10 14:57:58: INFO: NAT detected: MESo it's attempting to NAT for some reason out as the gateway; need to find out why. The odd thing is, when I sniff packets (with a bridged ALIX in the middle), the src IP is not 192.168.100.1, but the correct IP.