Unable to ping 1.1.1.1 and 8.8.8.8 from LAN all other pings work
-
Pings to specific IP addresses (such as 1.1.1.1 and 8.8.8.8) from the LAN are being blocked. I'm able to ping other IP addresses such as 208.67.220.220 without problem. So it's not a outgoing ICMP blocking rule.
I don't have any rules blocking these address and they are not being blocked by my upstream internet provider.
If I go into diagnostic->Ping and ping 1.1.1.1:
--from the WAN port it works fine
--from the LAN port I get a timeout (100% packet loss) -- but pinging other addresses work fineOnly places I see these addresses in the firewall was on System->Routing->Gateways where I had 1.1.1.1 and 8.8.8.8 as the monitoring addresses. I changed those addresses to something else and reloaded.
Suggestions?
-
@klubar I think pfblocker can block those depending on what lists your using. Do you have pfblocker rules?
-
Using PFSense I did a packet capture and looked at it in wireshark.
The failed packet (to 1.1.1.1) is getting a "No response seen] so perhaps the reply is being dropped.
A ping to 208.67.220.220 is returning Date (40 bytes) as expected.
Somewhere it looks like the reply is being lost.
-
@klubar so you sniffed on your wan and you saw it go out.. Or you sniffed on lan side?
That has to be your lan side the source IP is 192.168.100.41 - so no if that went out your wan you would never get a reply. So pfblocker could be blocking it from going out your wan.. Sniff on your wan to see if its leaving pfsense.
here is old thread where pfblocker was blocking to 8.8.8.8
https://forum.netgate.com/topic/157342/pfblocker-blocks-8-8-8-8
-
@johnpoz thanks! but not using that package.
-
@klubar ok other option if if you were routing out a vpn, 8.8.8.8 and 1.1.1.1 might not like the vpn IP..
I would sniff on your wan while you ping 1.1.1.1 do you see it go out, then its upstream.. if you don't see it go out then pfsense is not sending it for some reason, rule.. Or its going out not natted for some reason, again setting on pfsense.
But sniff on wan will tell you were it its failing right away.
-
One more clue ... looking at Diagnostics -> Routes I see the address 1.1.1.1 and 8.8.8.8 listed ... they seem out of place with the other addresses in the list:
If this is the issue how do I remove them from the route table (they are NOT manually added anywhere, that I know of).
Thx
-
@klubar do you have those set for dns? Do you allow dhcp to override dns? yeah trying to go to either of those would send it out whatever that link#5 is, interface ix2
-
I've looked in the following places:
System -> General Setup:
DNS servers are set to 103.247.37.37 and 103.247.36.36 (1.1.1.1 was listed here, but I removed it & saved)
DNS Server Override is NOT checked
DNS Resolution Behavior: Use local (127.0.0.1), fall... (Default)DHCP Server:
DNS servers: 192.168.10.13, 192.168.10.15 (our local caching dns servers)
Static mapping: one device did specify 1.1.1.1 and 8.8.8.8 as DNS server, now set to blankIs there someplace I should be looking? Or is there someway to force the routes to reload (short of rebooting?)
-
@klubar I would also look here.
What exactly is that interface ix2?
edit: oh my bad, missed that you clearly state its not checked.. doh! So what is that ix2 interface?
Do you have a vpn - when you setup a vpn, it can be set to pull routes from the server your connecting too.
-
We are running OpenVPN server, but not connecting to anything as a client... so it's unlikely that the VPN is the issue.
I boldly (or foolishly) executed:
route delete 1.1.1.1
in the command window which removed the 1.1.1.1 route from the listing (8.8.8.8 is still there). I don't know if this will reappear on a reboot, but for the time being I can ping 1.1.1.1.
Why do I care? I have a somewhat braindead security appliance that tries to ping 1.1.1.1 and 8.8.8.8 to see if it is connected to the internet so that was failing. Now it is happy as one of the pings succeed. Not naming names, but it starts with a U.
-
@klubar well I would just delete the other route as well to see if they come back. The only thing that I recall where routes like that would be set is if had set dns per interface. With the gateway, see my dropdown that says none above.. And I thought that if you allowed dns to be overriden by dhcp it could add a route there too
Maybe one of those things is where they got added, but never got deleted.. I would just delete the other route, and make sure next time you reboot that they don't come back.
Are they using dns to resolve what they should ping to see if hey have internet? Not a fan of company XYZ using some other service to check if your device you sell has an internet connection.. And you sure and the heck shouldn't hard code IPs.. If you want to check if your device you sell to people can get to the internet it should use what ever dns was provided to your device by either dhcp or set on it and look up some fqdn that you the company controls.. If you then want it to ping that IP, it should be pinging your resource not some other companies IP..
NTP is in line with this as well - if you making a device that will want/use ntp.. And you want to point it to the ntp pool, then get with ntp org and get your own vendor fqdn.. And if your just going to point to ntp in general, don't for F sake point to your country code..When the device is going to be used in different country..
I had one of those smart wifi plug things, still do actually just use it when put out the xmas lights. But clearly the thing is not going to be used in the UK.. We use different power plugs, so there is no freaking way I bought this in the uk and just using it in the us.. But it wants to check its time with the uk.ntp pool.. So I created a host override for what is was looking for..
Just pure laziness if you ask me, or they are hiring the cheapest developers they can hire? Or they have some developer and said hey make this work by tmrw we need to start shipping them out next week.. And failed to even give him any parameters or where it might be used.. Hey have it check ntp time while your at it ;)
My other pet peeve is these iot devices that have zero dns cache.. Ok we know you want to talk to fqdn xyz.. But do you really need to ask dns every 2 seconds for it, when you were just given the answer 10 seconds with a ttl of 24 hours ;) I mean it takes really nothing to store the dns record for the next time you want to go there in 2 seconds.. You don't have to store 10k records you need to store the handful you might be wanting to talk too..
Well now I have just gotten off on a rant, sorry ;)
