A new service is running, yet outside visitors cannot reach it. What is a firewall in that situation? It is a rule-based filter between networks or on a host, and its rules decide which traffic passes.
The quick answer is that a firewall compares each packet with an ordered list of rules and applies the action of the rule that matches. Learners preparing with security+ exam vorbereitung will meet this idea repeatedly, so it pays to understand the rule logic and not just the product names.
What a firewall does with traffic
A firewall is a control point that inspects network traffic and applies rules to it. Traffic that matches an allow rule continues towards its destination. Traffic that matches a blocking rule is stopped. Some rules do something different again: they rewrite where a packet is going.
Most of what a rule examines will already be familiar from TCP/IP. A rule typically looks at the protocol, the destination address and the destination port. The port tells the firewall which service on a machine the packet is aimed at. A rule that mentions TCP and a web port is therefore a statement about one kind of service, not about the whole machine.
Three common misunderstandings shape how people read firewall configuration, and the table below sets each against what actually happens.
| Common assumption | What actually happens | Planning use |
|---|---|---|
| A firewall only blocks traffic | Rules can also route external traffic through the firewall to internal services on specific IP addresses and ports, which is what port forwarding does | Read the action of each rule before assuming it is a block |
| A firewall is one box at the network edge | A Linux system runs iptables itself, and with IP forwarding enabled it can route packets between different network interfaces | Ask which device or host applies each rule |
| Once configured, a firewall needs no attention | Logs can reveal unexpected traffic patterns after a change is made | Review logs whenever the rule set changes |
These points follow the port-forwarding guide in the Unlimited Web Hosting iptables knowledge base, a hosting provider’s practical documentation.
How a rule set is read, packet by packet
A firewall decides what to allow by matching each packet against its rules, one packet at a time. The rule list is read in sequence, and the first rule whose conditions fit the packet normally decides its fate. This is why the same rule can behave differently depending on what sits above it.
In iptables the rules are grouped into chains attached to points in a packet’s journey. The PREROUTING chain processes incoming packets before routing decisions are made. That makes it the natural place to rewrite a destination, because the system has not yet chosen where the packet will go.
A worked rule from the iptables NAT table
The hosting guide gives this rule, which forwards external traffic arriving on port 80 to 192.168.1.1 on port 9086:
sudo iptables -t nat -A PREROUTING -p tcp –dport 80 -j DNAT –to-destination 192.168.1.1:9086
Read it the way the firewall does, from the conditions to the action:
- Pick the table. The -t nat part places the rule in the NAT table, where address rewriting lives.
- Pick the chain. The -A PREROUTING part appends the rule to the chain that sees incoming packets before routing.
- Match the protocol. The -p tcp condition limits the rule to TCP traffic, the transport protocol you already know from TCP/IP.
- Match the port. The –dport 80 condition limits it to packets whose destination port is 80.
- Apply the action. The -j DNAT –to-destination 192.168.1.1:9086 part rewrites the destination address and port, so the packet continues to the internal service.
Packets that fail any condition, such as a UDP packet or a TCP packet for another port, skip this rule and meet whatever rule comes next.
What has to be true for forwarding to work
A correct rule alone does not move traffic. IP forwarding must be enabled, which the guide does by setting net.ipv4.ip_forward=1 in /etc/sysctl.conf and running sudo sysctl -p. Without it the system will not route packets between its network interfaces, so the rewritten packet goes nowhere.
Existing rules matter as well. The guide advises looking for any rules that block or redirect traffic on the ports you plan to forward, because an earlier rule can intercept the packet before your new one is reached. After adding the rule, confirm it with sudo iptables -t nat -L -n -v.
Where a firewall sits in a network
A firewall sits wherever traffic crosses a boundary it is meant to control. In the classic arrangement that is between the internet and an internal network, so that external traffic reaches internal services only through the firewall. Port forwarding is the clearest example: external traffic is routed through the firewall to internal services on specific IP addresses and ports.
The boundary does not have to be a dedicated appliance. Because IP forwarding lets a system route packets between different network interfaces, a Linux machine with two interfaces can act as the crossing point and apply iptables rules to what passes through. The same filtering software also runs on a single machine to control traffic to that machine alone.
Network firewalls and host firewalls
A network firewall protects the segment behind it, while a host firewall protects only the machine it runs on. The two complement each other. A laptop that leaves the office network keeps its own host rules, whereas the edge device only covers traffic that actually crosses it. When troubleshooting, decide first which of the two is dropping the traffic, since a fix applied to the wrong one changes nothing.
Next-generation firewalls and the same reading skill
A next-generation firewall extends the same rule-matching idea with richer inspection than address, protocol and port alone. The practical consequence for learners is that the packet-by-packet reading habit carries over: identify what a rule matches, then identify its action. Detection and prevention features that sit alongside filtering are compared in ids vs ips.
A firewall also answers a narrower question than people expect. It judges traffic by its characteristics, not by who the user is. Questions about identity and permissions belong to authentication vs authorization, which works alongside firewall rules rather than replacing them.
Watching what the firewall allows and blocks
A firewall is not finished once the rules are in. After forwarding is set up, the hosting guide recommends reviewing firewall logs for any unexpected traffic patterns. Logs show which packets were allowed or stopped, so they are the evidence for whether a rule does what its author intended.
Make log review part of every rule change, not an occasional chore. A new rule that matches more broadly than intended will often show up first as traffic that no one expected to see.
Frequently asked questions
| Question | Answer |
|---|---|
| Do iptables rules survive a reboot? | Not by themselves. The iptables-persistent package saves firewall rules automatically so they survive system reboots. |
| What should be checked before adding a forwarding rule? | Look at the existing rules for any that block or redirect traffic on the ports you plan to forward, since they can conflict with the new rule. |
| What does a port mean to a firewall? | The port identifies which service on an address a packet is aimed at, so a rule that names a port applies to that service, not to the whole machine. |
| How can a rule be confirmed after it is added? | Run sudo iptables -t nat -L -n -v to list the NAT table and check that the rule appears as written. |
