Firewall, NAT and DMZ Explained for Beginners: ACLs, PAT and Core Network Security Concepts

Firewall, NAT and DMZ: How Network Security Really Works in Practical Setups

When you’re just starting to build a network, the goal is usually simple: devices should get internet access, servers should run, and everyone should be able to do their work. At this stage, security topics sometimes end up as “we’ll deal with it later.” But in practice, it’s the opposite: as the network grows, becomes internet-facing, and the number of services increases, security design stops being “extra” and becomes a core part of the infrastructure.

Because it’s not enough for a network to work; it has to work in a controlled way. Who can access what, which traffic is allowed through, which services can be visible from the outside… all of that is defined at the security layer. And this security layer mostly revolves around three main concepts:

  • Firewall: the gate that allows/blocks traffic
  • NAT/PAT: the mechanism that “translates” internal addresses to the outside world
  • DMZ (Demilitarisierte Zone): the approach of keeping externally exposed services in a separate zone

In addition, there are more “rule-level” tools such as ACLs. In this article, I’ll first set the big picture, then follow the flow NAT → Firewall → DMZ → ACL, so the topics connect naturally.

1) Understanding network security: where does the “boundary” begin?

In the subnetting and routing articles, we talked about the idea of drawing boundaries: subnets are boundaries, and routers carry traffic between those boundaries. On the security side, there’s something similar, but a bit harsher:

  • The internal network (LAN) is generally considered the “trusted” zone.
  • The internet/WAN is the “untrusted” zone.
  • Between these two zones, there is a boundary device: most often a firewall.

Thinking of a firewall as only “a device that blocks” is incomplete. A firewall is actually “a device that enforces policy.” The goal isn’t to block everything; it’s to allow the right traffic and block what’s unnecessary.

Once you get here, NAT naturally comes up. Because the IPs used in most internal networks are not routable on the internet (private IPs). For devices running on 192.168.x.x internally to access the internet, a “translation” is required.

2) What is NAT? (And why NAT ≠ security)

NAT (Network Address Translation), in its simplest form, means “IP address translation.” It allows private IPs inside the network to appear to the outside world through a public IP when going out.

Example scenario:

  • Inside PC: 192.168.10.50
  • Outbound path: the firewall’s public IP: 203.0.113.10

When the PC goes out to the internet, the internet side does not see the PC as 192.168.10.50 (and it shouldn’t). Instead, all outbound traffic appears as 203.0.113.10.

There is a very important misconception here:
NAT by itself is not “security.”

Yes, NAT can seem like it makes direct inbound access harder, because internal IPs are not visible. But that does not replace a security policy. NAT only translates addresses. Whether traffic is allowed or not is determined by firewall rules.

Making this distinction clear is crucial, because the idea of “We have NAT, so we’re safe” is a risky misconception in real life.

3) PAT (NAT overload): one public IP, hundreds of devices

In many environments, dozens or even hundreds of devices access the internet through a single public IP. How is that possible? That’s where PAT comes in.

PAT (Port Address Translation) does this:

  • It uses not only the IP, but also the port information for translation.
  • This way, sessions from different internal devices can be distinguished over the same public IP.

So from the outside, everyone looks like 203.0.113.10, but thanks to ports, it can still be tracked which internal device opened which connection.

For a beginner, this detail means:

“Internet access can go out through a single IP, but internally the traffic can still be separated.”

4) Firewall logic: rules and “stateful” thinking

The easiest way to understand a firewall is to start with this question:
How does a firewall decide?

A firewall typically decides based on:

  • Source IP/subnet
  • Destination IP/subnet
  • Port
  • Protocol (TCP/UDP/ICMP)
  • Direction of traffic (inside → outside or outside → inside)
  • And very importantly: the connection state (state)

This is where the “stateful” concept comes in. A stateful firewall knows whether “this connection was initiated from the inside earlier.” For example, when an internal device sends a request to an external website, it allows the returning response packets because they are part of an established session.

Because of that, most networks end up with this policy:

  • Inside to outside: controlled allow
  • Outside to inside: blocked by default (only opened by explicit permission)

This is a fundamental approach in security, and it also creates a good foundation for moving into DMZ. Because some services must be reachable from the outside (for example, a web server). But exposing that directly inside the internal network is risky.

