Pings to Tunneled LAN Drop After 1 Packet



  • 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.



  • 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


  • 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.