Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    BETA 4 120910 build: odd IPSec issue with Cisco

    2.0-RC Snapshot Feedback and Problems - RETIRED
    1
    1
    1.8k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      gravyface
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.