new pfsense firewall blocks many websites
-
Hi,
I have a new pfsense netgate 4100, the firewall all permissive (no rules yet) and many web sites are blocked by default:
Ex:
Dec 6 18:16:41 LAN 192.168.1.120:57232 104.18.39.73:443 TCP:ADec 6 18:17:55 WAN 192.168.1.254 224.0.0.1 IGMP
so sites like ikea.com, slack.com, and many others are refused by the firewall. I can go to google.com and netgate forum...
I see many people complaining the same and no real answers are given. What is the way to put the firewall permissive and then start adding rules?
thanks
Pierre -
@pirod What DNS servers are configured?
What is DHCP handing out?
How is pfSense configured to handle DNS?
There was a report earlier about slack and sites being blocked but it was tracked down to OpenDNS blocking it.
-
@rcoleman-netgate
thanks for replying. Not sure OpenDNS was for me. I don't have it.DNS are full automatic give by ATT router.
-
@pirod can you provide screenshots of your firewall rule tabs?
-
@pirod said in new pfsense firewall blocks many websites:
I see many people complaining the same and no real answers are given
Where do you see these complaints of the same thing? All of your blocks are out of state - they are ACKS, these are common to see in asymmetrical or when states have been reset do to say a loss of wan connectivity when you have pfsense set to reset states.
Your block of IGMP on your wan would be a given to be blocked and logged by the default rule on wan that blocks rfc1918 states, and just by the nature that nothing is allowed by default on the wan.. Why would you think IGMP being blocked would have anything to do with your issue?
IGMP would have zero use on pfsense wan that is for sure.. It is multicast..
-
@pirod Add the following to Status -> System Logs -> Firewall -> Normal View click on the wrench / spanner.
You'll get a description of the rule its failing on.
The last 3 log entires suggest you have a router connected to the internet then your pfSense router as the source IP address is in the RFC1918 range.
-
@gabacho4 said in new pfsense firewall blocks many websites:
can you provide screenshots of your firewall rule tabs?
+1 that one.
Look at the picture already included :
There is a USER created firewall rule called "Bock all IN".
Bock .....
@Pirod : serious ?
-
@gertjan wel ok, that was a test rule, but the issue is not related. I removed it again and still:
But as you see I can reply to this post on the forum. Google works. But a bunch of websites and apps are keeping to be blocked.
ERR_NAME_NOT_RESOLVED
Maybe a DNS issue but I tested even using google DNS.
The details on normal vue:
So I guess it is NOT the firewall preventing. But maybe more something related to how the WAN uses DNS from router from ATT?
-
@pirod A couple thoughts...
In your AT&T router, enable the Passthrough setting and select your pfSense, so your pfSense gets a public IP address.
In your pfSense DNS Resolver settings, uncheck "DNS Query Forwarding" and pfSense will resolve domains itself, without using AT&T DNS servers. (Unchecked is the default.)
Out of the box pfSense has only two rules, both on LAN, to allow from LAN to any (IPv4 and v6). So either additional block rules were added, or the problem is something else, like DNS.
ikea.com [104.108.110.251] is pingable...try pinging it by its IP address.
-
@pirod looks like a dns problem to me.. from this client what do you get when you do say from cmd prompt
nslookup www.ikea.com
$ nslookup www.ikea.com Server: pi.hole Address: 192.168.3.10 Non-authoritative answer: Name: e11632.x.akamaiedge.net Address: 104.114.25.189 Aliases: www.ikea.com san.ov11632.ikea.com.edgekey.net -
@steveits
Thanks for the reply. I changed to passthrough and DNS resolver was like you said.Still cannot ping site like idea.com:
-
Things ~should~ resolve either way, but since we're having issues I would at least test turning on the DNS Query Forwarding.
IIRC the docs don't mention it, but when off the system just spams the root dns servers instead of anything manually set. I don't consider myself fancy enough to bother the root dns servers.I feel like that last screenshot shows us getting worse ...
clearly some resolution happened, and that is a valid IP, but the pings should function. I just tested it myself as well as several others for ikea.I'm almost leaning toward modem mac filter, passthrough not functioning, or still just plain wrong WAN side setup with an incorrect subnet setup. Perhaps a static set IP but accidentally did wrong subnet?
-
@pirod Try a traceroute and see how far it gets. Also try the IP I showed above.
-
@pirod Its a setup problem.... not related to anything external.
Give me a teamviewer and access to tyour pfsense for 5 min and I will solve it for you.
-
@skogs said in new pfsense firewall blocks many websites:
I don't consider myself fancy enough to bother the root dns servers.
But you are.
When you decide to forward to some commercial data collector center, sorry, a DNS server like 1.1.1.1, you mandate them to 'bother' the root servers, as these are where your DNS request starts.. Because 1.1.1.1, 8.8.8.8 etc are resolvers.
So they will contact the root servers on your behalf.
Then they contact a TLD DNS server.
Then they contact a domain name server, who give you the answer of your request.So, why not, take the long road, do forwarding instead of your own resolving
And I'm not done yet : there is more : your local 'unbound', while forwarding or resolving, is also caching the results obtained.
Ones it knows from the root servers where it can find answers for "where are the dot com TLDs ?" it won't bother them anymore for do com requests (and dot net and dot org etc) as these are also cached.Results from the domain name servers are also cached.
And true, the 1.1.1.1, 8.8.8.8 etc are also caching.IMHO, if you have a question, and you have the choice to get the answers from the eye witness, or from some one who 'knows about it', who would you ask the question ?
Using the root servers, resolving, can give you a free bonus : when possible, it uses DNSSEC which guarantees you, that when you get an answer, it's a good answer, not a spoofed one. Forwarding means : you have to trust 1.1.1.1 or 8.8.8.8, as DNSSEC results are unknown to you.So, again, serious ? Doubting about 'do it yourself' or 'ask some one else' ?
You mentioned ikea.com. If you were resolving, this would be the result : https://dnsviz.net/d/ikea.com/dnssec/ so ikea.com is fully DNSSEC aware, so I (my resolver) will know that the answers, an A, AAAA MX TXT or NS record, are correct.
Btw : check your pfSense date and time. When it's not correct, DNSSEC will fail => DNS seems to fail.
-
@gertjan said in new pfsense firewall blocks many websites:
check your pfSense date and time. When it's not correct, DNSSEC will fail => DNS seems to fail.
This is a good point - but from his ping he tried to ikea.com did resolve.. So its not a dns issue on pfsense part.
It could be on his client having dns problem - maybe unbound isn't answering his clients? But that does not explain why his ping test from pfsense didn't work.
Would be a good test to see traceroute from pfsense to this ikea.com.. for example.
If fails with any, maybe change that to actual wan for interface to use as source.
Also is there any vpn in in play here - users tend to leave out important pieces of the puzzle all the time.. For all we know he is going out a vpn, and those sites don't like his vpn and don't answer..
edit: btw - he is not using IPv4 to talk to the forums? Only IPv6.. Possible piece to the puzzle in that as well.
so be curious to see if his ping test works when he uses IPv6
-
seems to be fixed!!
this was missing:
-
@pirod what did you have there?
Kind of hard to get to lots of the internet if you don't have any IPv4 address that is for sure.
www.ikea.com doesn't have IPv6 address.. Nor does www.slack.com
-
@johnpoz
was on static ipv4 I guess. Not sure why.Yes internet is not yet ful ipv6!
THANK YOU ALL for your patience!!!
-
@pirod said in new pfsense firewall blocks many websites:
was on static ipv4 I guess. Not sure why.
Well if it was static you would of had to have set the IP, etc It defaults to dhcp that is for sure.
BTW - still waiting for where you see all the complaints with no answers ;)
I see many people complaining the same and no real answers are given.
