A freshly configured appliance answers HTTPS from a laptop on the same server-room subnet but is unreachable from the operations VLAN one router away. Address, mask, and DNS are verified correct. Which single missing setting best explains this pattern?
Select an answer to reveal the explanation.
Short Explanation
A box with an IP and mask but no gateway is like a house with a driveway that meets no road — the neighbors can all visit, but nobody from across town can find you. Same-subnet works, off-subnet dies; that's the gateway talking. Add the default route, then prove it by testing from the far VLAN.
Full Explanation
A default gateway is the setting that converts link-local reachability into routed reachability. Without it the appliance still answers on its own subnet — ARP works, an attached laptop completes HTTPS — but it holds no route onward, so every off-subnet client fails, which is precisely the pattern described: local success, universal remote failure. It is the classic missed line in rack-side commissioning because the appliance 'obviously works' when tested locally. Widening a listening port fails by concept: the web service listens on its configured port for all reachable sources, and there is no multi-subnet mode to enable. Requiring reverse DNS per client subnet before accepting sessions fails at the protocol layer — TLS session establishment does not gate on PTR lookups for client subnets, and reverse records serve log readability and identity hygiene rather than admission control. The tagged-VLAN condition is likewise invented: VLAN tagging is a layer-2 membership decision and cannot be the cause when the symptom is a layer-3 absence. Exam caveat: when off-subnet reachability fails, verify the gateway responds and the return path exists before changing anything on the appliance. Operational check: configure the gateway, confirm the appliance can reach it, then load the GUI from a host on the operations VLAN to close the loop on the real admin path.