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

    IPSec tunnel - No traffic

    Scheduled Pinned Locked Moved IPsec
    49 Posts 7 Posters 14.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.
    • E
      e066377
      last edited by e066377

      I have a similar problem with pfSense 2.4.4.

      LAN interface stops routing traffic, tunnels stop working after some minutes or sometimes hours

      I have multiple Phase 2 tunnels, if i restart a computer in local network or restart IPsec service multiple times and try to ping tunnel remote IP then tunnels start to get packets but after a while traffic stops again.

      People had the same problem before : https://forum.netgate.com/topic/98893/pfsense-2-3-lan-interface-stops-routing-traffic-stops-working-after-2-or-3-day

      And it was fixed with 2.3.1, i think it was a solution by disabling all but 1 CPU. May it be the same?

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        If it works at all on upgraded devices then you have a different issue. Please start a new thread to address that.

        Steve

        1 Reply Last reply Reply Quote 0
        • B
          bpados
          last edited by

          Sorry. Still having this issue I'll try to get some ipsec status printed out this week. It's been busy.
          Thank you.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Just to confirm; the traffic counters on the phase 2 status shows 0 at both ends and in both directions?

            Steve

            1 Reply Last reply Reply Quote 0
            • B
              bpados
              last edited by

              You just pointed out to something I never paid attention to.
              In lack of time I looked at one of the setups and Connection is established but phase to status is not available on the connection that's not working.

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                Ah, phase 1 comes up but not phase 2? Then check for a mismatch there. The IPSec logs should show an error.

                Steve

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

                  No intention of hijacking the thread.
                  I'm using 2.4.4-RELEASE (amd64)
                  built on Thu Sep 20 09:33:19 EDT 2018
                  FreeBSD 11.2-RELEASE-p3

                  I create an ipSec tunnel with identical configuration of others created on a previous rev (2.4.3p1) and the tunnel itself establishes, but no traffic passes through. On the phase 2 items, they're configured in a fashion similar to the other working tunnels. One thing I noticed that was very strange. In Static -> IPsec -> SADs, the whole section on this 2.4.4 instance is EMPTY, but on the others, it's populated with two entries per phase 2 item.

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    The SADs will only appear once the tunnel is up. The SPDs should be be there whether it is up or not though.

                    If you see no SADs it's not establishing. Check the ipsec logs.

                    Steve

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

                      con2000: #3 toOffice pu.bl.ic.ip 10.xx.xx.xx NAT-T re.mo.te.ip re.mo.te.ip IKEv2
                      initiator 23725 seconds (06:35:25) AES_CBC
                      HMAC_SHA1_96
                      PRF_HMAC_SHA1
                      MODP_1024 ESTABLISHED
                      4026 seconds (01:07:06) ago

                      Status shows as "ESTABLISHED" for the main tunnel.

                      log snippet:
                      Nov 8 18:28:26 charon 09[NET] <con2000|3> received packet: from re.mo.te.ip[4500] to 10.xx.xx.1[4500] (76 bytes)
                      Nov 8 18:28:26 charon 09[ENC] <con2000|3> parsed INFORMATIONAL request 252 [ ]
                      Nov 8 18:28:26 charon 09[ENC] <con2000|3> generating INFORMATIONAL response 252 [ ]
                      Nov 8 18:28:26 charon 09[NET] <con2000|3> sending packet: from 10.xx.xx.1[4500] to re.mo.te.ip[4500] (76 bytes)
                      Nov 8 18:28:30 charon 12[CFG] vici client 574 connected
                      Nov 8 18:28:30 charon 16[CFG] vici client 574 registered for: list-sa
                      Nov 8 18:28:30 charon 16[CFG] vici client 574 requests: list-sas
                      Nov 8 18:28:30 charon 16[CFG] vici client 574 disconnected

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

                        You want to look for log messages detailing bringing up the ESP inner tunnels based on the traffic selectors.

                        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)

                        M 1 Reply Last reply Reply Quote 0
                        • M
                          Markadaca @Derelict
                          last edited by

                          @derelict How do I do that? I'm in Status -> System Logs -> System -> General
                          what would I filter by?

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            Look on the IPSec tab there. Errors will likely be evident just by reading it unless you have a few IPSec tunnels in which case they may be lost in the logging from that. Try restarting the problem tunnel and then immediately checking the IPSec log again.

                            Look for phase 2 issues such as those shown here:
                            https://www.netgate.com/docs/pfsense/vpn/ipsec/ipsec-troubleshooting.html#phase-2-network-mismatch

                            Steve

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

                              Thanks, it was a phase 2 no acceptable ENCRYPTION_ALGORITHM found message
                              Mismatched AES128 on one side and AES256 on the other.

                              Sorry for the thread-jack, I'll go away now.

                              1 Reply Last reply Reply Quote 0
                              • B
                                bpados
                                last edited by

                                I'm not seeing phase2 related errors.
                                1_1541785064291_2018-11-09 12_34_21-GW1- Status_ System Logs_ IPsec.png 0_1541785064290_2018-11-09 12_28_11-GW1- Status_ IPsec_ Overview.png

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

                                  That is all dead peer detection.

                                  Your Phase 2 looks like it is coming up.

                                  Obfuscating the private addresses makes it almost impossible to help you. Nobody cares what your private addresses are.

                                  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
                                  • B
                                    bpados
                                    last edited by

                                    Phase 2 been coming up for weeks now.
                                    0_1541786318274_2018-11-09 12_56_22-GW1- Status_ IPsec_ Overview.png

                                    1 Reply Last reply Reply Quote 0
                                    • stephenw10S
                                      stephenw10 Netgate Administrator
                                      last edited by

                                      Ok, so where are you actually sending traffic from?

                                      Does pfSense have an IP in 192.168.27.0/24? If so try sending some pings to any address in 192.168.97.0/24 from Diag > Ping using the 192.168.27.0/24 interfaces as the source. Those should definitely appear in the traffic counter as outbound packets even if there are no replies.

                                      Steve

                                      1 Reply Last reply Reply Quote 0
                                      • B
                                        bpados
                                        last edited by

                                        from 192.168.27.1 to 192.168.97.1 No traffic is showing/passing on IPSEC.

                                        PING 192.168.97.1 (192.168.97.1): 56 data bytes

                                        --- 192.168.97.1 ping statistics ---
                                        10 packets transmitted, 0 packets received, 100.0% packet loss

                                        1 Reply Last reply Reply Quote 0
                                        • stephenw10S
                                          stephenw10 Netgate Administrator
                                          last edited by

                                          You didn't select a source interface as I said otherwise it would show that. That traffic won't go over the VPN unless the source IP matching the local subnet selector.

                                          Steve

                                          1 Reply Last reply Reply Quote 0
                                          • B
                                            bpados
                                            last edited by

                                            Sorry Steve. I did overlook that request.

                                            PING 192.168.97.50 (192.168.97.50) from 192.168.27.1: 56 data bytes

                                            --- 192.168.97.50 ping statistics ---
                                            10 packets transmitted, 0 packets received, 100.0% packet loss

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