@rfinch23 said in pfsense default deny rule ipv4 1000000103: To my knowledge nothing has changed. This might be true .... but is really hard to do. You're saying : since I installed this firewall, I did not use new devices on my own networks, neither did I upgrade any of these devices .... If you did add just one new device, or updated just one, and this device 'crafts' internet packets that are 'wrong' (no big deal) then suddenly they start being captured by the final hidden block all rule. Now : knowing what I just told you, did you 'change' something ? I'm pretty sure you did ;) You can see the logs that show the "ipv4 1000000103" line, you have the offending IPv4. What happens when you remove this device from your network ? What is this device ? About : @rfinch23 said in pfsense default deny rule ipv4 1000000103: FreeBSD 12.2-STABLE (== 2.5.1) as Version 2.7.0 broke the tunnel. Read Netgate Will Migrate to OpenSSL 3 in pfSense Plus Software Version 23.09 which means things won't get any better soon. Example if a 'tunnel' uses encryption 'XXXX' and XXXX isn't supported anymore there will be a moment XXX won't work anymore on both side of the tunnel, for example : your phone app updates .... and now you're locked out.or your VPN supplier dropped old stuff : same result. It's way easier to stay 'current' - and yes, have some hassle ones in a while because you had to change 'SHA1' to 'SHA256' on both ends. But at that moment, thousands will have the same question as you, so answers will be available here. Keeping old stuff could mean you loose 'everything' and you have nothing to get back to.

@atlantakid I found how to add my URL but it is not reading it with "Update or Reload" from my local server, I can tell since I am watching the apache2 logs and there is not entry for reading that page!!, I had to go to the Firewall / pfBlockerNG / IP / IPv4, click on PRI3 and at then I can add to the bottom of the list. Looks like it can only pfsense can only look outside on open internet for the LIST and I have to figure out how to NAT that server request inward onto the LAN, I am getting this Error Failed to connect to 192.168.3.31 port 80 after 15017 ms: Timeout was reached Retry [2] in 5 seconds...

@left4apple said in Put IoT reject rules on WAN or LAN?: What would be the correct way to stop the traffic from getting into pfSense? As you already stated - on the lan side of pfsense.. Before it enters pfsense.. If someone came to your front door and said hey can I walk through your house to go to your back yard.. Would you stop right there at the front door, or would you let them stomp their muddy feet all through your house and then when they were going to exit your back door say - hey wait a minute I don't want you to go there..

@johnpoz said in pfSense propably blocking trafic from TP-Link Deco M9+ to WAN: If all your APs are wired, you don't need "mesh" you prob be better off just getting some cheap wifi routers and using them as AP.. at least then you could set the channels ;) Doesn't even look like these deco's support wpa3.. Seems like your pretty invested - but if you are wanting something more then plug it in and hope it works.. You should change to something else.. Yes, every AP is wired. I got the decos free from ISP - have not paid a single euro for them. I went into trap of people praising how easy they are work with... My pfSense is build on old industrial itx-motherboard running 3Gb and DualCore T7200 cpu. That I dug out from old equipment destined to rubbish bin, but it had 3 gigabit ethernet ports. It had 1.5Ghz Celeron Cpu but I managed to get a T7200 from China for 7€. Seem to be running at 10-13% cpu load even when there is pretty much traffic. Time will tell. [image: 1698597256788-463d9097-8fce-4e4c-9912-88a8ba0c9cec-image.png] I have mostly invested time for learning and creating physical network.

@SteveITS said in Gateway manually selected in firewall rule not enforeced? (preferential only): https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html#enforcing-gateway-use Yes, that is exactly what I needed! I guess I just don't know how to do research... I tried adding a block rule for the default gateway, but I couldn't get it to hit that rule. I didn't know about the checkbox in System>advanced. It works perfectly. Thank you!

If using that import button note there was a bad bug in 23.05 fixed in 23.05.1 (which would be in 2.7). It should exist on both.

