@SteveITS Still odd that it seems to KNOW it is in Canada and I did not see the IP range that was being blocked in the list... Oh well, it is working so that is good. Cheers,

@tknospdr said in How to read FW rules in plain English: Packet arrives to my WAN interface and says "I'm here to see PUBLIC_IP in apartment 3290. NAT rule says, "Hmm they're actually looking for 192.168.2.2 in apt 32400, but before I send them on their way, let's see if the doorman will allow it" Doorman says "My rulebook says packets from PUBLIC_IP visiting 2.2:3400 are welcome here" Close ! This order : Packet arrives to my WAN interface and says "I'm here to see PUBLIC_IP in apartment 3290. Doorman says "My rulebook says packets from PUBLIC_IP visiting 2.2:3400 are welcome here" NAT rule says, "Hmm they're actually looking for 192.168.2.2 in apt 32400, but before I send them on their way, let's see if the doorman will allow it" Where doorman = the WAN firewall rule (created by the NAT rule). So, first, an incoming packet has to be allowed by this fire wall rule. The packet can now enter the router and the attached NAT rule will kick in : it will replace the source IP of the packet with the destination IP for the local LAN IP, like 192.168.1.22. If needed, the original destination port number can also be changed, but this is optional. In your case it was originally '32400' and it sated '32400'. The NAT rule (and firewall rule) is statefull : the answers from the traffic going to 192.168.1.22 will get remapped in reverse, so a bidirectional data stream can take place.

Your comment gave me the bug..., I double-checked my LAN host conf and found out that on the LAN host, there was a static route that was sending packets to the LABO network using the wrong gateway... I'm really sorry to have taken your time for such a stupid thing... thank you very much for your time and your help...

Fixed once i disable log packets default block rules i could then disable passed rules reset log files ;)

For the sake of completeness for future search results... I had an empty interface on my pf box so I brought it up as a separate subnet and moved my TrueNAS server onto it. I updated my firewall alias to point to the new IP address, pointed the other internal subnets' forwarding rules back to the alias, put my split horizon DNS rules back in place, and everything is working as it should. I know it's academic now, but I'd really LOVE to find out what was causing my issues in the first place.

@johnpoz I don't know. I didn't have any upload issues for 4 days at this point and nothing changed since then.

@Peter-VARGA You can select an interface for "auto" rule generation: [image: 1739736858371-9b26195f-4c0b-43b0-bff0-d6fdb3d31f7d-image.png]

@viragomann @SteveITS Thank you gentlemen! It works now. viragoman put me in right direction. No need to open any ports on clients windows FW or anything else, just correct NAT rule. I have 2 clients in secure dep., one with 3389 and second with 3390 RDP port (have to change default RDP in windows). Then clone standard NAT rule and just change redirect target and RDP port. Here is my config, that works.[image: 1739453439593-pfsense_nat.png]

@JC03 said in Pfsense abilitates automatically rules: The real problem is ... pfSense, when you installed it, does not have "pfBlockerng" installed. It can be installed by the admin, and was installed ... by you ?! When installed, it does ... nothing. You had to activated IP lists and DNSBL lists. One of them is "pfB_wind10updates auto rule". Remember now ? So, to get rid of this "rule", undo what you've done before ( ! ) and you'll be good. @JC03 said in Pfsense abilitates automatically rules: Sorry for the uncorrect utilize of english, but I'm from another country. No problem ^^ I'm dutch, living in France. edit : if you are not the admin, then ask the admin ?! The rule must have been placed there for a reason.

Sorry you couldn’t get things figured out. Is it possible for you to share your current set up.

@Bambos Simply put the pass rule for allowing the needed services above of the block rule.

