01 / What a firewall decides and why

One question: who may talk to the application?

A firewall controls traffic between networks. A packet is a small addressed unit of data. A policy is an access rule. A flow is related traffic between endpoints; a session is the firewall’s tracked conversation state. A port identifies a transport endpoint; lesson 3 explains it fully. A firewall permit is permission, not proof of delivery or safety.

Worked example: staff LabClient needs the local application on LabServer, TCP 8080. The intended rule names this client, this server, the incoming/outgoing interfaces and that service. New unmatched forwarded traffic is denied in this baseline. Replies matching the allowed session can return; a new server-initiated connection is a different decision. This resembles a guest list, but a guest list cannot tell whether the application is running.

Keep these terms beside the explorer

MAC address

A link-layer address of a network interface, including a virtual NIC. This pack uses symbolic names instead of inventing actual MAC values.

Broadcast

A frame addressed to all receivers on its local Ethernet segment. The ARP request shown here is a local broadcast; it is not routed into the other lab subnet.

Frame / packet / segment

Ethernet carries a local-link frame; IP carries an addressed packet inside it; TCP carries a segment inside IP. These names describe different protocol layers.

Ingress / egress

Ingress is where traffic enters a device; egress is where it leaves. Their interface names must match the real cable mapping.

Implicit denial

The unmatched forwarding decision when no configured permit applies in this specified baseline. It is not a conclusion drawn merely from a timeout.

Evidence correlation

Matching observations by time and flow identifiers so that a server response, request and policy/session record refer to the same test.

Build the idea: a decision has several separate conditions

Start with the business request: “This disposable client needs the local web application.” Convert that sentence into a narrow flow. Source means the sender of a packet; destination means its intended receiver. An interface is the named network connection used to enter or leave a device. The request enters FortiGate through the client-facing port and leaves toward the server. The reply reverses these endpoint roles.

Keep five questions separate: is the cable/interface usable; does a route select a valid next hop; can local neighbors resolve each other; does policy permit this flow; and is the application listening and responding? A failure in any one can prevent the user’s request from succeeding. The firewall does not create the server’s return route or start its application.

Read the headers as nested envelopes

An Ethernet frame carries data across one local link. Its MAC addresses name the local sender and next receiver. Inside it, an IP packet names the remote IP endpoints. Inside that, a TCP segment identifies transport endpoints using ports and flags. Finally, HTTP carries the application request. Ethernet is replaced at this routed firewall; the IP/port endpoints remain unchanged here because NAT is off. Checksums, options and byte layout are beyond this introductory excerpt.

In the explorer, C_MAC, FG_P2_MAC, FG_P3_MAC and S_MAC are symbolic names for the four data-interface MACs. They are deliberately not invented hexadecimal addresses. ARP asks for a local IP neighbor’s MAC; it is not a TCP or UDP message and has no transport ports. A cached neighbor entry may make a new ARP exchange unnecessary.

Worked decision

Request A: client 10.77.10.10, destination 10.77.20.10, TCP destination 8080, client-facing ingress and server-facing egress. In the specified baseline it matches the narrow permit. Request B is a new connection with TCP destination 22. It does not match that permit and has no other matching forwarding policy in this baseline. Predict a drop; do not call it an observed result until a real controlled test and matching evidence exist. The practical lab below deliberately stops the service instead—it teaches why identical user symptoms may have different causes.

Lab 01 in smaller checkpoints

Conditional practical: complete the exact-build setup and baseline gates first. Until then, use this as guided analysis and leave observed results blank.

Readiness: use guided analysis if setup acceptance is incomplete. The instructor must establish the exact-build baseline; beginners should not paste unverified FortiGate configuration. Open the server and client consoles and verify their node names before typing. Commands below run on Ubuntu, not at the FortiGate # prompt.

