@rasputinthegreatest normally hosting stuff on big cdn networks is not cheap - and would assume they do some vetting of what is being hosted/served. Not saying stuff can not be compromised - but seems unlikely some malware people would choose to host their crap there to be honest. While that cdn is not a global player to the likes of aws/azure or clouldflare, etc. They are not a ma and pop vps hoster ;)

Glad you got it figured out - and this thread might be very helpful for the next guy.

You can, potentially, add a custom 'view' in unbound so that only a subset of client devices get a bad resolution for *.facebook.com. It's a non-trivial setup but there are some threads here detailing it.

When trying to create a new alias

191bae4d-2656-4879-8daa-aa137eded74b-изображение.png

I receive this message

06486e52-abeb-4c71-b629-e24ac3643f03-изображение.png

The list of aliases now looks like this:

943f2dc2-2f46-4fb3-a21c-eed29df812de-изображение.png

The contents of aliases are not displayed.
But they should be.
When editing an existing alias, list items are not displayed

cb575d9c-7f50-4e70-a47a-5712990ae298-изображение.png

There is such an alias with a list of hosts in the configuration

6d834b82-7ca8-4905-bfb0-f11e04e8757b-изображение.png

@Gertjan

I figured it out. It was my old IPSEC tunnel. It was capturing the traffic, so the rules never really impacted the traffic. Once I removed the IPSEC tunnel, the rules started working, as mentioned.

@viragomann Yes, actually, I made Allow any to any rules for all interface including bridge interfaces for testing. I wanted to see traffics going right direction and compare what I expected.
However, after I provides IP address to bridge, I'm getting less information from firewall.

From the firewall state, (PC-B to PC-A)
[Any 10.10.40.4 -> 10.10.30.3 SYN_SENT:ESTABLISH]
BRG2 10.10.40.4 -> 10.10.30.3 SYN_SENT:ESTABLISH
BRG1 10.10.40.4 -> 10.10.30.3 SYN_SENT:ESTABLISH

However, I found two solutions.

Creating rules in floating tab with enabling quick Make BRG1, BRG2 as a one interface group and creating rule.

I have no idea why those can be the solutions but seems like there's something related rule priority.

Thank you for taking care of my issue.

@johnpoz

Many thanks for the help, advise and comments noted.

Thanks again.

CC

@chris-doldolia Hello! You can safely make configuration changes on a running pfSense firewall, it's designed for that. Most settings apply immediately without needing a reboot, though some services (like IPsec, OpenVPN, or interface changes) may briefly interrupt traffic when restarted. Just make sure you have console or alternate access in case something goes wrong.

@johnpoz I am glad you also noticed it, I see it a lot on my proxy I decided to block it and see what breaks but nothing changed so far. I also have the DNS manually set on the iMac, so it should not attempt to use DoH

@Gertjan @JonathanLee ,

I appreciate your comments and your time for this.

I found that our ISP modem keeps sending login page when it thinks connection state is not made properly. (From development tool, I was able to see '302 Found - too many redirects')

The issue of this was NAT, because when my IP NATing to interface IP, source port kept changing as well.

I have created NAT rule with static port enabling, and it resolved my issue.

Thank you very much.

@CatSpecial202 The traffic is not being blocked because it is considered part of the RFC1918 space. Your rule is not a block rule, but rather a PASS rule (!RFC1918).
The traffic is blocked by your rule though - but thats because the IGMP multicast packets that was intended to be passed by the rule has IP options enabled that the default IP options filtering in the rule denies. Hence it blocks the traffic. Seach for IGMP filtering blocks traffic on this forum to understand the problem and configure your rule accordingly.

Fx: this thread https://forum.netgate.com/topic/187896/how-to-stop-logging-blocked-lan-igmp

Remove potential filter apk

@KOM Many Thanks for the reply ! ...good to know...

@CZvacko to be honest have no idea what would cause that.. But I don't have anything on my network doing ws-discovery either (ssdp).. At least not to ipv6 multicast..

It appears after more digging I found my fix. Sort of my fault In a way. I noticed in the command above that my rules that were being applied from the webgui were not showing on the backend rules. After scratching my a head a while, I looked at pfblockerng and noticed it was creating a lot of table IP entries and erroring due to limit. I did enable Geo and IP blocking which would created massive lists and due to this getting stuck it wouldn't write my firewall changes down. So I have adjusted the list limit and audited the IP lists I have enabled, and my rules are now showing.

@Spiney ip options is not his issue that is for sure.