A public address such as 203.0.113.10 attracts connection attempts whether a small office intended to publish a service or not. Without a firewall policy, an internet attacker needs only the address and an open path to reach exposed services, probe for weak configuration, or send traffic toward internal networks. A firewall is the boundary device that compares each connection attempt against rules and allows or blocks the traffic. In our lab, the first safe decision is simple: allow only the public web connection intended for Web at 192.168.40.10, and deny other unsolicited internet traffic. Let’s map the networks that this decision must protect:
This diagram fixes the addresses and roles for every later rule table. The firewall uses .1 on each internal network, while 203.0.113.10 is its internet-facing address. PC1 belongs on the user network, Guest1 belongs on an isolated guest network, and AdminPC is the only workstation permitted to administer the firewall. The web server sits in the DMZ, a separate network for services that must accept limited internet traffic without giving internet clients a route into the server network.
An attacker reaching the WAN interface should never reach File at 192.168.20.20 or the directory and DNS server at 192.168.20.10. Separating those systems into VLANs creates boundaries, but VLANs alone do not decide which packets may cross them. The firewall makes that decision with explicit rules between the networks.
Boundary rule A network segment protects a system only when the firewall denies traffic that has no stated business purpose.
The lab’s five recurring traffic flows give us concrete tests for every firewall type and rule set. Guest1 needs DNS resolution on its way to the internet, but a guest device has no business reason to open a Windows file-sharing connection to File on TCP port 445. PC1, by contrast, may need that file-sharing connection. The internet may reach the DMZ web server on TCP port 443, while only AdminPC should reach the firewall management page on TCP port 443.
A packet-filtering firewall decides from fields visible in one packet, including source address, destination address, protocol, and port. A rule can allow UDP port 53 from Guest1 to 8.8.8.8, or deny TCP port 445 from the guest network to the server network. Packet filtering is fast and useful, but a packet by itself does not show whether the packet belongs to a legitimate connection that started earlier.
A stateful firewall records active connections in a state table. When PC1 begins a permitted file-sharing connection to File, the stateful firewall allows the returning packets because they match that recorded connection. An unsolicited packet from the internet has no matching state, so the firewall can deny it unless a rule specifically permits the new connection. This behavior prevents a broad and dangerous rule that would allow all return-looking traffic from every direction.
An application-aware firewall can inspect information above ports and addresses, such as an HTTP request or a DNS query. A next-generation firewall commonly combines stateful inspection with application inspection and threat detection. Deeper inspection does not replace clear boundaries. The firewall must first decide that Internet may contact Web on HTTPS; inspection then helps identify traffic that violates the expected use of that allowed path.
Which of the five flows should cross a boundary, and which should stop at the firewall? The table keeps the expected decision and denial evidence together: