I am writing down all the steps on how you can set traffic priority to one internal IP - QoS custom Rule for an IP First, create a bypass rule for the device in question. Navigate to Config > Network > Bypass Rules and click the Add button. Give the rule a description that is helpful in identifying what device is being bypassed. In this example we are bypassing an internal email server at 192.168.1.10 so we named the rule Email Server Bypass. Click the Add button in the "Conditions" section. Select the Source Address is option and then enter the IP of the device in question. Now that the device is bypassed we can set up custom QoS Rules for the device. Navigate to Config > Network > Advanced > QoS > QoS Rules and click on the Add button found in the QoS Custom Rules section of this page. Give the rule a description that is helpful in identifying what device is being given a new QoS priority. Click the Add button in the "Conditions" section. Select the Source Address is option and then enter the LANIP of the device we just created the Bypass Rule for. Now select the Priority you would like to give the device in question. QoS Custom Rule for a port First, create a bypass rule for the port in question. Basically, I have to do this traffic priority to one internal IP for one of my projects automated payroll software. So I needed how to do this thing. Navigate to Config > Network > Bypass Rules and click the Add button. Give the rule a description that is helpful in identifying what port traffic is being bypassed. Click the Add button in the "Conditions" section. Select the Destination Port is an option and then enter the destination port number into the Value field. Now that the port in question is bypassed, we can set up custom QoS rules for the device. Navigate to Config > Network > Advanced > QoS and then click on the Add button found in the QoS Custom Rules section of this page. Give the rule a description that is helpful in identifying what port traffic is being bypassed. Click the Add button in the "Conditions" section. Select the Destination Port is an option and then enter the destination port number into the Value field. Select the Priority you would like to give the destination port traffic in question. Home this article will help you properly.

@netblues yep expecting too much i guess , thanks for your help

@viragomann @johnpoz Thanks a lot for your response. I think you found the issue John. This device is wireless and after verification it does switch from wireless to cell connectivity ... and all destinations are Google Cloud and Amazon , which makes sense. Now time for me to figure out why the wifi keeps dropping for that device, I really appreciate your help !! Thanks again

@keyser Thanks, that's good to know, a start. No obvious errors in the rule setup then I assume? They are pretty similar to @CiscoX rules, apart from the last one which I split into two. If so, I guess I should move this into a wireless section, if any. Thanks to both :)

@johnpoz Thank you for the reply. I will keep ipv6 blocked and manage it with ipv4. I have little knowledge about ipv6 so I like your suggestion just to turn it off, at least for now.

(Gateway Monitoring / dpinger) https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html

@wellcomefit ASN is Autonomous System Number, this is what defines a group of IP prefixes.. But teamviewer could be honestly pretty much anywhere on the planet from here. https://www.teamviewer.com/en-us/trust-center/faq/ with pretty much all the major CDNs So that pretty much wouldn't do you much good.. whitelisting *.teamviewer.com would be what you do when you use a proxy, not a firewall. For that just open up port 5389.

@auroramus said in PFsense not allowing rdp ports to open however works when open to any: throw out random initial ports hence why it wouldnt work. This isn't something new, its how tcp/ip works.. It is very rare for the source port to be anything other than Ephemeral port, ie something above 1024.. There are some instances where this is not always the case.. But pretty much always you would set source port to be any..

@johnpoz Thank you for both of your posts. I am going through the process now.

@darkcorner Since there is no other device on the DMZ2 NIC there is no need to state the specify the source in the block rules. Simply set it to "any", as already mentioned in the other tread. Presumed you use only RFC 1918 networks on LAN and DMZ1 there is no need for extra block rules. The RFC1918 block will cover all these networks. Permit Any From Any to Any Are you expecting other sources than DMZ2 subnet? In a pass rule stating the source would make sense to me, but possibly you have other requirements.

@dma_pf said in Access only to the Internet and not to the DMZ. How to do?: Youl'll need to create a block rule on the LAN like this: LAN interface Protocol: TCP - ICMP / Echo request From: LAN Net To: DMZ Net For general blocking, it will be more secure to set the source to "any". Can't see any sense to state the subnet here at all.

