@JonathanLee not sure what is not clicking here.. Yes if you use or some software uses a name be it a fqdn, or a host name or a mdns name or node name, etc it would have to resolve in some fashion, either some L2 discovery thing like mdns, or ssdp, etc. or just a simple old school LM host sort of broadcast for the name. But it sure isn't required if your just going to use an IP to access the service.. Now if your using some cert or something for the services your accessing the IP would need to be in the SAN, or your browser prob going to balk at you because the cert not valid for how your accessing it. But smb doesn't use that. I have no idea where he is coming with this statement of different IP.. I find it very hard to believe that this wifi router running a simple smb share is going to have more than 1 IP - one for the gui, or and one for the smb share. He feels like he has to hide his rfc1918 address, and not showing where he is finding the IP for the device, and or what IP is showing in his discovery of the dlna server his computer is showing him with that 8200 port.. But that IP isn't going to be different than the IP used for the smb share. He says he can access it now, this never had anything to do with pfsense in the first place - so I would consider this closed.

@Gcon Yes, sorry I didn't test it on a group, just on FLOAT, WAN and LAN pages One would have thought all the pages should behave the same.. Clearly when it is a group interface and I just tested that specifically now - it is acting as you say. I just tested specifically this on 2.7.2 test box. Seems like a bug. Still odd though, would have thought all the pages would behave the same, since they all calling the same page. with a parameter https://10.168.1.1/firewall_rules.php?if=FloatingRules https://10.168.1.1/firewall_rules.php?if=Test https://10.168.1.1/firewall_rules.php?if=wan https://10.168.1.1/firewall_rules.php?if=lan but clearly 1 of these things is not like the other 3. interesting enough that using the add below button, on any of the 3 still puts the rule at the bottom, on the "test" as you describe to the top it goes.. I vaguely recall from an issue that might be similar, in that the "index" of the rule you were attempting to add or delete wasn't the same as what appeared on the screen. Let me see if I can track that down And as I'm typing this the light went on (flickering candle really)- that issue was regarding Alias lists rm 14015- - this isn't an alias list but maybe somewhere in the code a group is using different method of loading/sorting/displaying the information. Something for someone to track down. Create a redmine issue is the only thing I can suggest for you. I'm not seeing an open one specifically.

@aclouden yeah reject would be a bad choice for external interface where your seeing noise from the internet, but internally its a better choice to be honest. edit: you can view your hidden rules for dhcp like this https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html [23.09.1-RELEASE][admin@sg4860.local.lan]/var/unbound: pfctl -sr | grep DHCP pass in quick on igb0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000002541 pass in quick on igb0 inet proto udp from any port = bootpc to 192.168.9.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000002542 pass out quick on igb0 inet proto udp from 192.168.9.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000002543 pass in quick on igb2 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000003591 pass in quick on igb2 inet proto udp from any port = bootpc to 192.168.2.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000003592 pass out quick on igb2 inet proto udp from 192.168.2.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000003593 pass in quick on igb4 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000004641 pass in quick on igb4 inet proto udp from any port = bootpc to 192.168.200.1 port = bootps keep state label "allow access to DHCP server" ridentifier 1000004642 pass out quick on igb4 inet proto udp from 192.168.200.1 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000004643 pass in quick on igb2.4 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000007791 pass in quick on igb2.4 inet proto udp from any port = bootpc to 192.168.4.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000007792 pass out quick on igb2.4 inet proto udp from 192.168.4.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000007793 pass in quick on igb2.6 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000008841 pass in quick on igb2.6 inet proto udp from any port = bootpc to 192.168.6.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000008842 pass out quick on igb2.6 inet proto udp from 192.168.6.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000008843 pass in quick on igb5 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000009891 pass in quick on igb5 inet proto udp from any port = bootpc to 192.168.7.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000009892 pass out quick on igb5 inet proto udp from 192.168.7.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000009893 pass in quick on igb3 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000010941 pass in quick on igb3 inet proto udp from any port = bootpc to 192.168.3.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000010942 pass out quick on igb3 inet proto udp from 192.168.3.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000010943 [23.09.1-RELEASE][admin@sg4860.local.lan]/var/unbound: Those are all the interfaces I have dhcp enabled on, zero rules set on my gui - dhcp works on all interfaces.

