Diagnosing can't ping out



  • Just had an issue with a remote site. Can someone help me understand what happened?

    Remote site has pfSense (Netgate 3100) connected to cable modem (modem in bridge mode - no routing)
    Computer at remote site was not able to reach the internet (user told me this by telephone)
    I was able to connect to remote pfSense using openVPN client
    On remote pfSense I see:
    - DNS servers look right (8.8.8.8, 8.8.4.4)
    - WAN interface up, has correct IP from ISP
    I try Diagnostics > DNS Lookup > google.com
    - Fail
    I try Diagnostics > Ping > 8.8.8.8
    - Fail (Time to live exceeded)
    In Diagnostics > Ping I change Source Address from Auto to WAN and ping 8.8.8.8 again
    - Success!

    As we had a 15 minute time window to get the system back up before a critical user was leaving the site I did Diagnostics > Reboot and crossed my fingers.

    In 3 minutes the sytem was back up and working fine.

    What happened? How could I have diagnosed further before resorting to a reboot?


  • LAYER 8 Netgate

    @axxxxe said in Diagnosing can't ping out:

    I try Diagnostics > Ping > 8.8.8.8

    • Fail (Time to live exceeded)

    That is generally a routing loop. Probably a problem upstream.



  • Would an upstream routing loop be resolved by rebooting the pfSense box?


  • Netgate Administrator

    It would if pfSense had decided it's default route was out the LAN.

    Do you have a gateway configured on the LAN subnet? If so make sure the default gateway is set to the WAN rather than automatic in System > Routing > Gateways to avoid any possibility that pfSense chooses the LAN as default if the WAN goes down.

    Steve



  • No gateway on the LAN subnet, at least as far as I understand the question.

    In System / Routing / Gateways I see a list of 2 Gateways:

    WAN_DHCP (default)
    OVPN9194

    But I am at the moment connected over the VPN. I was NOT connected over the VPN when the system went offline in the middle of last night.


  • LAYER 8 Netgate

    What happened? How could I have diagnosed further before resorting to a reboot?

    Probably packet captures to see what was actually going out WAN.

    Evaluating the routing table to see what the state of the network was at the time.


Log in to reply