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

    IPSEC - ping goes out, can see the reply in Packet Capture on the WAN but not on the IPSEC side

    Scheduled Pinned Locked Moved IPsec
    4 Posts 2 Posters 817 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
      theshao
      last edited by

      Re-posting this question with a lot more detail as I still haven't been able to resolve the issue.

      I have an IPSEC site-to-site VPN. The P1 and P2 both establish fine, and I have an allow-all rule in the IPSEC Firewall settings that works for other VPNs on the same pfSense.
      For one VPN, to a Draytek endpoint, I see the following behaviour:

      P1 and P2 establish as expected:
      5ed65c3e-fea0-4942-acd4-1685a2272cc7-image.png

      If I run a ping from the local site (192.168.19.x) to the remote side (192.168.20.x), the following processes occur:

      • Logged in packet capture on the IPSEC interface going out:
      16:55:37.563917 (authentic,confidential): SPI 0xe9e0f9e3: (tos 0x0, ttl 127, id 5440, offset 0, flags [none], proto ICMP (1), length 156, bad cksum 7cb3 (->7db3)!)
          192.168.19.27 > 192.168.20.2: ICMP echo request, id 1, seq 8538, length 136
      
      • Counted on the "Packets Out" counter on the pfSense IPSEC Status page (as per image above)
      • Logged as a packet going outwards on the WAN interface on the pfSense, as verified with Packet Capture:
      16:54:47.563257 00:15:5d:01:7f:0a > ac:3a:67:73:84:51, ethertype IPv4 (0x0800), length 234: (tos 0x0, ttl 64, id 46696, offset 0, flags [none], proto ESP (50), length 220, bad cksum 0 (->be59)!)
          X.X.141.2 > X.X.213.186: ESP(spi=0xe9e0f9e3,seq=0x157), length 200
      
      • Counted on the "Packets In" counter on the IPSEC status at the remote site
      • Ping is received by the remote host, which replies (verified by packet capture at the remote host)
      • Reply counted on "Packets out" at the remote site IPSEC Status
        0fab949e-9c54-4f35-b88f-3183865ec7f8-image.png
      • Reply logged as a packet coming inwards on the WAN interface on the pfSense:
      16:54:47.587320 ac:3a:67:73:84:51 > 00:15:5d:01:7f:0a, ethertype IPv4 (0x0800), length 234: (tos 0x0, ttl 118, id 25759, offset 0, flags [none], proto ESP (50), length 220)
          X.X.213.186 > X.X.141.2: ESP(spi=0xc950859d,seq=0xd52), length 200
      
      • Reply NOT recorded in the "Packets In" counter on the pfSense IPSEC Status page (image above)
      • Reply NOT visible using Packet Capture on the IPSEC interface.

      I've checked the SPD/SAD section, and the routes are present as I would expect:
      42e4af0f-bb13-4820-b5ee-b3eedaf25f2b-image.png
      The other network on there (192.168.10.x) is another remote site, with the same config; this one works fine.

      So what seems to be happening is that for some reason IPSEC isn't grabbing/processing the return packet. It successfully intercepts the outbound packet, and routes it over IPSEC. The remote site receives the ping and replies. The pfSense receives the reply packet on it's WAN interface, but never passes this packet to the IPSEC service. Any suggestions as to what I can try to change, or what might be causing this? I'm suspicious of the remote router simply because another VPN on the pfSense with a config that's identical in every detail apart from remote subnet and remote host works fine, however these packet logs seem to suggest it's actually the pfSense that's not behaving correctly?

      G 1 Reply Last reply Reply Quote 0
      • G
        giulpip @theshao
        last edited by

        @theshao
        I've exactly the same issue. Were you able to solve the situation?

        T 1 Reply Last reply Reply Quote 0
        • T
          theshao @giulpip
          last edited by

          @giulpip
          Nope, I gave up and swapped the Draytek for a Microtik and reconfigured from the top. More generally I've moved over to OPNSense anyway.

          G 1 Reply Last reply Reply Quote 0
          • G
            giulpip @theshao
            last edited by

            @theshao in my case, maybe is also more complex: I'm simulating my tunnel future need, running one pfsense in an hypervisor, and the other one on a VM hosted on Azure. So a lot of things that maybe I haven't considered, like the NAT of my internet provider. I'll give a shot reproducing the setup with physical devices.

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