@viragomann Perfect, missed that one, thanks!

@cathal1201 Sorry, it looks like I'm a little behind on the timing of your responses and me typing mine.

Ok, so if that's not working, you can also make the opposite - a pass rule with the time frame you want the IP address to have access. But, in this case, you have to also setup a BLOCK or DENY rule immediately under it, no schedule, for the same IP address.

I'm gonna be honest, it's a little bit difficult to setup a schedule-based rule in pfsense, since it's a stateful firewall, and states aren't necessarily dropped like you/we are hoping. You have to try either one of these methods until you get one to work. In my opinion, it should be a lot easier than this, but it it what it is...

@peter247 when connecting routers there really should be a transit network (no hosts on this network) this prevents asymmetrical flow that can happen when you talk to devices that sit on the network between routers..

I have gone over this countless times... Here is old post with some drawings explaining the problem.

https://forum.netgate.com/post/865509

If you only have 1 router, pfsense and your networks all are connected to pfsense - then you don't have asymmetrical flow as long as these devices can not talk to each other in some other way that does not flow through pfsense.

I had the same issue after updating to 21.05.2.

For my use case the easyrule script is a somewhat critical need. I have never applied a manual patch on pfsense before, but this one was relatively easy.

I basically took the new easyrule script from the redmine, and dropped it in usr/local/bin. (replacing the previous easyrule). And it works fine now.

@hescominsoon without you showing us what you had done its not possible for us to know what you might have been doing wrong.

But to be honest inverted or ! rules are not how I would suggest you do it.

Allow what you want to the firewall, icmp, dns, etc. Then create a block rule with your rfc1918 alias, then below that an any any rule.

Here is an example set of rules. That prevent a vlan/network from talking to any other rfc1918 networks, and still allows internet

rules.jpg

! rules can work, and do - but there are some scenarios where they could be problematic, its just better to set explicit rules. Much easier to read and understand from a quick glance of your rules as well.

The block to "this firewall" prevents this vlan from accessing the web gui of pfsense on its wan IP, which quite often is public IP, and without that rule would be allowed via the any any internet rule.

I found the problem.

0089fae6-f2a8-405d-818d-8a40648a0bf7-image.png

The virtual machine can now access the internet.

@sp00ky

These :

33fef112-7eba-4b44-bd64-e8d63d6f9a9f-image.png

b2d7d122-5d86-4e34-a0fe-7293654ff378-image.png

If you suspect DNS issues, I advise you eliminate all third parties.

The first image : wipe them all. This is the default.
The second image : When checking "DNS server override" pfSene will use the DNS info received when establishing the uplink to your ISP. This means you'll be using the DNS servers that your ISP suggested. This method is what our ISP rouyters use, very popular in the past.

What pfSense does, out of the box : it resolves. This means that it uses one or more main root DNS servers. There are 13 of them. IPv and IPv6 The addresses are build in, as they are very fixed and static. These main servers know where to find all the com org net us, any known TLD name servers. All these tld servers are cloned all over the place, so there is always one near by. One goes down ? No problem, another one will do the job.
These tld servers maintain the domain name records that are accessible by the registrar : when you rent a domain name, the registrar writes into the tld the domain name and the domain name servers of your domain name. There must be at least 2 domain name servers. These domain name servers of a domain name can tell you (pfSense, your browser etc) what the IPv4 is for a given domain, what the MX is, the IPv6, or an alias, or whatever TXT field.

If you can not resolve spotify.com : use nslookup and siwth to trace mode, or use the console access on pfSEnse, and ask for 'why ?' :

Knowing that spotify is not a small player on the Internet, there must be an answer.
No or wrong answer means :
Your uplink is bad,
Your ISP has peering issues ?
Your ISP, or someone upstream, is changing your DNS requests ?
The resolver, unbound has issues ? ( check the pfSense resolver logs )
And last, but not least, facebook has learned us that even the big companies themselves can have 'internal' issues that removes the access to all of their own domain name servers.

The biggest bottleneck is always : your uplink - and anything close to that uplink.
pfSense, the resolver, on an average box, can handle you thousands of DNS requests and answers a second. These have to 'fit' over the uplink. Your ISP will route them then to the DNS server the resolver chose to work with.

This method is created, tested, by billions, and this is done over 30 or 40 years.

Of course, you could use some external DNS server, like 8.8.1.1 - or the DNS server of your ISP. Just say to yourself : why would do these servers exist, knowing that they cost (hundreds of) millions every year to maintain ?
8.8.1.1 is a resolver, just like the one pfSense uses. So my thoughts are : when doubt, use the shortest road, exclude all non needed factors.

Btw : I excluded local problems like a bad WAN interface of pfSense. You mentioned one domain name, and not overall bad 'access quality'.

@johnpoz said in traffic in wan:

And gain your "users" have no complaints of anything be slow or not working?

Exactly, nobody is complaining about anything and in the firewall you continue to see this type of traffic.

@bluesun, no I haven't.

@frodo problem is you don't know what disector to use, or you need to write one to be able to view the details of that payload you see there in DATA..

You would need help from the vendor, or you need someone that does that sort of thing.. That could be completely benign and be just some info in a json file, or it might not be..

With the noise for example I showed you there are lots of people that have dug into that and listing what is being sent, etc.

For that - You could try decoding it as different stuff in wireshark.

https://ask.wireshark.org/question/20679/how-to-decodedecrypt-udp-packet-data/

@silence They? :) I added one and one network range each time a new IP appeared and this managed to stop the attack already at pfSense. Since the traffic then didn't go to the heavy wordpress site, that solved the issue.

@droidus said in pfblcokerng-devel possible web gui bug?:

I tried that, and it still deselects from the other field.

Try Click by holding CTRL pressed.

@johnpoz excatly , so i can change the gateway in routing of this isp , and under interface assimgnets, change the ip ,and add the new gateway that was given by isp.

@bly I did see (only now) on LAN side I did put 'TCP' instead of 'any' in the protocol. That was the error...

@hfarinha forgot to mention that I had to add acl's manually as well under DNS resolver otherwise dns resolution does not work.

@ddbnj I personally do not have such rules on my lan side interfaces currently. I do have some log rules for some specific blocks and specific allows. But my sons haven't been teenagers in like 20 years (both in their 30s) and long gone from the home.. But I get your reasoning ;)

If I was needing to troubleshoot something where I need to see all blocks for sure, I would just toggle the default logging back on.. But sure you could do the same sort of rules on your lan side interfaces.

I personally am more interested in unsolicited inbound into the wan that is interesting.. Gives me an idea what major noise is going on right now - remember back awhile when those modems got compromised and were generating tons of traffic globally - that popped up to the top of my block list in the report.. Then there is always the common 80,443,22,21,3389, etc.