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

    Pings to Tunneled LAN Drop After 1 Packet

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 801 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.
    • S
      simple1689
      last edited by

      Hello! Been pulling my hair out trying to figure this out

      Main Office has IPSec to Satellite Office
      Main Office (10.1) pings pFsense Firewall on other end of VPN Tunnel (pFsense in Satellite Office, .30.1) without issue. All packets ping successfully.
      Main Office pings a NAS on Tunneled LAN (30.50) for 1 packet successfully. Remaining packets stop responding.
      Further Pings attempts from Main Office to Satellite LAN fail. After an undetermined amount of time, I can ping 1 packet successfully to any other LAN device and subsequent packets fail.
      Satellite Office can ping between offices without an issue

      Rules in Satellite Office:
      IPSec tab - Allowing any thing from IPv4
      LAN tab - Allowing any thing from IPv4
      WAN - (Currently blocking bogon Networks) + Rule to access Management Port on Firewall. Doesn't appear to have any other rule.

      I can't imagine being a Routing issue. Not a matter of duplicate IPs on LAN or a Device being offline. Any help would be greatly appreciated! Still trying to review logs to get a better idea of what is the issue.

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

        Hmm, seems that I cannot Ping LAN now

        Microsoft Windows [Version 6.3.9600]
        © 2013 Microsoft Corporation. All rights reserved.

        C:\Users\tcmrms>ping 192.168.30.1

        Pinging 192.168.30.1 with 32 bytes of data:
        Reply from 192.168.30.1: bytes=32 time=115ms TTL=63
        Reply from 192.168.30.1: bytes=32 time=119ms TTL=63
        Reply from 192.168.30.1: bytes=32 time=109ms TTL=63
        Reply from 192.168.30.1: bytes=32 time=111ms TTL=63

        Ping statistics for 192.168.30.1:
            Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
        Approximate round trip times in milli-seconds:
            Minimum = 109ms, Maximum = 119ms, Average = 113ms

        C:\Users\tcm>ping 192.168.30.50

        Pinging 192.168.30.50 with 32 bytes of data:
        Request timed out.
        Request timed out.
        Request timed out.
        Request timed out.

        Ping statistics for 192.168.30.50:
            Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

        C:\Users\tcm>

        
        ping 192.168.30.50
        
        Pinging 192.168.30.50 with 32 bytes of data:
        Reply from 192.168.30.50: bytes=32 time=1ms TTL=64
        Reply from 192.168.30.50: bytes=32 time<1ms TTL=64
        Reply from 192.168.30.50: bytes=32 time<1ms TTL=64
        Reply from 192.168.30.50: bytes=32 time<1ms TTL=64
        
        Ping statistics for 192.168.30.50:
            Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
        Approximate round trip times in milli-seconds:
            Minimum = 0ms, Maximum = 1ms, Average = 0ms
        1 Reply Last reply Reply Quote 0
        • C
          cmb
          last edited by

          Guessing you probably have a static route pointing to the LAN IP to force the box itself to source traffic to the VPN to the right IP. That sends an ICMP redirect that causes some Linux kernels to ARP that as a local subnet. System>Advanced, System Tunables, set net.inet.ip.redirect to value 0. Save and apply changes. Might need to reboot the NAS for it to lose the route it picked up.

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