Help with pfSense firewall rules please!

Level1Techs L1 Articles & Video-related
, ,
1

rules
rules1208×805 66.7 KB

I am building a home router/firewall with pfSense to replace my Asus and TP-link all in one routers. I’ve installed it on an old Dell Optiplex and have managed to get it up and running, but have some questions about firewall rules.

The Browsing alias is ports 80,443,8080,53. The email alias is ports 25,465,587. Everything was going good ( I had internet in a browser and in Powershell), but when I tried to run other apps they would not connect to the internet. Two apps that I tried this morning that didn’t work was my trading app Ninjatrader and my vpn client. They work fine after I added the Allow All Traffic rule. My question is how do I configure a rule or rules to allow other apps without allowing everything.

Should I run netstat -b and just create an alias with all the ports that my apps are using and include that in rule? Or am I just being to anal, from what I understand pfSense is stated, so if i’m understanding that correctly it will only let traffic pass that my apps asked for anyway and the Allow All Traffic rule is good enough. Looking at netstat -b it looks like all the apps that I currently have running are using ports in the 52,000-53,000 range.

Maybe I could create and alias with that range of ports? Seems like a lot to have to troubleshoot any new app I might install to find ports and make a new or modify a rule every time.

I guess I’m looking for advise on which way to go and general firewall rules best practices.

2

Love to see another old piece of tech clawing its way back into use!

Firewall rules can be an absolute pain to get right, but well worth it!!

  1. Understanding Outbound Ports
    Yes, pfSense is stateful, so:

You only need to allow outbound connections.

Return traffic is automatically permitted.

Most modern apps (including browsers, trading apps, VPN clients) initiate connections using ephemeral ports (usually 49152–65535 or 1024–65535 depending on OS), and connect to known service ports like 443 or 1194.

  1. Best Practice for Outbound Rules
    Instead of allowing everything, consider this layered approach:

Option A: Controlled Freedom
Allow outbound connections to all destinations, but only from local devices, and only for TCP/UDP ports 1024–65535.

Destination ports: any.

Source ports: 1024–65535 (covers ephemeral range).

This keeps inbound connections blocked but gives apps the freedom to talk out.

Option B: Alias-Based Fine Control (More Work)
You can use netstat -b to identify needed ports per app.

Create port aliases and add rules — but this quickly becomes tedious.

  1. Suggested pfSense Rule Order (LAN tab)
    From top to bottom:

Allow DNS (UDP 53, TCP 53 if needed).

Allow Web Browsing (Browsing alias).

Allow Email (Email alias).

Allow NTP (UDP 123).

Allow VPN client (e.g., destination port 1194 UDP or 443 TCP).

Allow all from LAN net to any with source port 1024–65535 (TCP/UDP).

Block all (optional, pfSense has implicit deny at the end).

This will cover most legitimate outbound traffic without opening inbound doors.

Let me know what VPN client you use and if you’d like a more specific rule for it.

3

The easiest way to check why something isn’t working is to check the firewall logs which you can filter to make it easier to find what you’re looking for. It’s always worth enabling logging on block rules for this reason. Your VPN won’t work because you’ve only allowed TCP Web ports and the VPN is going to be using UDP and whatever port the server is using.

4

Re you 52-53000 range comment. I think its too narrow. Besides specific application ports, its worthwhile whitelisting 49152–65535 as suggested by RFC 6335 and IANA as ephemeral or private ports.

5

@paws
That is a pretty complicated setup for basically “allow all from LAN to WAN”.
So why not just use allow all from LAN to WAN?
It also allows inter VLAN communication.

Here is a IMHO sleeker option. It also covers VLANs.
It is from OPNsense but pfSense is basically the same.

image
image2350×874 202 KB

  • Rule 1:
    Is to allow all traffic to the Firewall itself. That allows for stuff like DNS. DHCP is already enabled in the auto rules.
  • Rule 2:
    This is an alias of local networks (RFC 1913 and IPv6 static /56 prefix from my ISP). That way clients can’t talk to other VLANs.
  • Rule 3:
    Allow everything. Since Firewall rules are “first catch only, top to bottom”, this will allow everything that was not blocked before and should always be the last rule.
    IMHO there is not point in opening single ports for outgoing connections.

