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 PeerTblEntry

    192.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: ME

    So 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.


Log in to reply