This simulator models a stateful firewall appliance sitting between a trusted client and an external server, evaluating an ordered rule set against new outbound connections and tracking handshake state so that matching return traffic can be permitted. Toggle rules, enable or disable stateful tracking, inject TCP messages by hand or run a full handshake, and watch how rule order, state and idle timeout each decide whether a message is allowed or denied.
• A real-time 3D cutaway workbench of the trusted client NIC, ingress interface/PHY, policy-processing ASIC, connection-state memory, egress interface and external test server, with home view, focus-selected-part, toggleable full-enclosure view, exploded view, auto-rotate and expand controls, tappable numbered components with callouts, and labels matching a companion diagram. • Six live controls: enable rule 20 (allow outbound HTTPS), enable rule 10 (deny outbound HTTPS first, evaluated before rule 20), track/admit matching connection state (stateful tracking on/off), next injected TCP message type (client SYN, server SYN-ACK, client final ACK, established server data, unsolicited inbound SYN), reply source port (443 matching vs. 8443 wrong tuple) and idle connection-state lifetime. • Play/pause, single-step (0.1 s) and larger-step (1 s) time controls, plus a playback-speed selector (10x slow motion, real time, 10x faster, 1 minute per second). • Five trial actions: start trial, stop trial, send test traffic (injects the selected message type), run TCP handshake (drives SYN → SYN-ACK → ACK automatically) and clear connection state, with a live "what is happening" sequence narrative and connection-state tokens (SYN_SENT / SYN_RECEIVED / ESTABLISHED). • Six live metrics: allowed messages, denied messages, whether a connection is currently tracked, whether the handshake is complete, connection idle time and total messages inspected. • A Curves & measurements tab with a connection-state-over-time chart, an allowed/denied-messages chart, the full model equations and snapshot measurements. • An Experiments tab with four guided scenarios (create a connection via full handshake, an earlier deny rule blocking the same flow, disabling state tracking, and a reply from the wrong source port), an automated model-verification bench of independent checks, and a timestamped event log with a copyable trial report. • A Learn & assess tab with four guided lessons, a two-question knowledge-check quiz and a written scope/reference statement.
New outbound SYNs are evaluated against an ordered rule list: the model demonstrates that a matching deny placed earlier in the list (rule 10) wins over a later allow (rule 20) for the identical flow, even though the later rule is enabled — first match wins, and rule order is not a suggestion. Once a SYN is accepted, the state tracker advances through SYN_SENT, then SYN_RECEIVED after a matching SYN-ACK, then ESTABLISHED after the client's final ACK, representing an abstract handshake rather than full TCP sequence-number validation.
Return traffic is treated differently from new flows: an established connection's reply is admitted only if it matches the expected reverse tuple (source port) and the tracked state has not expired, regardless of what the current new-flow rules say. Disabling stateful tracking removes this reverse-flow allowance entirely, so even a successfully permitted outbound SYN gets no special treatment for its reply — the no-state-tracking experiment is built to show exactly this gap.
The equations panel states the rule logic as "New SYN: first matching rule wins," the state progression as SYN → SYN_SENT, matching SYN-ACK → SYN_RECEIVED, final ACK → ESTABLISHED, and the return-traffic rule as "Established reply requires reverse tuple and unexpired state." The configurable idle connection-state lifetime removes a tracked connection once elapsed idle time reaches that value, after which even a previously valid reply is denied again — an important distinction from a firewall config change, since existing state is not revoked just because the underlying rules change while a session is active.
This is a fixed-flow policy and handshake fixture, not a full TCP/IP stack: there is no sequence-number window validation, no NAT, no TLS inspection and no real packet filtering. All addresses (10.0.10.10:51514 to 198.51.100.20:443), rule evaluation and fault injection are simulated locally with illustrative timing and equipment geometry.
Rule order determines the outcome: the model evaluates rules top to bottom and the first match wins. The "earlier deny" experiment enables rule 10 (deny outbound HTTPS) ahead of rule 20 (allow outbound HTTPS) — even with rule 20 enabled, the earlier deny still blocks the flow, because it is reached and matched first.
Permitting an outbound SYN and permitting its return traffic are two separate checks in this model. With stateful tracking disabled, the firewall does not build a connection-state entry for the outbound flow, so an inbound reply — even a legitimate one from the correct server tuple — has no matching state to be admitted under and is denied.
Established return traffic must match the expected reverse tuple recorded when the connection was tracked. The "wrong reverse tuple" experiment sets the reply source port to 8443 instead of the expected 443, and the firewall denies it even though a session is tracked, because the reply does not match the tuple that session expects.
It is a fixed-flow policy and handshake fixture rather than a full TCP/IP implementation. It excludes TCP sequence-number window validation, NAT, TLS/deep-packet inspection and real packet filtering, and all rule evaluation, addressing and state transitions are simulated locally with illustrative timing.