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.9k Views 5 Watching
    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 Offline
      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 Online
        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 Offline
          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 Offline
            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 Online
              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 Offline
                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 Online
                  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 Offline
                    bpados
                    last edited by

                    I know but it doesn't.

                    1 Reply Last reply Reply Quote 0
                    • DerelictD Offline
                      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 Offline
                        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 Offline
                          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 Offline
                            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 Offline
                              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 Offline
                                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 Offline
                                  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 Offline
                                    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 Offline
                                      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 Offline
                                        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 Offline
                                          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 Offline
                                            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.