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

    I can't ping 8.8.8.8 but I can 8.8.4.4

    Scheduled Pinned Locked Moved
    General pfSense Questions
    2
    8
    1.5k
    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.
    • IsaacFLI
      IsaacFL
      last edited by

      I have my pfsense router working with everything, but for some reason I cannot ping 8.8.8.8 but can ping 8.8.4.4 (and anything else I try).

      I found by searching that someone else had the same issue I have, and they reinstalled the router was the only way to fix it.

      https://www.reddit.com/r/PFSENSE/comments/7qcj2g/cant_ping_8888_from_lan_or_router/

      If I use the Diagnostic/Ping and use WAN as the source address I get:

      PING 8.8.8.8 (8.8.8.8) from 75.85.209.12: 56 data bytes
      64 bytes from 8.8.8.8: icmp_seq=0 ttl=122 time=27.232 ms
      64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=17.767 ms
      64 bytes from 8.8.8.8: icmp_seq=2 ttl=122 time=17.798 ms

      --- 8.8.8.8 ping statistics ---
      3 packets transmitted, 3 packets received, 0.0% packet loss
      round-trip min/avg/max/stddev = 17.767/20.932/27.232/4.455 ms

      If I use LAN as the source address I get:

      PING 8.8.8.8 (8.8.8.8) from 192.168.10.1: 56 data bytes
      36 bytes from localhost (127.0.0.1): Time to live exceeded
      Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
      4 5 00 0054 e229 0 0000 01 01 0000 192.168.10.1 8.8.8.8

      36 bytes from localhost (127.0.0.1): Time to live exceeded
      Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
      4 5 00 0054 42cd 0 0000 01 01 0000 192.168.10.1 8.8.8.8

      36 bytes from localhost (127.0.0.1): Time to live exceeded
      Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
      4 5 00 0054 c762 0 0000 01 01 0000 192.168.10.1 8.8.8.8

      --- 8.8.8.8 ping statistics ---
      3 packets transmitted, 0 packets received, 100.0% packet loss

      It seems to be doing some kind of redirection.

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

        TTL exceeded is usually a routing loop. You route to 8.8.8.8 out somewhere and that packet comes back to you somehow. The TTL exceeded is coming from localhost.

        I would look at the output from the following command executed in Diagnostics > Command Prompt:

        grep -A5 -B5 "8.8.8.8" /cf/conf/config.xml

        That will show you all occurrences of 8.8.8.8 in the config file with 5 lines on either side.

        It is probably defined as a name server with a gateway, a gateway monitoring target, or something else that is establishing a host route for traffic to that address that is not performing as you expect it to.

        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)

        IsaacFLI 1 Reply Last reply Reply Quote 0
        • IsaacFLI
          IsaacFL @IsaacFL
          last edited by

          If I ping 8.8.4.4 with LAN as the source address, I get:

          PING 8.8.4.4 (8.8.4.4) from 192.168.10.1: 56 data bytes
          64 bytes from 8.8.4.4: icmp_seq=0 ttl=122 time=17.768 ms
          64 bytes from 8.8.4.4: icmp_seq=1 ttl=122 time=17.935 ms
          64 bytes from 8.8.4.4: icmp_seq=2 ttl=122 time=18.230 ms

          --- 8.8.4.4 ping statistics ---
          3 packets transmitted, 3 packets received, 0.0% packet loss
          round-trip min/avg/max/stddev = 17.768/17.978/18.230/0.191 ms

          I suspect it is related to OpenVPN, since the link I posted also had open OpenVPN installed. But the other packages I have installed are: pfBlockerNG, nut, Avahi, and OpenVPN-client-export.

          IsaacFLI 1 Reply Last reply Reply Quote 0
          • IsaacFLI
            IsaacFL @Derelict
            last edited by

            @derelict that gave me:

            		<gateway>dynamic</gateway>
		<name>RW_VPN_VPNV4</name>
		<weight>1</weight>
		<ipprotocol>inet</ipprotocol>
		<descr><![CDATA[Interface RW_VPNv4 Gateway]]></descr>
		<monitor>8.8.8.8</monitor>
	</gateway_item>
	<gateway_item>
		<interface>opt4</interface>
		<gateway>dynamic</gateway>
		<name>RW_VPN_VPNV6</name>

            It looks like when I set up the gateway for my vpn I used 8.8.8.8 as the monitor IP.

            1 Reply Last reply Reply Quote 0
            • IsaacFLI
              IsaacFL @IsaacFL
              last edited by

              @isaacfl It is related to they gateway entry.

              I changed the monitor IP from 8.8.8.8 to 8.8.4.4 and now I can ping 8.8.8.8 but not 8.8.4.4

              IsaacFLI 1 Reply Last reply Reply Quote 0
              • IsaacFLI
                IsaacFL @IsaacFL
                last edited by

                0_1534908216091_Capture.PNG

                IsaacFLI 1 Reply Last reply Reply Quote 0
                • IsaacFLI
                  IsaacFL @IsaacFL
                  last edited by

                  I just noticed that the IPv6 address is acting same way. Monitor IP cannot be pinged.

                  Looking in my Routing Table, I can see that 8.8.4.4 (I changed it for testing) has as its gateway, 192.168.70.1, which is my VPN subnet. Not sure how I did that. Same thing in my IPv6 routes.

                  IsaacFLI 1 Reply Last reply Reply Quote 0
                  • IsaacFLI
                    IsaacFL @IsaacFL
                    last edited by

                    I seem to have gotten it working. Not sure, but it was the gateways for the OpenVPN was messed up. Between fiddling, with settings in OpenVPN and restarting the service, it seems to have fixed itself.

                    As far as I can tell, I didn't change any settings, but what seem to fix it, was switching the vpn subnet addresses, then switching them back, seemed to fix itself. ??

                    Regardless it is working properly now.

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