Firewall Rules 101: What Every SMB Owner Should Understand

Back to Blog

You hired an MSP to manage your firewall so you don't have to think about it. That's the right call — firewall configuration is a technical discipline, and the consequences of getting it wrong range from a slow network to a catastrophic breach. But "I pay someone to handle that" is not the same as "I don't need to understand it at all."

As a business owner, understanding what your firewall does — and what your IT provider should be doing with it — puts you in a far stronger position. You can have better conversations with your provider, ask the right questions during a security review, and recognize warning signs if something is being managed poorly. This guide is written for that purpose. No technical background required.

What a Firewall Actually Does

A firewall is a gatekeeper that sits between your internal network — your computers, servers, printers, phones — and the outside world, which is primarily the internet. Every piece of data that moves in or out of your network travels in packets, small chunks of information that include details like where they came from, where they're going, and what type of traffic they represent.

The firewall examines those packets and makes a decision: allow, deny, or log. That decision is made by comparing the packet against a set of rules that you — or more accurately, your IT provider — has configured in advance. The firewall applies those rules in order, top to bottom, until one matches. When a match is found, the corresponding action is taken.

Think of it like airport security. The rules determine who gets through, who gets turned away, and who gets flagged for additional scrutiny. The difference is that your firewall processes thousands of these decisions every minute, automatically, without human review of each individual packet.

Inbound vs. Outbound Rules

Firewall rules apply in two directions, and understanding the distinction matters.

Most security incidents that begin with an external attacker involve inbound traffic first — someone finding a way in — followed by outbound traffic as the malware "calls home." A firewall that only applies strong rules to inbound traffic is only doing half the job.

Stateful vs. Stateless Inspection

This distinction sounds technical, but the concept is simple and important.

Stateless firewalls look at each packet in isolation. They evaluate the source, destination, port, and protocol, then apply rules based on those characteristics alone. They don't know anything about the conversation — whether this packet is part of a legitimate ongoing session or an unauthorized connection attempt. Stateless firewalls are fast and simple, and they were the standard for decades. They're also relatively easy to fool.

Stateful firewalls maintain a table of all active network connections — all the "conversations" currently in progress between your systems and the outside world. When a new packet arrives, the firewall checks whether it belongs to an established, legitimate conversation before deciding what to do with it. This means an attacker can't simply craft a packet that looks like a valid response to fool the firewall — the firewall knows which responses it's actually expecting.

Every firewall IT Center deploys for managed clients uses stateful inspection as the baseline. It's not optional — it's the minimum acceptable standard for any modern business network.

The Three Core Actions: Allow, Deny, Log

Every firewall rule ends in one of these three actions, and understanding what each one means is fundamental to understanding what your firewall policy actually does.

Action	What It Does	When It's Used
Allow	The packet is permitted through. The connection proceeds normally.	Legitimate business traffic: your accounting software talking to a cloud server, users browsing the web on port 443, VPN traffic from known IP ranges.
Deny / Block	The packet is dropped. The connection is refused. In some configurations, the sender receives no response at all (a "silent drop"), which reveals less information to an attacker than a formal rejection.	Everything not explicitly permitted. Inbound connection attempts from the open internet to internal services. Traffic from blocked countries or IP reputation lists.
Log	The packet or event is recorded. Logging is typically combined with allow or deny — you might allow traffic and log it, or deny traffic and log the attempt. The log entry records source IP, destination, port, timestamp, and action taken.	High-value traffic you want an audit trail on. Denied connection attempts from the internet. Admin logins. Any traffic that warrants review.

Logging is not just an audit trail — it's an intelligence feed. The blocked connection attempts your firewall logs every day are data points about who is probing your network and from where. A sudden spike in blocked attempts from a specific region or IP range is a signal worth investigating.

What IT Center Configures by Default

Every client we onboard gets a baseline firewall policy built around the same core principles. Here's what that looks like in plain English:

Default Deny All Inbound

