Network Perimeter Defense — Firewalls, Load Balancing, and VPN Tunneling
The perimeter model
A network’s edge is where trust changes — traffic crossing from the public internet into your infrastructure is untrusted by default. Every packet that crosses that boundary goes through a series of checks: does this packet match an allowed rule? Is there already an active connection for this flow? Is the traffic legitimate application data or something else?
The four main approaches are packet filters, stateful inspection firewalls, proxies, and Unified Threat Management (UTM) appliances. They trade depth of inspection against throughput. This post walks through the algorithmic difference between packet filtering and stateful inspection, then moves to how load balancing distributes traffic across backends once it’s passed the firewall, and finally compares two common VPN tunneling modes — IPSec site-to-site and WireGuard client-based.
Firewall architectures: packet filter vs stateful inspection
A packet filter (layer 3/4) evaluates every incoming packet against a rule set independently. Each packet must match source prefix, destination prefix, port range, and TCP flags against the first matching rule. There is no memory of previous packets.
A stateful firewall adds a connection tracking table. The first packet of a new flow (typically a SYN with no payload) gets evaluated against rules just like a packet filter would. Once accepted, the firewall records the flow’s 4-tuple and reverse-key in a table. All subsequent packets matching that flow skip rule evaluation entirely — they hit a fast-path.
The difference matters under load. A packet filter does O(N_rules × packets) work per packet. A stateful firewall turns most packets into an O(1) hash-table lookup.
The demo simulates six packets through both engines side by side. Packet 1 (a SYN initiating a connection) gets accepted by both — the stateful firewall creates a tracking entry, labeled “new connection.” Packets 2 and 4 are return traffic on that flow (ACK and PSH+ACK from server to client). The packet filter drops both because they don’t match any rule in the table — there is no standalone ACCEPT rule for return packets on port 443 coming from the server. The stateful firewall accepts them via its fast-path, because it remembers the established flow.
Packet 5 (an SYN from an outside IP) hits neither rule’s prefix and both drop it. Packet 6 (data without a prior handshake) is also dropped by both, but for different reasons: the packet filter rejects it because PSH+ACK isn’t in the allowed flags list; the stateful firewall rejects it because no NEW flow exists for this source/port combination.
The takeaway: stateful inspection doesn’t just allow return traffic — it avoids re-evaluating every rule on every single packet, which is why modern firewalls use connection tracking tables as their first-pass check. Proxy firewalls take a different approach entirely (they terminate connections and rebuild them), which we’ll skip here to focus on the packet-level mechanisms.
Load balancing strategies
Once traffic passes the firewall, it often needs distribution across multiple backend servers. The strategy you choose determines how traffic flows under asymmetric load — which is every real scenario.
The demo uses three backends with weights 3:5:2 (web-1:web-2:web-3) and sends eight requests through each strategy:
Round-robin distributes evenly — web-1 gets 3, web-2 gets 3, web-3 gets 2. It ignores whether backends are healthy or how many connections they’re currently handling. Simple, predictable, but blind to reality.
Least-connections always picks the backend with the fewest active connections. In this run web-1 absorbed 5 of the 8 requests (62.5%) because it started with zero connections and was selected first on most iterations; by the end all three backends sat at 4 connections each after simulated completions. The strategy adapts — if one backend starts slowing down, fewer new connections route there.
Weighted round-robin expands the pool proportional to each backend’s weight. With weights 3:5:2 across 10 slots, web-2 gets half the traffic (5 of 8 requests, 62.5%) while web-3 gets none in this small sample (weight 2 maps to 2 of 10 slots, which doesn’t land in the first 8 rounds). Weighted round-robin is useful when backends have different capacities — larger servers get proportionally more traffic.
VPN tunneling modes
The second demo also compares two common VPN encapsulation modes. Both wrap original packets in outer headers to route them securely across untrusted infrastructure (the public internet), but their overhead and use cases differ.
IPSec site-to-site connects two networks through gateway appliances. It adds ~36 bytes of ESP + IPsec outer headers per packet. The encapsulated source/destination become the gateway IPs, hiding internal addresses from intermediate routers. This matters most for DNS packets — a 64-byte DNS query’s overhead jumps to 44.4%.
WireGuard client-based encrypts individual client traffic using symmetric key pairs and adds ~32 bytes of WireGuard frame overhead (lower than IPSec). Clients appear as addresses within the WG subnet to the destination, enabling zero-trust-style access without per-host rules. Keepalive packets with zero payload show absurd overhead percentages (150%) — a real-world reason VPNs batch small packets.
The encapsulation overhead shrinks dramatically for larger payloads: HTTPS traffic at 1200 bytes sees only 2.9% overhead for IPSec and 2.6% for WireGuard. This is why tunnel MTUs matter — the extra headers reduce the available payload, so TCP MSS clamping or fragmentation handling becomes important on high-throughput links.
Takeaway
A hardened network boundary works in layers: packet filtering rejects obvious mismatches early, stateful inspection reduces per-packet cost by tracking flows, load balancing distributes accepted traffic intelligently, and VPN tunneling wraps legitimate traffic in encrypted outer packets before it reaches the internet. Each layer answers a different question — who can reach what, how should it be routed, and is the path secure — and each has real algorithmic trade-offs behind its performance.