FUNDAMENTALS · MECHANISM WALKTHROUGH

Branch to Public Website
Every Hop and Translation on the Way

not the same question as "PC to Internet." this is the multi-site version — a branch that doesn't break out to the internet locally, and has to cross the WAN to a centralized edge before it ever touches the internet at all.

BRANCH LAN→ BRANCH ROUTER: ROUTE VIA SD-WAN→ OVERLAY TUNNEL→ HQ CORE→ HQ EDGE FW + PROXY→ NAT AT HQ→ INTERNET→ RETURN, SAME HOPS

01 The Full Sequence — Worked Example

The Setup — Centralized Internet Breakout

A user at Branch-12 (10.12.0.0/16) requests https://example.com. This branch has no local internet breakout — company policy routes all internet-bound traffic back through HQ for consistent URL filtering, DLP, and logging. This single design decision is the entire reason this walkthrough looks nothing like a single-firewall LAN scenario.

Setup

Local Delivery to the Branch Gateway

The switching, ARP, and local delivery to the branch router/firewall happen exactly as in a standard LAN — link, MAC learning, ARP for the gateway, frame delivered. That mechanism doesn't change here, so it isn't repeated in depth; what matters for this question starts at the next step.

LAN

Branch Router's Routing Decision

The branch router/firewall evaluates its routing/policy table for the destination. Because centralized breakout is enforced, there's no local default route straight to a WAN internet circuit — instead, the traffic matches a policy directing it into the SD-WAN overlay tunnel toward HQ.

Route

SD-WAN Path Selection and Encapsulation

The branch's SD-WAN edge wraps the packet in overlay tunnel headers and picks which underlay transport to send it over — MPLS or a broadband internet circuit — based on continuously measured live metrics (latency, loss, jitter) against that traffic class's SLA, not a static route. This dynamic choice is a materially different mechanism than a simple default-route decision.

SD-WAN

Crossing the Underlay

The encapsulated packet physically transits the chosen underlay — branch CPE, through the MPLS provider's PE routers or the broadband ISP's network — as an ordinary tunneled flow, invisible to any device along that path as anything other than generic tunnel traffic.

Underlay

Checkpoint — Arrival at HQ, Still Not on the Internet

The SD-WAN hub at HQ de-encapsulates the tunnel and the original packet re-emerges, unchanged, now sitting inside HQ's internal network. Compare this to the flat, single-firewall "PC to Internet" walkthrough: there, the packet reaches the internet edge in one hop from the LAN. Here, it has already crossed an entire WAN and is only now arriving at the network that actually owns the internet edge.

Checkpoint

HQ Core Routes Toward the Internet Edge

HQ's core switch/router forwards the packet toward the internet edge firewall based on its own, entirely separate routing table — a normal, internal routing decision with no awareness that the traffic originated at a branch three networks away.

HQ Core

HQ Edge Firewall — Policy and Centralized Inspection

The HQ internet edge firewall performs its state table lookup and policy evaluation, but here it also enforces the centralized services that were the entire point of this design: URL/web filtering, DLP inspection, and possibly transparent or explicit web proxy insertion — services that never exist at the branch level in this architecture.

HQ Firewall

NAT Happens at HQ — Not the Branch

Source translation occurs at HQ's internet edge, not the branch. To the destination server, the request appears to originate from HQ's public IP entirely — the branch's own WAN circuit and any public IP it might have are never involved in this flow at all, since the traffic never broke out locally.

NAT

Out to the Internet and Back

From HQ's edge, the request goes out to the internet exactly as in the single-firewall model, reaches the destination server, and the reply comes back addressed to HQ's public IP:port.

Internet

Return Trip — All Hops in Reverse

HQ's firewall matches the return traffic against its state table, un-NATs it, and routes it back through the core toward the SD-WAN hub, which re-encapsulates it into the overlay tunnel back to Branch-12. Note that the SD-WAN's path selection for this return leg is evaluated independently — it's entirely possible for the reply to travel over a different underlay transport than the original request did, if conditions changed in between.

Return

Delivered to the Branch User

The branch router de-encapsulates the tunnel traffic and delivers it to the user's PC over the local LAN. Total path: branch LAN → branch router → SD-WAN overlay → HQ core → HQ firewall/proxy → internet → all the way back — a materially longer, multi-organization-boundary path than the single-hop flat-network scenario.

