I can't ping 8.8.8.8 but I can 8.8.4.4

IsaacFL

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.

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.

IsaacFL

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.

IsaacFL

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

IsaacFL

@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

IsaacFL

IsaacFL

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.

IsaacFL

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.