5) DMZ: not bringing internet-facing services “all the way inside”

The DMZ (Demilitarisierte Zone) concept may sound like a military term, but in networking it’s used for a very simple purpose:

Keeping internet-facing services in a separate zone from the internal network.

Why? Because when you expose a service to the outside, it’s more likely to become a target. Since services like web servers, mail gateways, and reverse proxies are open to the outside world, the attack surface increases. If those servers sit inside the internal network, a vulnerability could make it easier for an attacker to move into the internal environment.

With a DMZ approach:

  • Traffic coming from the internet goes to the DMZ first.
  • Servers in the DMZ have very limited access to the internal network.
  • Separate rules are applied between the internal network and the DMZ.

For a beginner, it’s easy to picture the logic of a DMZ like this:

  • Internal network = inside your home
  • Internet = the street
  • DMZ = the entrance hall of an apartment building
    If a visitor is going to enter, they first pass through the hall, and where they can go inside is controlled by rules.

The critical point here is: a DMZ is not a “magic zone that solves everything.” A DMZ is a design approach; the actual security still comes from firewall rules and proper segmentation.

6) ACL: a simpler version of the “let this pass, block that” list

Firewall rules are often richer and stateful. An ACL (Access Control List) often works more like a straightforward “list.” You can encounter ACLs on routers, switches, and firewalls.

ACL logic:

  • Allow traffic from this source to this destination on this port/protocol
  • Deny the rest (often with an implicit deny)

ACLs commonly appear in places like:

  • Basic filtering on a router
  • Restrictions between the DMZ and the internal network
  • Limiting access between VLANs

For a beginner, the key point is understanding that an ACL is a “policy enforcement tool.” Separating VLANs does not automatically bring security. VLAN draws a boundary; ACL/firewall defines who can cross that boundary.

7) Security requirements: what are we doing all this for?

Behind all these technical concepts, there are actually simple goals. In security, people often talk about the “CIA Triad”:

  • Confidentiality
  • Integrity
  • Availability

Without making it overly theoretical, you can connect it like this:

  • Confidentiality: not everyone should access everything.
  • Integrity: data should not be altered/manipulated.
  • Availability: systems should remain operational (e.g., services shouldn’t collapse due to DDoS, loops, or a misconfigured rule)

That’s why security settings are not just “let’s block things.” If you write the wrong firewall rule, security might increase but the system won’t work. If you leave it too loose, the system works but risk increases. The goal is balance.

8) A practical flow: I want to publish a web service (what happens?)

Let’s connect the topics through a scenario that is very common in real life:

Say you have a web application and you want it to be reachable from the outside.

  • Will you keep the server inside the internal network, or in the DMZ?
    Usually the DMZ is the safer approach.
  • Requests coming from the internet must pass through the firewall.
    Here you write an inbound rule: “Allow HTTPS (443) to this public IP.”
  • NAT (port forwarding) comes into play.
    Public IP:443 → Web server IP:443 in the DMZ
  • You need a rule set between the DMZ and the internal network.
    If the web server needs to connect to an internal DB, you allow only the relevant port and only to the relevant IP.

This example shows:

  • NAT: translates address/port
  • Firewall/ACL: decides who can pass
  • DMZ: keeps risk away from the internal network

Here, the topics naturally complete each other.

9) The most common mistakes (short but important)

As a beginner, knowing these mistakes will help you a lot:

  • Thinking NAT is security (NAT ≠ security)
  • Saying “open everything so it works,” and then forgetting about it
  • Building a DMZ and allowing too much access from the DMZ to the internal network
  • Not accounting for “return traffic” when writing rules (not understanding the stateful difference)
  • Expecting security without segmentation (one subnet, everything in the same place)

Closing: security isn’t something you add later to the network

Once you learn firewall, NAT, and DMZ, the way the network looks changes. It’s no longer “everyone can go everywhere,” but “the right person should go to the right place.” And this is one of the most important differences in enterprise system management.

The reason I kept this article long is that the topics are deeply connected. Once you explain NAT, firewall follows; once you explain firewall, DMZ gains meaning; once you build a DMZ, you need to enforce boundaries with ACLs. All of these serve a single goal: keeping the network running while also keeping it under control.