1Session at a glance
Objectives
- Explain why a reply arrives without a rule permitting it, and when it would not.
- Say what happens when a specific exception sits below a general block, and fix it.
- Name the built-in zones and read a rule as a sentence.
- Describe what translation does to a packet in both directions, and what the port is doing.
- Answer a request for a remote desktop forward, with the reason and the alternative.
- Classify a blocked-traffic log line into scanning, blocked by design, or ordinary work.
Before the session
- A site open in the UniFi console at its firewall rules, with one specific-above-general pair already located.
- That site's port forwarding rules found in advance, and its blocked-traffic log open with recent entries.
- A real scanning burst against the public address picked out of the log, to use in the open.
- Everyone with the Learner Guide open.
| Time | Block | What happens |
|---|---|---|
| 0:00 | Open | The log, and how many strangers tried the front door of a client site last night. |
| 0:04 | Concept | Why a reply gets back in (5), rule order (4), zones (3), translation (5), port forwarding (4), and the virtual private network, or VPN (2). |
| 0:27 | Show | Live: the rule list read top to bottom, a specific-above-general pair, any port forward with what it exposes, then the blocked log. |
| 0:37 | Do | Everyone writes five rules as sentences, then classifies twenty log lines. |
| 0:49 | Check | Seven questions. |
| 0:56 | Close | The work before session 07, and what that session covers. |
Stateful inspection and translation carry the session at five minutes each, because every later block is read off them and both check questions that trip people depend on the state table. If the room is behind, cut zones to naming External, Internal and VPN and leave the rest to the Learner Guide, and cut the VPN block to the two sentences about it being its own zone.
Menu names in the UniFi console move between versions, and the firewall section in particular has moved recently. Confirm the paths in the version the site is running before the session rather than in front of the room.
2Open (0:00, 4 minutes)
Here is last night at a client site. Put the log on the screen. These are attempts to reach that site from the internet, from addresses nobody there has ever heard of, and there are hundreds of them. This is not an attack and nobody is being targeted. This is what the public address of every business looks like every night, and it has been happening at every site we run for as long as they have been connected. Nothing got in. Today is why nothing got in, what would have to be misconfigured for something to, and the one rule people ask us for that would hand them the building.
- Scroll the log rather than summarizing it. The volume is the point, and it does the work no explanation does.
- Say where the hour goes: the firewall makes one decision per packet, and everything else is the order it reads the rules in and what it already knows about conversations in progress.
3Concept (0:04, 23 minutes)
Why a reply gets back in (5 min)
- Pose it as a question rather than stating the mechanism: a workstation loads a website, the answer comes back from an address nobody trusts, and no rule permits it. So why does it arrive?
- Take an answer or two, then give the mechanism: the firewall wrote the request down. Source address and port, destination address and port, protocol, in a state table.
- Arriving packets are checked against that table before any rule. A match means this conversation was started from inside, so it passes.
- Then the three consequences, and say them as consequences rather than facts, because that is how they will be recalled: rules are for traffic that starts somewhere, so permitting staff to the internet is one rule and every reply comes back on its own. Traffic starting outside matches nothing, so it is judged by rules alone. And entries expire, which is why an idle session dies and an active one does not.
- Flag that last one. It is the seventh check question and people get it wrong.
Rule order (4 min)
- One sentence, said slowly: rules are read top to bottom and the first match decides. Nothing below it is consulted.
- Then the example on the board, with the block at position 1 and the printer exception at position 2. Ask the room whether guests can print before you answer.
- Land what is actually happening, because "the rule is broken" is the wrong model: rule 2 is not wrong and not disabled, it is never consulted, because something above it already decided every packet it would have matched.
- State the rule: the specific exception goes above the general block.
- Then the implicit deny, and give the reasoning rather than the definition: anything no rule matched is blocked, which is why rules are written for what is permitted. The list of things to forbid has no end and the list of things the business needs is short.
Zones (3 min)
- Motivate it with the arithmetic: six internal networks make thirty pairs, and every new network makes more. Nobody maintains that.
- Name the six built-in zones and what each covers. Spend the time on DMZ, because it is the one that gets misused: a network for machines that must be reachable from outside, arranged so a compromised machine in it has no route onward.
- Show the shape of a rule as a sentence: from this zone, to that zone, this traffic, allow or block. That is the form they will read on screen in eight minutes.
Translation (5 min)
- Name it once and then use the plain word: this is NAT, network address translation. Start from why it has to exist, which is that a packet with a source of 192.168.10.15 could never be answered, because that address is in a million buildings and names none of them.
- Walk the four steps in section 5 of the Learner Guide on the board with real numbers, and write the table entry out: 203.0.113.20 port 40001 means 192.168.10.15 port 51900.
- Ask what happens with a second workstation, then answer it: a different port on the same public address. That is the thing to land, because it is what lets a building share one address.
- Be precise about the security claim, because people overstate it: translation hides internal addresses, and the rules are what decide who gets in. Hiding is a side effect, not the control.
Port forwarding (4 min)
- Set it up from the gap: traffic starting outside matches nothing in the table, and the firewall has no way to know which internal machine it was for.
- Name the fields off the console form: rule name, WAN interface, incoming public address and port, source restriction, internal destination address and port, protocol.
- Then say plainly what has been created: a permanent opening from the entire internet to one service on one machine, found by scanners within hours, exposed continuously rather than when somebody is using it. Point back at the open.
- Give the one that matters most: a forward of port 3389 to a server puts a sign-in prompt for that machine in front of the whole internet. That is the answer to give when it is requested, and the alternative is the next block.
- Add the one field that genuinely helps, restricting the source to named addresses, and the one that does not, moving it to an unusual external port.
VPN (2 min)
- An encrypted tunnel that makes a remote machine or office behave as though attached to the local network, and it appears as its own zone rather than being trusted automatically.
- Remote access replaces the forward: authentication happens before anything internal is reachable, and there is no permanently open service.
- Site to site in one line, with the constraint that bites: both ends need a route, and the two address ranges must not overlap.
- Finish with the mistake, because it is the sixth check question: a tunnel grants reachability, not access. What the remote machine may do is still a rule.
4Show (0:27, 10 minutes)
- Read the rule list top to bottom. Read each custom rule aloud as a sentence: from this zone, to that zone, this traffic, allowed or blocked. Do not skip ahead to the interesting ones; the order is the lesson.
- Stop at the specific-above-general pair. Point at both, then ask the room what would happen if they were swapped. Let somebody answer before you confirm it.
- Open the port forwards. For each one, read the public port, the internal machine and port, and whether the source is restricted. Say out loud what is exposed by each. If the site has none, say so, and say that this is the good outcome.
- Back to the log. Find three lines: a scan from outside, something internal blocked by design, and a staff machine being blocked doing ordinary work. Read each one field by field.
- Sit on the third one. Ask the room what rule they would add. Then do not add it, and say why: a blocked line is a fact about what was attempted, not a request for a rule, and the first job is finding out what the destination actually is.
5Do (0:37, 12 minutes)
- Rules as sentences. Everyone writes five rules from the list in the form: from this zone, to that zone, this traffic, allowed or blocked. Compare two of them out loud.
- Order check. Each person finds one rule that would change behavior if moved, and says what would change.
- Classify the log. Twenty lines each, sorted into scanning from outside, internal traffic blocked by design, and ordinary work being blocked.
- One investigation. Pick one line of the third kind and work out what the user was trying to do. No rule gets added, and the exercise is to say what you would need to know before one could be.
The instinct to correct is adding a rule to clear a log line. Somebody will propose one within a minute of seeing the third category. Make them answer the three questions out loud first: what is the traffic, who asked for it, and can the same need be met by something already permitted. A rule added to quiet a log outlives the ticket by years and nobody afterwards knows why it is there.
6Check (0:49, 7 minutes)
A workstation loads a website. No rule permits that website to send anything in. Explain why the answer arrives anyway, and what would have to be true for it not to.
AnswerThe firewall recorded the outbound request in its state table, and the answer matches that entry, so it is recognized as part of a conversation this network started and passes without consulting a rule. It would not arrive if the entry had expired, if the reply came from a different address or port than the one recorded, or if the outbound request had never been permitted in the first place.
A rule list blocks the guest network from all internal networks at position 1 and permits guest to the internal printer at position 2. Guests cannot print. What is wrong, and what is the fix?
AnswerThe first match decides, so every packet from guest to the printer is caught by the block at position 1 and the rule at position 2 is never consulted. Move the printer rule above the block. Everything else from guest stays blocked.
What is the implicit deny, and why does it mean rules are written for what is permitted rather than for what is forbidden?
AnswerIt is the decision applied to anything no rule matched, and on a firewall worth using it is to block. Because everything is blocked unless something permits it, the rule list only has to describe what the business actually needs, which is short and knowable. A list of things to forbid has no end.
Describe what NAT does to a packet on the way out and on the way back, and say what the port number is doing in that process.
AnswerOn the way out the firewall replaces the private source address with the site's public address, picks a source port of its own, and records that the pairing of public address and that port means this internal machine and its original port. On the way back it looks the port up and rewrites the destination back to the internal machine. The port is what lets hundreds of machines share one public address, because every conversation gets its own number on the public side.
A client asks for remote desktop to be forwarded to their server so they can work from home. Give the answer you would give and the reason, and say what to offer instead.
AnswerNo, and the reason is that it puts a sign-in prompt for that server in front of the entire internet, where automated attempts against it begin within hours of the rule being created. Offer a remote access VPN: the person authenticates first and the tunnel is built after, so nothing internal is reachable until they have proved who they are and there is no permanently open service on the public address.
A remote user's VPN connects successfully and shows as established, but they cannot reach any internal machine. What is the most likely cause, and why is a connected tunnel not evidence against it?
AnswerA missing rule from the VPN zone to the internal zone. The VPN is its own zone and traffic arriving through it is judged by the rules like anything else.
The obvious answer is that the tunnel is broken, because it is the only piece that looks like it could be. A connected tunnel proves the person authenticated and the encrypted path is up. It says nothing about what they are permitted to reach through it, and those are two separate things.
A remote desktop session to a server drops every time the user leaves it alone for a while, and never drops while they are working in it. The network is otherwise healthy. What is happening?
AnswerThe state table entry for that conversation is expiring during the idle period. With nothing crossing it for long enough the firewall drops the entry, and the next packet no longer matches a conversation in progress, so it is treated as a new arrival and blocked. An active session keeps the entry alive, which is why it never drops while the user is typing.
The obvious answers are the wireless connection or the server sleeping, and the pattern rules both out: a fault that only ever appears during inactivity and never during use is the state table, not the link.
7Close (0:56, 4 minutes)
Work before the next session
- The practice steps in section 9 of the Learner Guide, with twenty classified log lines brought along.
- The ordering rule and the implicit deny, each said in one sentence from memory.
- The Network+ companion, chapter 5, security devices and secure protocols.
Next session
07 - Wi-Fi, the last session of this course. Why a shared radio medium behaves differently from a cable, what the channel and width settings actually do, and how to drive a slow wireless complaint to a cause.
Open items to settle
- Any port forward found during the session that nobody can account for, raised as a ticket with the client rather than left in the room.
- Whether the sites we run have remote access available, so that the answer to a remote desktop request is an offer rather than only a refusal.
- Whether blocked-traffic logging is on at the sites where it would be useful, and where those logs are kept.
8Sources
- Internet Engineering Task Force, RFC 3022, Traditional IP Network Address Translator, for address and port translation and the table that reverses it.
- Internet Engineering Task Force, RFC 2979, Behavior of and Requirements for Internet Firewalls, for stateful behavior and default-deny.
- Ubiquiti, Zone-Based Firewalls in UniFi, for the six built-in zones and how custom rules are ordered against built-in ones.
- Ubiquiti, UniFi Gateway, Port Forwarding, for the fields on a forwarding rule.
- Ubiquiti, Traffic and Policy Management in UniFi.
- Cybersecurity and Infrastructure Security Agency, Securing Network Infrastructure Devices, on limiting services exposed to the internet.
- Kodi A. Cochran, CompTIA Network+ (N10-009) Certification Companion (Apress, 2026), chapter 5, security devices and secure protocols.
9After the session
| Delivered on | |
| Attendance | |
| What landed | |
| What did not | |
| Changes for next time | |
| Backlog items created |