The last rule in every firewall policy we deploy is a catch-all: deny everything inbound that has not been explicitly permitted by a rule above it. This is the foundational principle of secure firewall configuration. If a rule doesn't explicitly say "allow this," the firewall blocks it. The firewall does not trust anything by default. Access is earned through explicit configuration, not assumed.

This is the opposite of how many businesses start out — with routers and firewalls in their default-from-the-factory state, which often lean toward permissive. We invert that posture on day one.

Allow Established and Related Connections

Thanks to stateful inspection, the firewall automatically allows traffic that is part of a connection your internal systems initiated. If someone inside your network opens a browser and visits a website, the firewall knows to allow the website's response traffic back in — because it tracked the outbound request. This means legitimate traffic flows normally without needing to manually allow return traffic for every permitted service.

Permit Specific Services on Specific Ports

Any service that genuinely needs to be accessible from the internet — a web server, a client-facing application portal, a VPN endpoint — gets an explicit allow rule, scoped as tightly as possible. That means specifying the source IP range if possible, the exact destination port, and the protocol. A VPN allow rule, for example, would specify the VPN protocol, the port number, and ideally limit the source to known geographic regions. Nothing is opened more broadly than it needs to be.

Block Known Malicious IP Reputation Lists

We subscribe to threat intelligence feeds that maintain constantly updated lists of IP addresses associated with known malicious activity — botnets, command-and-control servers, Tor exit nodes, scanning infrastructure used by threat actors. These are blocked proactively before they ever have a chance to probe your specific services. It's not a perfect defense — threat actors change IPs frequently — but it eliminates a substantial volume of low-effort attacks automatically.

Geo-Blocking: Keeping Out Traffic From Countries You Don't Do Business In

Geo-blocking is exactly what it sounds like: firewall rules that block all traffic originating from specific countries at the network level. If your business operates entirely within the United States and has no clients, vendors, or employees in Russia, North Korea, China, or Iran, there is no legitimate reason for inbound connection attempts from those countries to reach your network.

The volume of attack traffic that originates from specific geographic regions is not random — it follows well-documented patterns. Blocking these regions at the firewall eliminates an enormous category of automated scanning, brute-force attacks, and exploitation attempts before they ever touch your systems.

It's worth being precise about what geo-blocking does and does not do. It is not a complete defense — sophisticated attackers route traffic through VPNs, compromised US-based servers, or proxies to appear domestic. Geo-blocking eliminates opportunistic, automated threats. It does not stop a targeted, determined adversary. But for most SMBs, the threat landscape is dominated by opportunistic attacks, and eliminating them matters.

Application-Layer Filtering: Looking Inside the Packet

Traditional firewall rules operate at the network layer — they see the source IP, destination IP, port number, and protocol. But they don't look inside the traffic itself. A traditional firewall might allow all HTTPS traffic on port 443, which includes legitimate web browsing — but also malware that uses HTTPS to blend in with normal traffic.

Application-layer filtering, also called deep packet inspection (DPI), goes further. It examines the actual content of traffic to understand what application or service is generating it and whether that traffic is behaving the way it should. Modern next-generation firewalls can identify traffic by application signature rather than just port number, which matters because:

• Attackers routinely use non-standard ports to move traffic, so a rule blocking port 3389 doesn't stop RDP if the attacker moved it to port 8443.
• Some applications are legitimately risky — peer-to-peer file sharing, certain remote access tools, anonymization proxies — and DPI can identify and block them regardless of the port they're running on.
• Malware often mimics legitimate application traffic signatures. DPI can detect when something claiming to be HTTP traffic is not behaving like HTTP traffic actually does.

Application-layer filtering adds processing overhead, which is why it's often deployed selectively — applied to traffic categories where the inspection value is highest, rather than to every packet crossing the firewall. Sizing the firewall hardware appropriately to handle DPI without degrading network performance is part of our deployment process.

Why "Default Allow" Is Catastrophic

The alternative to default deny is default allow — a firewall posture that permits everything unless a specific rule says otherwise. This is the way consumer routers and many entry-level network devices behave out of the box, and it is dangerous in a business environment.

