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

    IPSec VPN from pfSense to Cisco 1941 dropping connection (redacted)

    Scheduled Pinned Locked Moved IPsec
    11 Posts 3 Posters 1.5k 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.
    • T
      TheWhiteWing01
      last edited by

      Hello, everyone. I recently installed a Netgate SG-3100 device, running pfSense 2.4.4_p2. This box replaced a Cisco 881 ISR that was having issues.
      The Cisco maintained a site-to-site connection to a branch office, and I was able to connect to the remote router, and reconfigure the VPN for our new IPsec VPN connection. After twenty minutes of messing around in Putty, the remote Cisco1941 was configured how I wanted it, I added the pfSense P1 and P2 configurations, and tada! Connection established! ... for 30 seconds. The connection will re-establish itself, but for a maximum of 30 seconds before dropping out and re-establishing again.

      Here is my setup:

      MainOffice(192.168.3.0) --- pfSense(50.196.x.x) ------------ Cisco1941(173.220.x.x ) --- BranchOffice(192.168.16.0)

      Here's the P1/P2 settings on my pfSense:
      0_1547222689854_dc278813-7080-4a2b-9724-b6829f61b037-image.png

      Below is the settings on the Cisco router.

      ```Crypto Map IPv4 "pfsense" 15 ipsec-isakmp
              Peer = 50.196.x.x
              Peer = 96.65.x.x
              Extended IP access list 150
                  access-list 150 permit ip 192.168.3.0 0.0.0.255 192.168.16.0 0.0.0.255
                  access-list 150 permit ip 192.168.16.0 0.0.0.255 192.168.3.0 0.0.0.255
              Current peer: 96.65.x.x
              Security association lifetime: 4608000 kilobytes/28800 seconds
              Responder-Only (Y/N): N
              PFS (Y/N): Y
              DH group:  group2
              Mixed-mode : Disabled
              Transform sets={
                      NEW256:  { esp-256-aes esp-sha-hmac  } ,
              }
              Interfaces using crypto map pfsense:
                      GigabitEthernet0/1
      

      ===

      As you can see above, there are two peers listed. The second peer is an unrelated office of another client, but they also have the same Netgate SG-3100. Mirroring the settings from the first for P1 and P2, however, this unrelated Netgate is able to maintain connection. The only difference I can find between the two boxes is that the one having issues is running pfSense 2.4.4_p2, where as the unrelated-but-working Netgate is running pfSense 2.4.4_p1. I have added the IPSec logs from my non-working device as an attachment, but my questions are this: Does the newest pfSense have an issue with IPSec tunnels, or is there anything in my logs/configs that anyone can find that can tell me what I have misconfigured or need to change in order to get this working? Please let me know if I need to provide more information.

      Thank you,
      Josh

      0_1547225748823_IPSec logs Redacted.txt

      K 1 Reply Last reply Reply Quote 0
      • K
        Konstanti @TheWhiteWing01
        last edited by Konstanti

        @thewhitewing01

        Hello again.
        I'll try again to clarify
        Pfsense is also Ikev1 main mode ?
        Cisco Ikev1 quick (aggresive ) mode ?

        T 1 Reply Last reply Reply Quote 0
        • T
          TheWhiteWing01 @Konstanti
          last edited by

          @konstanti Yes to both.

          K 2 Replies Last reply Reply Quote 0
          • K
            Konstanti @TheWhiteWing01
            last edited by Konstanti

            @thewhitewing01
            I beg your pardon
            Friday afternoon
            Do not look back
            phase 1 is fine.
            For some reason , problems with the phase 2

            1 Reply Last reply Reply Quote 0
            • K
              Konstanti @TheWhiteWing01
              last edited by

              @thewhitewing01
              Phase2
              if you change the hash algorithm to sha256 on both sides
              will anything change ?

              T 2 Replies Last reply Reply Quote 0
              • T
                TheWhiteWing01 @Konstanti
                last edited by

                @konstanti I will try right now.

                1 Reply Last reply Reply Quote 0
                • T
                  TheWhiteWing01 @Konstanti
                  last edited by

                  @konstanti Negative. No change in status. I am confused as to why the second pfSense is able to maintain connection with zero issues while this one cannot, despite using the same settings.

                  K 3 Replies Last reply Reply Quote 0
                  • K
                    Konstanti @TheWhiteWing01
                    last edited by Konstanti

                    @thewhitewing01
                    can you send me a picture like this when the connection is established ?
                    Ideally, you need pictures from two pfssense

                    0_1547233639076_58657f38-1433-465d-9c5f-fcc5aef758a3-image.png

                    1 Reply Last reply Reply Quote 0
                    • K
                      Konstanti @TheWhiteWing01
                      last edited by Konstanti

                      @thewhitewing01
                      See more here
                      I wonder what information is provided by cisco

                      https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/5409-ipsec-debug-00.html
                      On one of forums I read that the problem can be in mismatch of param
                      eters of lifetime pf / Cisco or dpddelay, dpdtimeout pfsense (keepalive Cisco)
                      You can try to enable/disable DPD on the cisco side
                      For example ,
                      crypto isakmp keepalive 10 5 (enable )
                      or
                      no crypto isakmp keepalive

                      1 Reply Last reply Reply Quote 0
                      • K
                        Konstanti @TheWhiteWing01
                        last edited by Konstanti

                        @thewhitewing01
                        Even as an option - you're blocking all incoming packets on the ipsec interface or WAN interface (500,4500 udp or ESP) of pfsense is also and cisco believes that PF is not available, and breaks the connection
                        What are the rules on IPSEC interface and WAN interface?

                        1 Reply Last reply Reply Quote 0
                        • DerelictD
                          Derelict LAYER 8 Netgate
                          last edited by

                          Jan 11 10:21:26 charon 05[NET] <con1000|17> received packet: from 173.220.x.x[500] to 50.196.x.x[500] (380 bytes)
                          Jan 11 10:21:26 charon 05[ENC] <con1000|17> parsed QUICK_MODE request 3356035729 [ HASH SA No KE ID ID ]
                          Jan 11 10:21:26 charon 05[ENC] <con1000|17> received HASH payload does not match
                          Jan 11 10:21:26 charon 05[IKE] <con1000|17> integrity check failed
                          Jan 11 10:21:26 charon 05[ENC] <con1000|17> generating INFORMATIONAL_V1 request 3233859265 [ HASH N(INVAL_HASH) ]
                          Jan 11 10:21:26 charon 05[NET] <con1000|17> sending packet: from 50.196.x.x[500] to 173.220.x.x[500] (76 bytes)
                          Jan 11 10:21:26 charon 05[IKE] <con1000|17> QUICK_MODE request with message ID 3356035729 processing failed
                          Jan 11 10:21:26 charon 05[NET] <con1000|17> received packet: from 173.220.x.x[500] to 50.196.x.x[500] (92 bytes)
                          Jan 11 10:21:26 charon 05[ENC] <con1000|17> parsed INFORMATIONAL_V1 request 2703109558 [ HASH D ]
                          Jan 11 10:21:26 charon 05[IKE] <con1000|17> received DELETE for IKE_SA con1000[17]
                          Jan 11 10:21:26 charon 05[IKE] <con1000|17> deleting IKE_SA con1000[17] between 50.196.x.x[50.196.x.x]...173.220.x.x[173.220.x.x]
                          Jan 11 10:21:26 charon 05[IKE] <con1000|17> IKE_SA con1000[17] state change: ESTABLISHED => DELETING
                          Jan 11 10:21:26 charon 05[IKE] <con1000|17> IKE_SA con1000[17] state change: DELETING => DELETING
                          Jan 11 10:21:26 charon 05[IKE] <con1000|17> IKE_SA con1000[17] state change: DELETING => DESTROYING

                          Your side does not like the traffic selector in the P2 being sent by the other side.

                          Please send the output from each of these on each node - the one that's working and the one that isn't:

                          swanctl --list-conns

                          swanctl --list-sas

                          cat /var/etc/ipsec/ipsec.conf

                          Send them in chat or I can send you a nextcloud upload link.

                          Chattanooga, Tennessee, USA
                          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                          Do Not Chat For Help! NO_WAN_EGRESS(TM)

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