Delivered

02 How to Explain This in an Interview

Open by naming the architectural decision, not the mechanics. "This branch doesn't break out locally — everything routes back to HQ" is the one sentence that frames everything that follows and shows you understand design intent, not just packet flow.
Contrast this explicitly against a flat, single-firewall scenario if asked to compare. Being able to say "this is the same idea as PC-to-Internet, but with an entire WAN and a second firewall boundary inserted in the middle" demonstrates you can generalize the underlying mechanism, not just recite one memorized path.
Say "NAT happens at HQ, not the branch" unprompted. It's the detail that trips people up most and directly demonstrates hands-on multi-site experience.
Mention SD-WAN path selection is dynamic, not static — a live SLA-based decision per flow, re-evaluated continuously, not a single configured route.
If asked for the trade-off of this design, be ready with it: consistent inspection and policy at the cost of added latency and WAN bandwidth consumption for every branch's internet traffic — this is exactly the kind of design trade-off question that follows a mechanism question like this one.

03 Follow-Up / Gotcha Questions

Q Why not just give every branch its own local internet breakout instead?

A Local breakout reduces WAN load and latency for internet-bound traffic, but it means every branch firewall needs to independently enforce the same security policy, and it fragments logging/DLP visibility across dozens of edge devices instead of one central point. Centralized breakout trades that latency cost for consistency and a single place to audit and control internet-bound traffic.

Q What exactly is SD-WAN's path selection measuring to make its decision?

A Continuously probed metrics per underlay transport — typically latency, jitter, and packet loss — compared against the SLA defined for that traffic's application class. A voice/video flow might require the lowest-latency path available at that instant, while a bulk file transfer might tolerate a cheaper, higher-latency link; the decision can change dynamically as conditions shift, not just at link failure.

Q Why does the destination website see HQ's public IP instead of anything related to the branch?

A Because NAT is performed at HQ's internet edge, which is the only point in this architecture where private addresses are translated to a public one. The branch's own WAN circuits carry only overlay-tunneled traffic to HQ — they were never involved in a NAT decision for this flow at all.

Q What happens if both underlay transports (MPLS and broadband) fail at the same branch simultaneously?

A With no remaining underlay path, the SD-WAN overlay tunnel itself goes down, and the branch loses connectivity to HQ entirely — including its only path to the internet, since there's no local breakout to fall back to. This single point of failure is a direct consequence of the centralized design and is usually mitigated with a genuinely diverse third transport (e.g. LTE/5G failover) rather than accepted as-is.

Q Where specifically would a web proxy or URL filter sit in this path, and why there?

A At the HQ edge, typically inline with or just behind the firewall, before traffic is NAT'd out to the internet — that's the one point every branch's internet-bound traffic is guaranteed to pass through, which is precisely why the centralized design routes everything there in the first place.

Q Does the branch firewall do anything meaningful here, or is it just a router in this scenario?

A It still enforces local LAN security policy (inter-VLAN rules, local segmentation) and terminates the SD-WAN overlay itself, but for this specific internet-bound flow its role is limited to routing the traffic into the tunnel — the deep inspection and internet-facing policy decisions all happen at HQ, not here.

04 Quick-Fire Glossary

Term	Meaning
SD-WAN	Software-Defined WAN — dynamically selects the best underlay transport per flow based on live SLA metrics
Underlay / Overlay	Underlay is the physical transport (MPLS, broadband); overlay is the encapsulated tunnel running across it
Centralized Internet Breakout	All branch internet traffic routed back to a central site before reaching the internet
Local Internet Breakout	A branch exits to the internet directly from its own site, without transiting HQ
CPE	Customer Premises Equipment — the branch-side device terminating a WAN circuit
MPLS	A private, provider-managed WAN transport often used as one underlay option in SD-WAN
SLA-Based Path Selection	Choosing the transport for a flow based on measured latency/loss/jitter against policy thresholds
Hairpinning	Traffic routed out to a central site and back, even when a more direct path might exist
Transparent Proxy	A proxy that intercepts traffic without requiring explicit client configuration
WAN Edge / Hub	The device terminating SD-WAN overlay tunnels at a branch (edge) or central site (hub)