@nikpony said in Firewall blocks me after every rule change or service stop: I wish i could provide more info, but as looking in General Error Logs, there is no something specific. shows the rule starts with something friend.

@aihysp those services are a vpn, a vpn is really just an encrypted tunnel. I am not aware of those 2 supporting inbound traffic through the vpn. But there prob is some services that provide that service. As to speed through a vpn - yeah not very likely that you would see any sort of speed increase - more likely to see a pretty drastic hit on performance if anything.. As to circumventing geo restrictions to watch services like netflix, etc. While sure that might work for a while, at some point they will prob block whatever IP range your using for the vpn, and have to change to a different pop or even vpn service. Your going to be playing wack-a-mole for sure with that sort of circumvention.. It might work for hours, it might work for days or weeks, or shoot it might work for a year, etc. But more than likely they at some point will block the IP your coming from via a vpn..

@viragomann Brilliant, I will try this, thanks :)

Solution: Grabbed a few IP's to the ldap server, created a host override in DNS resolver, and added a static route over the WAN to these IPs. Worked like a charm.

@mer said in How to best test/verify firewall rules?: @furom said in How to best test/verify firewall rules?: This surprises me a bit, and is in fact what made me want to test the rules. I have been told rules act according to "quick", that first match wins, but experienced otherwise when testing a bit with a simple raspberry pi, Well, that's what the GUI hides a little from you, hence me saying "pfctl". Under the hood, pfSense uses pf (originally from OpenBSD) to implement firewalling and NAT. pf has always been last match wins, but other keywords change that behavior. Think of an old HP calculator using RPN and you're thinking "correctly" ;) If you look closely at the rules you'll see how the "as applied" order matches with the "floating", "per interface", etc ordering in the GUI. Basically, rules you define in the GUI always have the "quick" added, which makes them effectively "first match wins" because "quick" aborts processing of the rules (there are a few exceptions, but for the most part this applies; I think floating rules you may have to actually check something to get quick applied). Ah... That clears the woe around that, makes sense now. :) This is a handy bookmark: https://docs.netgate.com/pfsense/en/latest/ Definitively! Thanks, had found it already, but a great resource - almost a bit daunting... But what I have seen so far, really good and comprehensive! If you have other packages enabled, it may affect what rules are evaluated and when, so I'm just talking about base install, nothing else enabled. Got it, I haven't come to addons or anything like that yet, but will have that in mind when time comes. The pf book by Peter Hansteen is a little old but the concepts and fundamentals still apply to "how pf works". Disclaimer: take anything I write here as my opinion, not an official "pfSense position" and like any thing else engineering/networking more than one way to get your result. For sure. I read a lot and try to compute what I can from it... :) Good thing there is a great backup feature, so there's most often a way back to where I started if messing things up too much :)

@the-other Yeah this is even better

Thanks everyone! My confusion was with 'blocking' - I thought it was a too way street. Now I understand it only prevents the source from Initiating a connection, but not replying to a request.

@briankoch709 said in Firewall policies work (sometimes): For a stretch of 15-20 minutes, working firewall policies stop working, resulting in blocked traffic. And then after some time, traffic will then be allowed. It's occurring quite regularly, and getting frustrating with my customer. What services do you have enabled? checks the status of your gateway during the period of time that the rule stops working. and post your full logs! please (not from the dasboard)

@furom well you could always test by trying to create connects your rules should block and set them to log and see if the block is logged, etc. But to be honest I have never seen an issue where rules were not what they say they are.. If having problems with say block rules not working - most likely an existing state that is allowing, etc. Being a good netizen I have an outbound rule to block rfc1918 that shouldn't go to the isp, ie if I typo something locally or something.. If there is no local network your trying to get to, then yeah pfsense would route that out the public internet, wouldn't get very far ;) But sure if you don't want to send such possible noise to your isp you could create an outbound block rule in floating for the rfc1918 space.. [image: 1642776409367-blockrfc1919outbound.jpg]