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

    IPSec connection established and trafic is outgoing, but no ongoing response

    Scheduled Pinned Locked Moved IPsec
    25 Posts 3 Posters 3.2k 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.
    • K
      Konstanti @lmhaydii
      last edited by

      @lmhaydii The solution to the problem should be sought from Cisco side
      Ip packets in its party leave and do not return

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

        @lmhaydii
        Here's what it looks like to me
        15:59:50.636268 (authentic,confidential): SPI 0xc4b93af1: IP XX.XXX.70.141 > XX.XXX.236.39: GREv0, length 174: IP 192.168.1.96.51731 > 208.123.73.199.443: tcp 118
        15:59:50.856954 (authentic,confidential): SPI 0xc8365d06: IP XX.XXX.236.39 > XX.XXX.70.141: GREv0, length 56: IP 208.123.73.199.443 > 192.168.1.96.51731: tcp 0

        1 Reply Last reply Reply Quote 0
        • L
          lmhaydii @Konstanti
          last edited by

          @konstanti Thank you for your help, I will try from another server without NAT / BITANT and see if that will work

          1 Reply Last reply Reply Quote 0
          • L
            lmhaydii
            last edited by lmhaydii

            Hi again,
            After several attempts, I come back to you, maybe I can find a solution.
            I tried several configurations, but still the same issue : Tunnel connexion establisheed, telnet request go out, but can't catch the response. The responder server guys confirm that they are getting my requests and they return a response. But the response is lost somehwere and I can't determine where !
            I've tried all pfsense log level on IPSec advenced options : but found nothing that can help, except when setting Kernel Interface on highest I can see :
            (4_1547772896575_pfSense localdomain   Status  System Logs  IPsec.png

            This is a resume of my debbuging:
            the tunnel is up and request are going out :

            3_1547772896574_pfSense localdomain   Status  IPsec  Overview.png

            The connexion states are closed !
            2_1547772896573_pfSense localdomain   Diagnostics  States  States.png

            Packet captures with 0 bytes !
            1_1547772896573_pfSense localdomain   Diagnostics  Packet Capture.png

            And netstat with 0 packet error !
            0_1547772896572_pfSense localdomain   Diagnostics  Command Prompt.png

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

              If the reply is not arriving on your IPsec interface there is nothing you can do about it. They have to fix it on their side.

              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)

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

                @lmhaydii

                Tcp 0 is the SYN packet to establish the connection, this is normal .
                The bad thing is that the answer is not from the second side
                It is necessary to deal with the second side
                Ask them to show the answer log
                Can they ping your host 192.168.50.11 ?
                Can you ping their host 192.168.127.80 ?

                1 Reply Last reply Reply Quote 0
                • L
                  lmhaydii @Derelict
                  last edited by

                  @derelict thank you. How can I determine with certitude that thier response or thier request are not arriving to my firewall ? There is any command to show up that ?

                  K DerelictD 2 Replies Last reply Reply Quote 0
                  • L
                    lmhaydii
                    last edited by

                    @konstanti No they can't ping my host.
                    but my ping requests arrive to thier side, but I can't get any response from them

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

                      @lmhaydii
                      /diagnostics/packet capture /
                      interface wan
                      host - static ip address of second side
                      protocol esp
                      start
                      as a result , you should see if the answers come from the second host or not?
                      aaaa -> bbbb (esp)
                      bbbb-> aaaa(esp)
                      .....

                      In order for them to ping your host , a allow rule must be created on the ipsec interface

                      L 1 Reply Last reply Reply Quote 0
                      • L
                        lmhaydii @Konstanti
                        last edited by

                        @konstanti Thank you kontanti,
                        I've already add a rule on IPSec firewall rules to allow any to any.

                        Also, alredy trying to capture packet coming from thier side using wan and ipsec interface, but nothing !

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

                          @lmhaydii
                          It is necessary to understand cisco settings
                          Let him show log where you can see that esp packet went in the direction of your host

                          Perhaps they have an error in the acl settings
                          access-list 100 permit ip host 192.168.127.80 host 192.168.50.11
                          access-list 100 permit ip host 192.168.50.11 host 192.168.127.80

                          alternatively , the host 192.168.127.80 the default gateway is not Cisco , and the gateway knows nothing about the network 192.168.50.0/24.
                          Here you can come up with many versions . However, without knowing the network configuration, it is difficult to find a solution

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

                            @lmhaydii said in IPSec connection established and trafic is outgoing, but no ongoing response:

                            @derelict thank you. How can I determine with certitude that thier response or thier request are not arriving to my firewall ? There is any command to show up that ?

                            Yes. A packet capture. You have done that. That would be enough for me.

                            If you want more certainty, pcap on WAN for protocol ESP. You will see your pings (encrypted) go out but nothing come back from their side.

                            If you are going across NAT (NAT-T) you will need to capture UDP 4500 instead of protocol ESP.

                            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.