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.
    • 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
          • GrimsonG
            Grimson Banned
            last edited by

            Might be a shot into the dark, but what are your firewall rules for IPsec? Did you add rules for the new tunnels?

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

              Ok so that target may not respond to pings or is blocked etc but did you see 10 packets on the Phase 2 status outbound?

              Traffic from the firewall itself should always be allowed out across the tunnel. Unless you have specific blocking 'OUT' floating rules.

              Steve

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

                at this point for testing I have a very open rule set on both ends.
                As for traffic It doesn't even display the phase2 for ipsec tunnels

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

                  Your screenshot above shows the Phase 2 as established but the traffic counters show 0 packets in or out. After running that ping it should show 10 packets out.

                  Steve

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

                    I know but it doesn't.

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

                      Please run the ping test again and post another shot of Status > IPsec with the phase 2 expanded. Thanks.

                      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)

                      S 1 Reply Last reply Reply Quote 0
                      • S
                        sgw @Derelict
                        last edited by sgw

                        @derelict
                        another thread-hijacker here:
                        I see issues on a tunnel between my 2.4.4 SG-1000 and a remote SG-3100 on 2.4.3-p1 still.

                        tunnel comes up, no traffic goes through .. no ping via shell, nothing seen in Status page.

                        disabled that new async-option, checked and upgraded strongswan (on SG-1000), re-saved tunnel configs, restarted IPSEC ... I will disable other tunnels and check back with a screenshot or so.

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

                          If you know you're hijacking why not just start another thread?

                          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)

                          S 1 Reply Last reply Reply Quote 0
                          • S
                            sgw @Derelict
                            last edited by

                            @derelict said in IPSec tunnel - No traffic:

                            If you know you're hijacking why not just start another thread?

                            because it might be the same issue/bug and it will be easier to search for that ... ? sorry

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

                              ipsec statusall
                              Status of IKE charon daemon (strongSwan 5.7.1, FreeBSD 11.2-RELEASE-p3, arm):
                                uptime: 59 seconds, since Nov 13 19:49:59 2018
                                worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
                                loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf curve25519 xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock counters
                              Listening IP addresses:
                                62.40.171.237
                                172.32.99.254
                                2001:470:6f:333::1
                                172.32.99.97
                                192.168.100.1
                                2001:470:6e:333::2
                                172.31.91.1
                              Connections:
                                 bypasslan:  %any...%any  IKEv1/2
                                 bypasslan:   local:  uses public key authentication
                                 bypasslan:   remote: uses public key authentication
                                 bypasslan:   child:  172.32.99.0/24|/0 2001:470:6f:333::/64|/0 === 172.32.99.0/24|/0 2001:470:6f:333::/64|/0 PASS
                                  con13000:  62.40.171.237...89.221.HIDDEN.IP  IKEv2, dpddelay=10s
                                  con13000:   local:  [62.40.171.237] uses pre-shared key authentication
                                  con13000:   remote: [89.221.HIDDEN.IP] uses pre-shared key authentication
                                  con13000:   child:  172.32.99.0/24|/0 === 172.20.95.0/24|/0 TUNNEL, dpdaction=restart
                              Shunted Connections:
                                 bypasslan:  172.32.99.0/24|/0 2001:470:6f:333::/64|/0 === 172.32.99.0/24|/0 2001:470:6f:333::/64|/0 PASS
                              Routed Connections:
                                  con13000{1}:  ROUTED, TUNNEL, reqid 1
                                  con13000{1}:   172.32.99.0/24|/0 === 172.20.95.0/24|/0
                              Security Associations (1 up, 0 connecting):
                                  con13000[1]: ESTABLISHED 33 seconds ago, 62.40.171.237[62.40.171.237]...89.221.HIDDEN.IP[89.221.HIDDEN.IP]
                                  con13000[1]: IKEv2 SPIs: c7032e2b0033885b_i* 6f31cd51da0db2d3_r, pre-shared key reauthentication in 7 hours
                                  con13000[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
                                  con13000{2}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c4103760_i cc791808_o
                                  con13000{2}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i (0 pkts, 33s ago), 0 bytes_o (0 pkts, 33s ago), rekeying in 44 minutes
                                  con13000{2}:   172.32.99.0/24|/0 === 172.20.95.0/24|/0
                              

                              I masked the WAN-IP of the SG-3100 ... looks good to me aside from traffic going through.
                              Same tunnel worked already earlier today ... I can log in to the SG-3100, ping to WAN is fine.

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

                                The only bug in play is what looks like issues in the async crypto in yet-to-be-identified edge cases.

                                Everything else is almost certainly misconfiguration.

                                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
                                • DerelictD
                                  Derelict LAYER 8 Netgate
                                  last edited by

                                  Looks fine. How are you testing?

                                  Did you install any policy routing on the LAN rules?

                                  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)

                                  S 1 Reply Last reply Reply Quote 0
                                  • S
                                    sgw @Derelict
                                    last edited by

                                    @derelict no, I did not. So far I ping from pfsense and my system behind.
                                    You know what? Now that I stopped IPSEC completely after disabling everything execpt that one tunnel ... waited some minutes and started the IPSEC service again, it starts pinging again.
                                    I will monitor this for the next few days .. Thanks so far.

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

                                      When you ping from pfSense you have to be sure to source it from something interesting to IPsec. Use the -S flag or the Source address pulldown in Diagnostics > Ping.

                                      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)

                                      S 1 Reply Last reply Reply Quote 1
                                      • S
                                        sgw @Derelict
                                        last edited by

                                        @derelict said in IPSec tunnel - No traffic:

                                        When you ping from pfSense you have to be sure to source it from something interesting to IPsec. Use the -S flag or the Source address pulldown in Diagnostics > Ping.

                                        will do, thanks. So far I mostly tested from my laptop (within LAN).

                                        S 1 Reply Last reply Reply Quote 0
                                        • S
                                          sgw @sgw
                                          last edited by

                                          To be fair and maybe even help others here additional information:

                                          It turned out that my local docker-installation sometimes used a subnet 172.20.0.0/16 that overlapped the subnet behind the pfsense-IPSEC-tunnel to my customer. So this lead to routing tables on my local machine pointing "somewhere else". The IPSEC-tunnel was working all the time. Thanks anyway.

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

                                            Thanks for coming back with the note.

                                            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.