1. On the server, confirm that qcs-http.py is the supplied file at the agreed location. If it is missing, stop for the approved private transfer; do not create Internet connectivity.
2. Start the helper in the foreground. If “address already in use” appears, stop and identify the existing listener; do not kill an unknown process. If “cannot assign requested address” appears, inspect the server’s actual interface address.
3. From the separate client console, make one numeric bounded request. Write the HTTP status/body observation, not just “works.”
4. Record the instructor’s matching policy/session evidence if available. If it is unavailable, label that part unverified rather than inferring the policy ID from success.
5. Press Ctrl+C only in the helper terminal, then repeat one client request. Note whether the result is refusal, timeout or another error; do not rename every error “blocked.”
6. Restart the same helper, repeat the request and compare with the original baseline. Cleanup stops only the helper when finished.

SERVER foreground:
python3 qcs-http.py

CLIENT:
curl --noproxy "*" --connect-timeout 3 --max-time 5 --include http://10.77.20.10:8080/

Acceptance: one baseline response, one service-stop failure and one restored response, with the actual timestamps and limitations recorded. Stop condition: after one failed request and up to three focused checks—helper, route, instructor’s policy evidence—restore the fault before further diagnosis.

See the conversation

Detailed diagram: scroll horizontally to inspect full-size labels. The text path below reflows on phones.

Slow packet film: 12 steps, six seconds per step (72 seconds total). Pause to inspect the headers, or use the explorer above at 10/15 seconds per step. Film timing is instructional; it is not measured network latency.

No autoplay. Use native pause or leave the static diagram visible. Reusable GIF download. The static diagram and caption are the reduced-motion alternative; GIFs are not embedded.

Practical 01 • predict, test, explain

Conditional practical: complete the exact-build setup and baseline gates first. Until then, use this as guided analysis and leave observed results blank.

Prerequisite: the instructor has passed setup acceptance. Otherwise complete the same worksheet as guided analysis only. Estimated study time: 60–90 minutes.

1. Write the intended access tuple: 10.77.10.10 → 10.77.20.10, TCP destination 8080, port2 → port3.
2. In the server console, start the supplied helper with the command below. It stays in the foreground. In the separate client console run the bounded curl request.
3. Expected, not observed here: HTTP 200 and QCS local lab text. Match the time and endpoint tuple to the server request line and instructor’s policy log/session evidence.
4. Fault: press Ctrl+C in the server console to stop just the helper. Run one fresh client request. A refusal or timeout now illustrates a service failure, not proof of firewall denial.
5. Rollback: restart the same helper and retry. Acceptance: HTTP 200 returns again; rule scope stayed unchanged. Cleanup: Ctrl+C only if finished with the service.

SERVER Ubuntu console:
python3 qcs-http.py

CLIENT Ubuntu console:
curl --noproxy "*" --connect-timeout 3 --max-time 5 --include http://10.77.20.10:8080/

python3 runs the local helper. curl requests a URL; --noproxy "*" avoids proxy dependencies, the timeout options bound waiting, and --include shows the status headers. The numeric URL requires no DNS.

Bounded diagnosis and practice

If the baseline fails: (1) confirm the helper is running, (2) inspect client/server routes as lesson 2 teaches, (3) ask the instructor for the matching policy/log observation. Stop without broadening rules. Practice: explain why a correct rule and a stopped service can coexist; write one permitted tuple; identify the missing evidence in “it timed out.” Suggested answers: rule ≠ listener; use the tuple above; missing route/listener/policy correlation.

Evidence and boundaries

Use the evidence worksheet. Write prediction before observation; record time, exact command, endpoints, policy ID if available and a redacted result. Leave actual-result cells blank until tested. Never paste passwords, license files, serials, full configurations or recovery backups into the preview.

Stop after one failed attempt and up to three focused checks. A timeout alone is inconclusive: service, route, host filtering or firewall policy may be responsible. Restore the stated fault before trying a different hypothesis.

More practice • explain before revealing the answer