Network Security and Defense Questions

The three-way handshake is how TCP establishes a connection before any data flows. The client sends a SYN (synchronize) segment proposing an initial sequence number, the server replies with a SYN-ACK (synchronize-acknowledge) segment proposing its own sequence number while acknowledging the client's, and the client finishes with an ACK (acknowledge) segment. Only after all three steps is the connection considered established.

The three steps

1. Client to server: SYN flag set, sequence number x (a locally chosen initial value).
2. Server to client: SYN and ACK flags both set, sequence number y (the server's own initial value), acknowledgment number x+1 (confirming the client's SYN).
3. Client to server: ACK flag set, sequence number x+1, acknowledgment number y+1 (confirming the server's SYN-ACK). The connection is now established.

The server allocates a small amount of state, a "half-open" entry in its connection backlog, the moment it sends the SYN-ACK in step 2, before it has any proof the client is real. That allocation is exactly what a SYN flood targets.

How this helps detect a SYN flood

Normal traffic shows roughly matched counts of SYNs and completed connections. A flood shows a large, sustained excess of SYNs with few or no matching final ACKs, meaning many connections stuck half-open, which shows up as backlog growth and an elevated SYN-to-established ratio in connection-tracking telemetry. Attackers also commonly spoof the source address of flood SYNs so the traffic cannot easily be traced or blocked, which means the real attacker never receives the SYN-ACK and so never legitimately completes step 3.

Mitigation: SYN cookies

Instead of storing state after step 2, the server encodes the connection details, a cryptographic function of the source and destination address and port plus a timestamp, directly into the sequence number it sends in the SYN-ACK, allocating no memory yet. Only when the final ACK returns with the corresponding acknowledgment number does the server reconstruct and verify the connection was legitimate before allocating real state. This defends against a flood because spoofed or abandoned half-open connections cost the server nothing, so no volume of unanswered SYNs can exhaust the connection table.

Worked example

A normal handshake trace: client sends sequence 1000 (SYN); server replies sequence 5000, acknowledgment 1001 (SYN-ACK); client replies sequence 1001, acknowledgment 5001 (ACK), connection established. During a flood, connection-tracking telemetry might show 50,000 SYNs per second arriving with a source-address pattern that looks spoofed (many one-off addresses never seen again), against fewer than 50 completed handshakes per second, a SYN-to-established ratio around 1000 to 1. A healthy baseline ratio sits close to 1 to 1, and that ratio, not raw SYN volume alone, is the real tell, since a genuine flash crowd also raises SYN volume but keeps the ratio near 1 to 1 because real clients complete the handshake.

Trade-offs and pitfalls

SYN cookies stop backend connection-table exhaustion, but they do not stop the SYN packets themselves from consuming link bandwidth or router CPU, so a large enough flood still needs upstream volumetric mitigation as well. A few legacy TCP options can be dropped when cookies engage, which is mostly a non-issue on modern implementations but worth knowing it is not perfectly transparent.

Direct answer

At 50,000 concurrent users across regions, treat authentication and tunnel termination as two separately-scaled problems: federate and shard the identity layer so no single authentication service is a global bottleneck, terminate tunnels at regional points of presence close to each user rather than backhauling everyone to one location, and pick the tunnel protocol based on per-session overhead and how gracefully it handles a client moving networks, favoring WireGuard (or a WireGuard-based concentrator) over classic Internet Protocol security (IPsec)/Internet Key Exchange (IKE) for this profile, with a Transport Layer Security (TLS)-based fallback for restrictive networks.

Structured elaboration

flowchart TB
    U[Remote users] --> DNS[Geo DNS or anycast broker]
    DNS --> R1[Region A concentrators]
    DNS --> R2[Region B concentrators]
    R1 --> AUTH1[Region A auth front end]
    R2 --> AUTH2[Region B auth front end]
    AUTH1 --> IDP[Central identity provider]
    AUTH2 --> IDP
    R1 --> APPS[Internal resources]
    R2 --> APPS

1. Protocol choice. IPsec/IKE is standard and broadly supported, but its per-session negotiation state and rekey overhead add up at very large concurrent-session counts, and it recovers slowly when a client's network changes (Wi-Fi to cellular). A TLS-based VPN benefits from looking like ordinary HTTPS through almost any firewall, but still carries a full TCP-plus-TLS stack's overhead per session. WireGuard keeps minimal per-connection state (a peer is just a public key mapped to allowed IP ranges, with nothing to renegotiate), runs over UDP, and updates a peer's known address automatically when a valid packet arrives from a new source, which handles client roaming gracefully. Recommendation: WireGuard for the bulk of traffic, with a TLS-based VPN fallback for legacy clients or networks that only permit outbound HTTPS.
2. Authentication architecture, sharding and federation. A single centralized authentication service handling all 50,000 users' logins and periodic re-authentication would be both a bottleneck and a single point of failure. Instead, deploy regional authentication front ends that validate short-lived tokens locally, issued by a central identity provider through a federated protocol such as OpenID Connect against the corporate identity system, so only the relatively infrequent token-issuance step reaches the central service, while the frequent per-connection check is a local signature verification, not a network round trip. Shard session state by region so a regional outage affects only users natively assigned there.
3. Session brokering and load balancing. A lightweight broker, DNS-based geolocation routing or anycast, directs each client to its nearest regional concentrator cluster. Within a region, a load balancer distributes new connections using a metric that reflects real capacity (concurrent-session count and crypto throughput), since a concentrator's limit is sessions and crypto work, not raw request rate.
4. Regional ingress and egress placement. Terminate tunnels close to users to minimize setup and ongoing latency. Egress placement is a separate decision driven by where internal resources actually live: if those resources are centralized, each regional point of presence needs a fast backbone path back to them, which is exactly where the split-tunnel decision below has the largest impact.
5. Split tunneling versus forced tunneling. Split tunneling routes only traffic destined for internal resources through the VPN and lets everything else, general browsing, video calls, other software-as-a-service traffic, go directly out the client's own connection. Forced tunneling routes all client traffic through the VPN and out corporate egress regardless of destination. Split tunneling dramatically reduces the bandwidth and latency load on the VPN infrastructure, at 50,000 concurrent users this is often the difference between a feasible and infeasible egress capacity requirement, but it means corporate controls like web filtering, data-loss-prevention inspection and centralized logging never see that split-off traffic, a real visibility trade-off, not just a performance one. Forced tunneling preserves full visibility but multiplies concentrator and egress bandwidth by however much non-corporate traffic each client generates, usually the larger cost driver at this scale. A common middle ground is split tunneling with a defined, audited exception list.
6. Key management. WireGuard's per-peer static keypairs (or IPsec certificates) need a provisioning and rotation pipeline tied to the same identity system as authentication: issue a new keypair when a device is enrolled through mobile device management, revoke it promptly when a device or user is deprovisioned. Regional concentrators need a fast path to learn about revocations, since a compromised or terminated-employee device staying valid for hours across every region is a meaningful exposure window.
7. NAT and edge constraints. WireGuard and IPsec both need UDP to reach the concentrator, which some restrictive corporate, hotel or airport networks block or throttle. A fallback path over TCP port 443 needs to exist for clients on those networks, at some cost to the primary protocol's throughput and latency advantages.
8. Client performance considerations. Keepalive intervals need tuning against mobile battery life (frequent keepalives keep NAT mappings alive but drain battery faster) versus how quickly a dead session is detected and failed over. WireGuard's cheap, stateless handshake is an advantage here: a client can drop and rejoin cheaply compared to a heavier IKE renegotiation.
9. Telemetry for large-scale troubleshooting. Per-region dashboards of concurrent sessions, tunnel-setup latency (P50/P95/P99, the 50th/95th/99th percentile), and concentrator resource utilization; per-user session history recording which regional point of presence, connect and disconnect times, and disconnect cause (client-initiated, keepalive timeout, server-side eviction); and aggregate authentication latency and failure rate split by region, so a regional identity-provider or network issue shows up as an isolated regional anomaly rather than a confusing global one.

Worked example

50,000 concurrent users spread evenly across 4 regions averages 12,500 sessions per region. If each concentrator instance is rated for a conservative 3,000 concurrent WireGuard sessions (a modest figure given WireGuard's small per-session footprint), a region needs

$\left\lceil \frac{12{,}500}{3{,}000} \right\rceil = 5 \text{ instances at steady state}$

plus at least one more for N+1 redundancy, six instances per region, twenty-four total, a number the capacity-planning and autoscaling policy should be built around directly rather than discovered after an outage.

Trade-offs and pitfalls

WireGuard's lightweight scaling and roaming behavior come at the cost of some of the enterprise tooling maturity (granular per-application policy, specific compliance certifications) that established IPsec or SSL-VPN (the older industry name for a TLS-based VPN) products have accumulated, worth weighing explicitly for a highly regulated industry. Sharding authentication by region improves resilience but means a traveling user either needs to reauthenticate against the new region's front end or the token-validation public keys need to already be replicated everywhere, an easy detail to miss until someone travels and gets locked out.

A secure Software-Defined Wide Area Network (SD-WAN, an overlay network where a central controller programs encrypted tunnels and routing policy across many sites rather than each site being hand-configured) for 200 branches needs a policy model that segments by application rather than by branch, centralized key management the controller drives rather than manual per-site work, and a default-deny posture between segments enforced locally at every branch edge.

Policy model

Define a small number of application-level segments (for example: point-of-sale, corporate IT, guest/BYOD, IoT/building systems), independent of which branch a device sits in, and express policy as segment-to-segment rules rather than branch-to-branch rules. A compromised guest-segment device at branch 12 should be unable to reach the point-of-sale segment at branch 87 by default, regardless of the underlying encrypted overlay connecting those two sites. Default-deny between segments, with a short, auditable allow-list of the specific cross-segment paths the business actually needs (for example, point-of-sale needs to reach a central payment gateway segment, nothing else).

Key distribution and rotation

Each branch edge device is provisioned with a unique device identity certificate at onboarding, issued by an internal certificate authority the SD-WAN controller manages or delegates to. Tunnels (built on IPsec, or the vendor's own encrypted overlay protocol) authenticate using these certificates rather than a single shared pre-shared key across all 200 sites, so compromising one branch's key material does not expose the others. The controller drives automated, scheduled key/security-association rotation and certificate renewal well before expiry, which matters specifically because 200 sites makes manual rotation impractical and error-prone.

Orchestration

A centralized controller computes and pushes the segment policy and tunnel configuration to every branch edge as policy-as-code, so a new branch can be zero-touch provisioned (ship the device, it phones home to the controller, receives its identity and policy, and is live) instead of an engineer configuring it by hand. Branch edges report policy compliance and drift back to the controller, so a device whose local configuration has diverged from the centrally-computed intent is visible rather than silently inconsistent.

Inter-branch traffic and exception workflows

Enforcement happens locally at each branch edge, not only centrally: the edge device itself computes and applies the same policy the controller pushed, so even a branch that's temporarily disconnected from the controller keeps enforcing its last-known-good policy rather than failing open. Exceptions (a specific application at a specific branch needing a cross-segment path not covered by the standard policy) go through a scoped, time-limited approval workflow: a request ties to a specific source segment, destination segment, and expiry, is approved by a named owner, and is pushed only to the branches actually involved, with automatic expiry and an audit log entry, never a blanket or permanent carve-out.

Trade-offs

Centralizing policy computation creates a single point of control whose compromise or outage is high-impact; mitigate with controller high-availability and by ensuring branch edges cache and keep enforcing their last policy during any controller outage rather than depending on constant connectivity to the controller to remain secure. Keeping the segment count small (application-level, not branch-level) is what keeps the 200-site policy matrix tractable; a bespoke per-branch ruleset at this scale becomes unauditable and is the more common real-world failure mode than any cryptographic weakness in the design.

Direct answer

Egress filtering flips the usual firewall focus from "what can come in" to "what is allowed to leave." The core move is a default-deny outbound policy validated against actual application need, layered with DNS-layer controls and behavioral monitoring, because a pure IP/port allow-list cannot see encrypted, encoded, or DNS-tunneled exfiltration on its own.

Structured elaboration

Rule strategy: allow-list vs deny-list.

• Allow-list (default deny outbound, only known-good destinations/ports permitted): more secure, but higher operational cost. It needs an accurate application inventory and breaks whenever a team adopts a new SaaS (software-as-a-service) integration without updating the rule set.
• Deny-list (default allow, block known-bad destinations): cheaper to roll out, but it is always chasing a moving target. It can never enumerate every bad actor, so it catches known threats and misses novel ones by construction.

DNS filtering. Force all resolution through a controlled internal resolver, block resolution to newly-registered or known-malicious domains, and sinkhole known-bad domains to a monitored address instead of letting the query resolve normally. Also watch the DNS traffic itself for tunneling patterns: unusually high query volume from one host, queries with long or high-entropy subdomains, and heavy use of TXT records, which are all signs someone is smuggling data out one DNS label at a time.

Blocking residential IP ranges. Exfiltration and command-and-control traffic increasingly routes through residential proxy networks specifically to blend in with normal consumer traffic and dodge datacenter-IP block lists. Since a server subnet has no legitimate reason to talk directly to residential internet service provider address space, you can block outbound connections from servers to those ranges with very low risk of breaking real functionality.

Handling encrypted exfiltration channels. TLS (Transport Layer Security) hides the payload, so the control has to work on metadata instead of content: inspect the certificate and the Server Name Indication at a TLS-terminating or TLS-inspecting proxy, check destination reputation, and watch for unusual connection shape (a small, steady trickle of bytes at regular intervals looks like a beacon or slow exfiltration, not like a normal browsing session). Routing all outbound web traffic through an authenticated forward proxy means every egress path is at least visible and attributable to a specific process or user, and adding data loss prevention (DLP) content inspection at that proxy catches sensitive data leaving in the clear, though DLP cannot see inside a channel it cannot decrypt.

Validating it actually works. Writing the rules is not enough. Run a controlled exfiltration simulation (attempt a small test transfer through DNS, ICMP, and a common cloud storage API) and confirm each attempt is blocked and logged; review the default-deny hits in the firewall/proxy logs to prove the policy is doing something, not just present in the config; and plant canary domains or files that should never be reachable, so any hit on them is an unambiguous signal.

Worked example

A default-deny egress policy for an application server subnet, in nftables syntax:

table inet egress_filter {
  chain outbound {
    type filter hook output priority 0; policy drop;

    # allow established/related return traffic
    ct state established,related accept

    # allow DNS only to the internal resolver
    ip daddr 10.0.0.53 udp dport 53 accept
    ip daddr 10.0.0.53 tcp dport 53 accept

    # allow HTTPS only to the internal forward proxy (TLS inspection happens there)
    ip daddr 10.0.0.10 tcp dport 3128 accept

    # allow patching / package repo mirror
    ip daddr 10.0.0.20 tcp dport 443 accept

    # allow log shipping to the monitoring collector
    ip daddr 10.0.0.30 tcp dport 4317 accept

    # log then drop everything else outbound
    log prefix "EGRESS-DENY: " drop
  }
}

Every allowed destination is a specific, known-good internal service. Anything else, including a direct HTTPS connection straight to the internet that skips the inspecting proxy, gets logged and dropped, which is exactly the allow-list posture described above.

Trade-offs and pitfalls

A strict allow-list breaks a legitimate but unlisted integration the first time a team adds one, so it needs an intake/change-request process or it turns into a source of constant tickets. Port-based filtering alone is close to useless for egress today, since nearly everything, legitimate and malicious, tunnels over port 443, so the real control has to be domain/SNI-based or proxy-based, not "block everything except 443." Allow-listing IP addresses or domains also does not stop an attacker who exfiltrates to a destination the organization already uses legitimately, such as its own cloud storage bucket, since that destination is on the allow-list by definition; that gap is why the DLP and traffic-shape monitoring pieces matter, not just the destination list. Finally, forgetting to treat DNS as its own egress channel is a common miss: an allowed path to "the" resolver still enables tunneling if nothing inspects query volume or entropy.

Direct answer

All four are different attacks on different security properties: eavesdropping and MITM (man-in-the-middle) both compromise confidentiality/integrity by intercepting traffic, IP/ARP (Address Resolution Protocol) spoofing is the technique that often enables MITM by forging addresses, and DDoS (distributed denial-of-service) attacks availability instead by overwhelming a target with traffic from many sources.

Structured elaboration

Worked example

Take ARP spoofing leading to MITM concretely: the attacker broadcasts a forged ARP reply claiming the gateway's IP (say 10.0.0.1) belongs to the attacker's MAC address. Every host that accepts this poisons its ARP cache and starts sending gateway-bound traffic to the attacker instead, who can forward it on (invisibly relaying it while reading/altering it) to preserve connectivity. Dynamic ARP Inspection stops this specific chain: it checks each ARP packet's claimed IP-to-MAC binding against the bindings the switch already learned from legitimate DHCP transactions (via DHCP snooping), and drops the forged reply before it ever reaches the victim hosts.

Trade-offs and pitfalls

• Encrypting traffic stops an eavesdropper from reading content, but not from observing metadata (who is talking to whom, how much, how often); traffic analysis is a real residual risk even with TLS everywhere.
• DAI and DHCP snooping require every legitimate DHCP transaction to actually pass through the switch that builds the binding table; a misconfigured trunk/uplink trust setting either blocks legitimate leases or defeats the protection.
• Ingress/egress filtering against IP spoofing assumes each interface's expected source range is known and stable; asymmetric routing can break strict reverse-path checks and force a looser (and less protective) mode.
• DDoS mitigation via scrubbing/anycast is a network-design decision made in advance, not something you can bolt on mid-attack; it also adds an ongoing dependency on (and cost of) an upstream provider.