@buggz said in GRC Shields Up test result: I have ALL IPV6 settings disabled everywhere I can find them, router, pfsense, and clients to all client connection settings to pfsense. Shrug, I guess it is what it is and can't be changed due to the nature of the offering from T-Mobile. Why??? Why not use IPv6. I know T-Mobile uses it for their cell network, as do other cell companies. Same with many ISPs and content providers. I know some people don't want to admit it, but the world is moving to IPv6 and fighting against it is counter productive. You use VoLTE or VoNR (VoIP over 4G or 5G)? You're using IPv6. Do you have Comcast X1 TV? You're using IPv6 Do use the Internet with an Android or iPhone on 4G or 5G? You're using IPv6. Major content providers, such as Google, YouTube, Facebook and more provide content to users on IPv6, if they can. Anyone who thinks sticking with IPv4 is fine has their head in the sand. As an experiment, plug a computer directly into that Comcast box and see what addresses you get on it. If you see a public IPv6 address, you can use it on your network.

@g-ca13 ISP uses Microsoft server. To hand out DHCP addresses but unfortunately windows protocol messages are being sent on the same segment. Just a guess. Either way it’s being blocked which is a good thing

@mhank when you add a rule, its possible the rule is not placed correctly.. Where some other rule blocks it.. But that rule shouldn't be the default deny.. You don't have your own rule named default deny do you? Doesn't look like it because of the ID there ending in 103 pretty sure is the default deny ID.. Without looking at your full rule set and understanding the details of your specific source IP and what is in the tables its hard to guess what could be causing it. Just thinking off the top of my head here.. Lets say you had a port forward setup, these are evaluated before rules.. So if you had a forward setup that triggered, but there was no actual rule that matched the port forward. Then it would hit the default deny and fail. But if your IPs are just routed public, you should have no port forwards setup. Do you have any port forwards setup? For example if I had a port forward that trigged on destination port 5060, and suppose to send it to say 192.168.1.10.. And you don't have a rule that allows traffic to 192.168.1.10 that would fail and hit your default deny and be logged. So you could put rules in all day long for specific source IP to be allowed to say 1.2.3.4 behind your firewall. But the port forward would cause it to fail. Because it sees the traffic and says hey suppose to forward to 192.168.1.10.. Just a guess here, but would be curious if you do have any port forwards.

In front of the Pfense is the ISP cable modem. No MultiWAN. Nothing else. It was a one time ping. No states to 1.1.1.1 in the firewall table. No states resets or outages at this time. Maybe some sort of Smartphone guest on my WLAN, which was disconnected at this time. Nevermind, i have a huge amount of incoming connections, which pfsense blocks away. Thanks for the Explanations.

@jrey said in Not able to block facebook website: @Gertjan said in Not able to block facebook website: all the IP addresses and networks of Facebook will get blocked at the firewall level. Not entirely true All the IPs in their ASN will get blocked, however they also use (randomly) IP addresses that are not in their ASN (ie the leased space) here are a few of them associated with fb Correct. You're right. I won't try not to be funny here, but the best way would be : contact each large social media corporation and ask them for all their IPv4 (and IPv6) they use. Most will be 'in' their ASN they own. But they can (will !) use more then that. If I was working for them, I would do exactly that : using 'random' IPv4 (& IPv6) addresses so my clients can use my social media at any time. No one (read : pfSense admin) would be able to block the access. He'll try, and abandons soon as he'll understand what he tries to do. That's why "I want to block the bog ones' isn't really an issue. As it can not be done for 100 %. Blocking the big social networks can only happen if you have all ( ! ) the IPs they use. This list with IPs probably changes all the time. They will never give you this list, neither making it available to the public.

Have you all attempted to use the following custom patches Redmine#13984 This fixed a lot for me with Squid and Squidguard

@JonathanLee I used static port

@IMV8N It is a subtle difference but HA Net allows that subnet only. Any would allow any custom routed subnet behind HA Net (which has a different IP range and its own router not using NAT). 99% of the time they are functionally identical. 117 = open states/connections (click on it) 4.37 G = bytes.

@SteveITS For future reference... I also had to raise the max table size and that made the rule loading error go away. Also when adding new rules today, they were not applied until I had raised the max table size and reloaded.

@johnpoz said in What is rule (@4294967295)?: Do all your log entries other than rfc and bogon show that? Nope, log has been very quiet since I disabled logging of implicit default rules and my main firewall Netgate 6100 is behind 1100. These two 4294967295 entries are the first I've seen (that I remember, at least). I do get the info popup from older block entries, but nothing (empty) from the two pass entries.

@paoloposo Yep, that seemed to be my issue. I was too focused on the ping! I simply rebooted both my NAS and firewall and was able to access it via smb & ip. Thanks!

@Bob-Dig Resetting the state table was the answer. TY

@NotAHacker Such little mistakes may happen. But nice that you got it sorted.

@Bob-Dig Thanks and understood. I'll have a look at pfBlocker.