With default allow, the security of your network is entirely dependent on your ability to anticipate and explicitly block every possible attack vector. You must write rules for every malicious IP, every unauthorized port, every dangerous protocol. You're playing defense by trying to predict what attackers will do next.

With default deny, the posture is inverted. You define what is legitimate and block everything else. Attackers must find a way through your explicit allow rules — which are limited and well-defined — rather than exploiting gaps in your deny list, which can never be complete. Default deny is not more restrictive in practice for a well-run network; your legitimate business traffic is identified and permitted. But it eliminates an entire class of threat that default allow invites.

If your current IT provider cannot tell you whether your firewall operates under a default deny policy, that is the first question to ask.

Firewall Logs: What to Look For

Firewall logs are dense — a busy business network can generate hundreds of thousands of log entries per day. The value is not in reading them line by line. The value is in reviewing aggregated summaries and alerting on anomalies. Here's what matters:

• Denied connection attempts by source IP: A single IP generating thousands of denied connection attempts is a scanning or brute-force attack. An IP generating a small number of denied attempts is normal internet noise. The difference matters, and your firewall should be configured to alert on high-volume attempts from a single source.
• Denied outbound connections from internal IPs: If a machine inside your network is trying to connect to known-bad IPs or unusual destinations and the firewall is blocking it, that machine may already be compromised. The firewall is containing the threat — but the alert is telling you to investigate the source.
• Authentication events: Failed login attempts to VPN or other externally accessible services are visible in firewall logs. A surge in failed authentications against your VPN — especially from a small number of IPs trying many different usernames — is a brute-force attack in progress.
• Unusual allow events: Legitimate traffic following known patterns. If something that is being allowed looks different from its normal pattern — a server that typically talks to three destinations is suddenly making connections to forty — that warrants investigation.

IT Center's managed clients have their firewall logs reviewed as part of ongoing monitoring. You should not be relying on someone manually combing through logs — that's what log aggregation and SIEM tools are for. But someone should be reviewing dashboards and responding to alerts on a regular cadence.

When to Call Your MSP

You don't need to understand firewall rules at a technical level to know when something warrants a call. These are the signals to act on:

• You've onboarded a new vendor or software platform that requires connectivity to your network, and your team can't access it. Don't just tell IT "it's not working" — tell them it's a new connection and what service it is. That's a firewall rule conversation.
• You're adding remote employees in a new country or region. If your firewall uses geo-blocking, that region may need to be whitelisted for VPN access.
• You've received a notification that a device on your network has been flagged for unusual outbound activity. Even if the firewall blocked it, this is an investigation item.
• Your company is about to open a new physical location, and that location needs to connect to your main network. The network interconnect between locations needs firewall policy — this is not a set-it-and-forget-it situation.
• You're considering a merger, acquisition, or partnership that would involve connecting another organization's network to yours. This is a significant firewall event — two different security postures being joined — and it deserves a dedicated security review before connectivity is established.

The firewall is not a "configure once and walk away" tool. Every change to your business — new software, new users, new locations, new vendors — is potentially a firewall event. Your MSP should be part of those conversations from the beginning, not called in after the fact to clean up a permissive workaround someone implemented to get a new tool working fast.

The Bottom Line for Business Owners

You don't need to know how to write a firewall rule. But you should know that your MSP is operating under a default-deny policy, maintaining up-to-date threat intelligence feeds, logging denied traffic and reviewing anomalies, implementing geo-blocking appropriate to your business, and applying application-layer filtering where it adds value. Those aren't technical details — they're professional standards. Any MSP that can't answer those questions clearly and specifically is not managing your firewall to the standard your business requires.

IT Center has managed firewall infrastructure for Southern California businesses since 2012. Our standard deployment uses Netgate pfSense appliances configured with the baseline policies described above, reviewed and updated as part of every client's ongoing managed security service. If you've never had a clear answer from your current provider about what your firewall actually does, that's a conversation worth having — preferably before you need it.