That is basically how all tutorials tell you to setup firewall rules and IMHO the way to go.

1 Like
6

@paws thank you very much lots of info!

After I posted I did change the Allow All Rule to open ports 52,000-54,000 and everything is working right now.

If I’m going to have all those ephemeral ports allowed why not just allow everything, kind of like what @ThisMightBeAFish says below?

Do I even need those three block rules I have at the bottom? I do want to keep it simple, and I’m going to have VLANS also. As for my vpn, I signed up with AirVPN for 3 months to test them out. I have their client “Eddie” on my pc right now, but I’m trying to put it directly on pfSense so I it will cover the whole network, or most of it anyway. It seems pretty involved and the newest guide I’ve found is from 2021, so a little outdated. Still a work in progress.

Any thoughts on VPNS? Something that might be easier to use with pfSense. Nord seems popular (everyone seems to recommend it) but that doesn’t make it the best choice.

7

@ThisMightBeAFish Thanks for your input! I do want to keep it as simple as possible while keeping good security. I do want to create VLANS and It looks like the only block rule you have is to isolate the VLANS right? I don’t know if this should be a different topic but here is what I think I want my network to look like. Any recommendations from anyone would be welcome.

image
image918×721 91.7 KB

8

No, they do absolutely nothing there. Because they are at the end and by default everything is blocked in pfSense (but there are some automatic allow rules like DHCP).

VPNs are a Tunnel. Tunnels don’t offer any privacy advantages, because they only move your entry point to the internet. Companies like NordVPN are basically a scam, that is why their biggest spending is in marketing.

That is correct.

1 Like
9

What is your VPN for? If you have not yet divedinto the world of TailScale I suggest you put your swimming trunks on!

https://tailscale.com/

You can access your whole network via a tailscale network or just individual machines. It “JUST WORKS” in a lot of situations. Others can require some setup. Reach out if you need help setting it up!

10

Haven’t look over the thread carefully, but as a non-expert OPNsense user, here’s what I understand:

The rules will normally be processed in order, and then should reach a default DROP for anything not ACCEPTed.

For INbound traffic from the WAN you want (what should be the default) to DROP everything. This does not affect established connections something on your network has initiated. Do not REJECT/DENY traffic from your WAN, use DROP - this makes you somewhat more vulnerable to hacking and DOS. Never remove or fail to have this default DROP everything on the WAN! If you need to open some specific holes in the firewall (don’t recommend it) you can put ACCEPTs before the default DROP (this requires more setup as well, to tell pfSense what address to send such to).

For OUT bound traffic to the WAN, you don’t set this in the WAN’s rules normally, instead you want pretty much any LAN/VLAN to ACCEPT IN traffic on “any” protocol and “any port” from that VLAN (or “any”) that is destined to the WAN. Traffic that comes IN (to router) and has a route to go to (OUT) will be sent OUT on that interface, so you don’t normally have to worry much about OUT. That means that a device on that LAN will be able to connect to the internet. Note that if it reaches a default DROP or REJECT it will not be able to talk to other LANs/VLANs.

Things you may want to do to lock down certain LAN/VLANs (guest wifi for example, that kind of thing):

  • ACCEPT IN to “this firewall” DNS (TCP/UDP port 53 is what I remember putting)
  • DROP (could be DENY/REJECT as could the following) IN all other traffic to “this firewall” (prevent a device on that network from logging in or anything else - always leave one LAN without this set!)
  • DROP IN to GeoIP addresses if you want to block communication with certain countries. This has to be configured.
  • DROP IN to Spamhaus DROP list (has to be configured). You don’t need to block the incoming traffic from these networks, since they are already blocked on the IN direction of the WAN (or you’ve messed up!), but this will prevent any device from contacting them.
  • DROP IN traffic to an alias you’ve created for local_networks or such with all the local network interfaces. In this case, a LAN that doesn’t have this DROP will still be able to connect to a device on the LAN with it, but a device on the DROP LAN will not be able to connect to other LANs.
  • ACCEPT IN traffic to the inverse of local_networks (!local_networks) - if it’s not to a local_network, it’s fine.
  • Last rule should be default DROP anything not accepted…