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

    PFS <> ASA IPSec tunnel help

    Scheduled Pinned Locked Moved IPsec
    23 Posts 3 Posters 8.8k Views
    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.
    • M
      Matthias
      last edited by

      Hmm ok. The only other thing I could suggest is posting the outputs of the following commands when the tunnel is working and when it stops working.

      
show crypto ipsec sa
show crypto ikev1 sa
show crypto map
      1 Reply Last reply Reply Quote 0
      • S
        sipple31
        last edited by

        @Matthias:

        Hmm ok. The only other thing I could suggest is posting the outputs of the following commands when the tunnel is working and when it stops working.

        
show crypto ipsec sa
show crypto ikev1 sa
show crypto map

        So I went ahead and switched the whole network around to 192.168.31.x to get off the public range.  Got the tunnel back up.  Same exact behavior.  Here are some show commands off the ASA if you are interested.  They do not change whether the tunnel is "dormant" or not… I'm so confuzzled.

        ASA_Show_Cmds.txt

        1 Reply Last reply Reply Quote 0
        • M
          Matthias
          last edited by

          Well I'm not sure on this one. Your results with NAT-T enabled were the same I'm assuming? My guess is there's something going on with the security associations. They might be expiring on the pfSense side. You said the indicator stays green on the IPSec status page right? Maybe check the SAD tab. There should be two SAs there, one for inbound and one for outbound and the data column should be increasing when you refresh the page (there may be more than two but only two will be active with data increasing). Their SPI's should match the SPI's listed from the sh crypto ipsec sa output under current inbound/outbound SPIs.

          I'm not sure where else to look for. Kinda at a loss for this one. Seems like there's something deeper happening.

          1 Reply Last reply Reply Quote 0
          • S
            sipple31
            last edited by

            @Matthias:

            Well I'm not sure on this one. Your results with NAT-T enabled were the same I'm assuming? My guess is there's something going on with the security associations. They might be expiring on the pfSense side. You said the indicator stays green on the IPSec status page right? Maybe check the SAD tab. There should be two SAs there, one for inbound and one for outbound and the data column should be increasing when you refresh the page (there may be more than two but only two will be active with data increasing). Their SPI's should match the SPI's listed from the sh crypto ipsec sa output under current inbound/outbound SPIs.

            I'm not sure where else to look for. Kinda at a loss for this one. Seems like there's something deeper happening.

            lol… I know...

            when the tunnel is dormant the traffic is NOT coming across the tunnel from ASA to PFS.  The traffic does not increment.  If I send one ping from PFS to ASA, the tunnel awakens and traffic flows freely both ways.  If the tunnel is dormant and I start a continuous ping from ASA to PFS... it might wake up after 4 failed pings or after 40.  It's totally random.  I definitely think this issue lies in the ASA.

            This does not happen with our other branch networks running the little ASA 5505's.  I need to get this working flawlessly to convince the boss-man to start putting more PFS into branch offices versus the overpriced 5505's.  :D

            1 Reply Last reply Reply Quote 0
            • S
              sipple31
              last edited by

              Well Cisco washed their hands of this.  I got on a support call with a guy and he was able to prove that the request packets were being sent to the pfSense box.  Packet captures don't lie.

              This is either a hardware issue with the appliance running my pfSense or an ISP issue.  Sucks to have a little nagging issue like this.  It bugs me.  :-\

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                You have "Prefer old SAs" enabled under System>Advanced? Probably shouldn't. Description matches what might happen if that were set in this circumstance.

                1 Reply Last reply Reply Quote 0
                • S
                  sipple31
                  last edited by

                  Yes - thanks for pointing that out.  I have tried with that setting on and off… same behavior.

                  1 Reply Last reply Reply Quote 0
                  • S
                    sipple31
                    last edited by

                    Well.  Tried new interfaces on my device to prove out any sort of IRQ issue.  Messed around with settings a bunch more - always the same behavior.  I also tried setting NTP to peer with a server over the IPsec.  The slight addition of traffic keeps the tunnel "alive" MORE often… but still pretty easy to catch it sleeping.  PCAPS show the ESP packets coming in and pfs not responding.  So weird.

                    I got a desktop PC ready with the same pfs version, restored my config, and am going to throw it in place of my current hardware.  At this point I'm curious if i'm running into a hardware issue or a pfs bug.  Will try it out the next time I'm home...

                    EDIT: It's funny... this thread from way back in 2007-2008 explains almost the exact same behavior I'm seeing: https://forum.pfsense.org/index.php?topic=5920.0

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb
                      last edited by

                      Is that inbound ESP being blocked? Should show in the firewall log if it is, unless you disabled logging on the default deny rule. There are two reasons you see ESP coming in and nothing actually decrypting that traffic - it's getting blocked, or it isn't for an active SA. The rules to allow that ESP would be automatically added unless you have that disabled under System>Advanced.

                      1 Reply Last reply Reply Quote 0
                      • S
                        sipple31
                        last edited by

                        @cmb:

                        Is that inbound ESP being blocked? Should show in the firewall log if it is, unless you disabled logging on the default deny rule. There are two reasons you see ESP coming in and nothing actually decrypting that traffic - it's getting blocked, or it isn't for an active SA. The rules to allow that ESP would be automatically added unless you have that disabled under System>Advanced.

                        Sure enough… firewall.  I never saw it in the logs.  However, this makes me question what I know about firewalls.  Shouldn't traffic either pass or fail?  It's like once the stream was initiated and flowing - it just let the traffic pass.  Can you explain that?

                        I checked in System>Advanced>Firewall/NAT and the "Disable auto added VPN rules" is not checked... so I'm not quite sure why the ESP rule didn't make it in.

                        thanks

                        EDIT: I just checked on the new 7541 I rolled out and it did not have this rule for ESP auto-added, either.

                        1 Reply Last reply Reply Quote 0
                        • C
                          cmb
                          last edited by

                          Outbound ESP from your side and replies to it were being passed, ESP initiated on the other side was not. That would make it mostly if not entirely work when you initiate it, but not in the opposite direction.

                          Assuming you still have the auto-added VPN rules enabled, what do you see in the output for command:

                          grep esp /tmp/rules.debug

                          1 Reply Last reply Reply Quote 0
                          • S
                            sipple31
                            last edited by

                            Here you go:

                            [2.1-RELEASE][admin@sipsense.localdomain]/root(3): grep esp /tmp/rules.debug
                            pass  in  quick  on $WAN reply-to ( rl1 24.118.172.1 ) inet proto esp  from 63.238.x.x to any keep state  label "USER_RULE: Allow ESP from XRD ASA"
                            pass out on $WAN  route-to ( rl1 24.118.172.1 )  proto esp from any to 63.238.x.x keep state label "IPsec: XRD ASA - outbound esp proto"
                            pass in on $WAN  reply-to ( rl1 24.118.172.1 )  proto esp from 63.238.x.x to any keep state label "IPsec: XRD ASA - inbound esp proto"

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