Firewall Basics
A firewall enforces rules for defined traffic flows. Good rules describe source, destination, service, direction, and purpose—not just “open port”.
Before you start
Who is this for?
For learners who want to control network access and narrow errors using rules and logs.
Prerequisites
- IPv4, routing, and ports
- VLAN and NAT basics
What you'll be able to do
- Distinguish stateless and stateful filtering
- write precise rules based on least privilege
- place zones, direction, and rule order in context
- separately check routing, NAT, and firewall errors
Practical outcome
You can create a minimal, testable rule set for clients, guests, and servers with verification and a rollback plan.
1. What a firewall decides
Section titled “1. What a firewall decides”A network firewall checks traffic at a control boundary. A simple flow can be described as a tuple:
Source: 192.168.10.25:51514Destination: 192.168.30.10:443Protocol: TCPDirection: Clients → ServerA rule can additionally consider interface, zone, user identity, application, time, or device state. The foundation remains the concrete question: Which sender needs which service on which destination and why?
Firewalls do not replace secure server configuration, updates, strong authentication, or segmentation. They reduce reachable paths and log decisions.
2. Stateless and stateful
Section titled “2. Stateless and stateful”A stateless filter evaluates each packet largely independently based on header fields. For return traffic, matching rules must explicitly exist.
A stateful firewall maintains a state table. When a new TCP connection is allowed, it can recognize return packets for that connection. This does not mean every return packet is allowed: it must match the known protocol state. UDP has no TCP handshake, but can be tracked through time-limited flow mappings.
3. Rule components and order
Section titled “3. Rule components and order”A comprehensible rule documents:
- Source: individual host, group, or smallest necessary network;
- Destination: specific server or defined target group;
- Service: protocol and destination port, optionally application;
- Direction/zone: from where to where;
- Action: allow, deny, or reject;
- Logging: appropriate to risk and diagnostic need;
- Owner and purpose: who needs the rule and until when?
Many firewalls process rules from top to bottom and use the first match. Other platforms derive an effective policy from multiple layers. Know the specific model rather than assuming a universal order.
Default deny means traffic that is not explicitly needed is dropped. This is safer than a broad permit, but requires inventory, testing, and a controlled rollout.
4. Zones and segmentation
Section titled “4. Zones and segmentation”Zones group interfaces or networks with similar trust and protection needs, such as clients, servers, guests, management, and internet. A zone is not an automatic security guarantee. Only rules between zones define allowed communication.
Example:
| Source | Destination | Service | Action | Purpose |
|---|---|---|---|---|
| Clients | internal DNS | UDP/TCP 53 | Allow | name resolution |
| Clients | web server | TCP 443 | Allow | application |
| Guests | internal networks | Any | Deny + Log | isolation |
| Admin hosts | management | SSH/HTTPS | Allow | administration |
“Any to any” makes a short-term test easier, but often remains in place permanently. Better is a temporary, time-limited diagnostic permit with documented rollback.
5. Host and network firewalls
Section titled “5. Host and network firewalls”A network firewall controls transitions between segments. A host firewall protects a single system even within the same VLAN. The two complement each other: a network rule can make a server reachable while the local firewall keeps the port blocked.
Cloud platforms also use Security Groups, Network Security Groups, or comparable distributed controls. Names and evaluation logic differ. Check whether rules are stateful, how priorities work, and whether inbound and outbound policies are separate.
6. Separating NAT, routing, and policy
Section titled “6. Separating NAT, routing, and policy”For an incoming publication, three independent problems can occur:
- Routing: is there a forward and return path?
- NAT: is the external destination correctly translated to the internal server?
- Firewall: is exactly this flow allowed?
In addition, the service must be listening. A timeout alone does not reveal which stage fails. Therefore document the flow before and after NAT, and search firewall logs by source, destination, port, protocol, and time.
7. Logging and verification
Section titled “7. Logging and verification”Logs should contain the decision, rule ID, interfaces, source/destination tuple, and time. Permanently logging every allowed packet can overload systems and create data protection issues. Log based on risk and protect logs from unauthorized access.
For every change, define in advance:
- the expected allowed test;
- the expected blocked negative test;
- affected source and destination;
- observation in server and firewall logs;
- rollback method and responsibility.
A successful ping is no proof of an allowed HTTPS flow. Test the actually required protocol and then check the application layer.
Common mistakes
Section titled “Common mistakes”- Documenting only “open port 443” without source, destination, and direction.
- Placing a broad permit above precise rules.
- Not testing network and host firewalls separately.
- Treating NAT or VLANs as a complete security solution.
- Only performing positive tests and not checking unintended access.
- Comparing logs without correct time synchronization.
Knowledge check
Section titled “Knowledge check”Multiple Choice
Firewall knowledge check
What you should now be able to do
Section titled “What you should now be able to do”- distinguish stateful and stateless filtering;
- formulate rules with source, destination, service, direction, and purpose;
- practically apply default deny, zones, and least privilege;
- separately test routing, NAT, network firewall, host firewall, and service.