@joejoe317 discovery isn't going to work across subnets/vlans.. Broadcast and Multicast is limited to the L2.. Now depending on the discovery method like mdns or ssdp, you could setup say the avahi or pimd packages.. Don't you know what your nas IP is? Set it up so you can use dns, mine is nas.home.arpa for example. If you have to resort to discovery for something - just put your client on the same network your thing you want to discover is on. C:\>ping nas.home.arpa Pinging nas.home.arpa [192.168.9.10] with 32 bytes of data: Reply from 192.168.9.10: bytes=32 time<1ms TTL=64 Reply from 192.168.9.10: bytes=32 time<1ms TTL=64

@Gertjan said in Unable to get OPT1 to work: unbound your local port 853 so it can handle DNS over TLS for your phones It will also do Doh, you just need to use some custom options.. Do phones really do DoT or wouldn't they being trying to do DoH.. Here is thread that came up about that. https://forum.netgate.com/post/1131273 It was pretty straight forward getting unbound to also do DoH. edit: btw I tried to see if could do DoQ to unbound.. And while its coming per this https://blog.nlnetlabs.nl/newsletter-dns-over-quic/ It doesn't seem to be available yet in the version of unbound we have on pfsense. Yet another way for devices to circumvent your local dns - atleast with DoQ its a different port at play vs DoH that uses your standard 443 port that everything else on the planet also uses..

@szsemla Changing the certificate or downloading it to trust on your clients does not remove the certificate warning which causes you browser to issue that warning. The DNSBL service blocks clients by DNS responses with the IP of the DNSBL Block site service. So regardless of which certificate is on there, the browser will issue a warning as the Common/SAN name of the certificate will never be the sitename the client actually was attempting to reach.

@Uglybrian @CommonSense @viragomann It may seem strange, but while I was entering the rules into this new firewall I felt that it was wrong to put the ports in "Source" instead of "Destination". But I said to myself "if they've been fine on other firewalls for over a year, they'll be fine here too". Instead, the feeling was right and I was the one who remembered it wrong. I always document everything, step by step; it was enough to go and read the notes from back then instead of memorizing. I apologize again.

Yes this worked! While I hate having to change at this low level, it's better than recreating the default block rules I guess. Thanks!

@NogBadTheBad Yep, you are correct. I think something got very confused when it was in the same (but not the same considering the /24) 10.x.x.x. I just changed all my own equipment to 192.x.x.x and now its working. Still weird though. But thanks for all your help anyway :)

@SteveITS said in Another "OPT1 Problem": On the DNS Resolver settings page there is a circle-arrow button at the very top to restart the service, which may have also worked but after saving that page pfSense should have shown an Apply button, did you click Apply? Yes, I clicked "Apply" right after clicking "Save". One way or another, it worked out. Thanks. for the explanation.

@ama This [image: 1698128286216-aa11ab0f-2576-4d25-a308-f6795d1b58a2-image.png] is just incoming ICMPv4 traffic/packets - not your traffic goint to the "Internet" and coming back. Look at my ICMPv4 WAN rule : [image: 1698128354546-2b62ba07-6fed-4989-9fa9-8223348ba01e-image.png] This can only be incoming ICMPv4 traffic and is not related to my ordinary "LAN to Internet (and back)" traffic Wan port blocking internet access The subject line is awkward. Router firewall pfSense interfaces can block incoming traffic. Look (physical) at the WAN port, or any other (LAN) port. Firewall rules apply to traffic going into (into pfSense), not at traffic that comes out of the interface. What boils down to : WAN firewall rules - or the absence of - can't block "internet access". Only the "Floating" interface has that power. Anyway, all this just to be sure, you probably know already all this. Next thing to check : System > Routing > Gateways is ok ? The routing table ( Diagnostics > Routes ) looks ok ?

@johnpoz Ok :) Work-around in place (the /32 thing also worked), thanks for the help!

@johnpoz thank you that worked

@itsw I just wanted to share my.... "findings" with you ;-) If one takes over a project from another contractor, always make sure to get as much of documentation as possible. The gateway address on LAN and DMZ were on .254, the gateway address for the MANAGEMENT was on .1 everything was working as intended from the start, but the hosts in management network did not pass the traffic bc of wrong gateway.