@johnpoz said in Ingress Filtering question: How did that lead you to false understanding? i mean like i'm in LAN, looking to the incoming traffic and apply the firewall rules to limit the traffic. So according to this diagram, i was thinking that for LAN interfaces i was applying rules for the outbound of firewall / interface / LAN ingress traffic, so we can limit traffic going to that network (to protect that network) because we are on the firewall rules of it's interface. Instead of that, as what i'm learning now, i have to put the firewall rules to the outgoing traffic of the other interface (because this is where is the filtering happening). Also after reading through your comments, on this post and also others, assuming the pf filtering happening before the packet entering the interface, and NAT happening before the packet leave the interface, it seems that the NAT positioning for LAN is the correct, instead of the Guest. Last we have 3 different designs for interface attachment to the routing plane. which one you feel is more close to reality ? [image: 1739046378873-96b03bfa-4825-4bae-879c-defe7f692959-image.png]

@Bambos ok

@nbk333 said in Blocking Youtube with firewall rules: @bmeeks said in Blocking Youtube with firewall rules: pfBlockerNG First of all, thank you for this detailed explanation, it's completely understandable. I still have a question: if I don't deal with the separation, but only with the "youtube" blocking itself, is it possible to schedule the blocking somehow using pfBlockerNG? Do I block it during the week and allow it on the weekend? Or can this only be solved manually in pfBlockerNG? Yes, you can schedule when particular firewall rules are active. See the official documentation here: https://docs.netgate.com/pfsense/en/latest/firewall/time-based-rules.html. Where a tool such as pfBlockerNG comes in handy is that it can be configured to automatically populate and then keep updated firewall aliases containing the ASN IP ranges of chosen networks (controlled by the lists you download and enable within pfBlockerNG itself). You then create your own firewall rules using the alias or aliases you configured pfBlockerNG to maintain. Then after creating your rules containing the pfBlockerNG aliases, place the rules on a schedule. One last unsolicited piece of advice -- do not depend on technology to "be the parent" . There are simple and fail-safe ways to control device time for children that do not involve any technology at all.

@johnpoz said in I can not block WAN port?: so - for your own sanity, do the packet capture on pfsense wan when you do that test, do you see that 1024 hit pfsense wan, do you see a response. You're right. :) I did not try Packet Capure until now. I will googling and inform you. But it'looks modem answerign it? Regards, Mucip:)

@chris-doldolia could but just block that - that is not filling your single pipe.. You know a lot of users new to pfsense and first see all the noise they see on the internet and they think they are being attacked ;) Lets see this this dos.. You said your pfsense is logging just fine - so lets see some of this attack..

@keyser I was also surprised that you can't set a time interval. I didn't notice that if I click on the days (header) it doesn't give you a specific date, but the days in general. Thanks for the help!

@mj9768 If you allow any on OPT1 also access to your local network is allowed from this interface of course. But there is nothing allowed from WAN, even OPT1 is bridged with it. All you need to allow might be access to public destinations, however. So just add a proper rule to the interface. To achieve this, I create an RFC 1918 alias and use it as destination in a pass rule with "invert match" checked: [image: 1738149081752-9120df6d-057b-4b55-bc3d-9055be0632d6-grafik.png] This here is a floating rule, but in your case you should put it on OPT1 and you might want to allow any protocols. This presumes, that the tunables net.link.bridge.pfil_member is enabled and net.link.bridge.pfil_bridge is disabled.

@CatSpecial202 A reject is fine on a lan side rule - it sends an answer back.. But your blocking outbound.. I don't even know if it would work to be honest you would have to sniff to see.. but say you have a rule to block say ping to your wan IP from bad guys.. You would send them a reject every time they scanned a port that was blocked. So here is a rule on my lan that rejects going to 8.8.8.8 - see how I get a RST back, when it really should of just timed out.. [image: 1738034523169-reset.jpg] Might be ok since your traffic is going outbound. But it is normally not a good idea to use a reject on a wan interface unless your sure you want to actually send back something to the sender. Ok I tested changing my block outbound rfc1918 to reject - and yup I do get back a rst.. So guess its fine inbound traffic from the internet would not trigger that rule anyway. [image: 1738034867551-rejectwan.jpg] Just be aware you normally don't want reject on a internet facing interface - unless your sure you want to send an answer back.. Which could lead to sort of dos attack with your firewall busy answering stuff it should just drop and pay no attention too.