An intruder pivots between two VMs on one hypervisor: why does the perimeter firewall log nothing, and what does catching that flow cost?
answer
- the packet never leaves the box
- a virtual switch is still a switch
- borders see crossings, not conversations
- a missing record proves nothing
- to see it, filter inside the host
basics
~20 sTwo guests on one hypervisor exchange packets switched in software inside that host; nothing crosses a wire, so no border device receives them. Blocking that pivot means paying for a filter inside the host — an in-guest agent or a hypervisor firewall.
solid answer
~50 sA border firewall only sees packets that cross it. Two guests on one hypervisor are attached to the same virtual switch, so their packets are forwarded in software inside the host and never reach the physical uplink at all. Nothing is broken and no rule was bypassed — the flow simply never entered the border's path, which is why the pivot leaves no line in its log. To get a decision point on that flow you have to move the chokepoint inside the host: a firewall agent running in each guest, or a filter in the hypervisor's virtual switch. Both cost something. Agents cost a fleet to install, keep alive and keep in policy, and they run inside the guest an intruder may already own. A hypervisor filter costs you a layer you may not operate — on a provider's virtualisation cluster the virtual switch is theirs, not yours.
go deeper
Be ready to say plainly that a firewall only acts on traffic that passes through it, and that two guests on one hypervisor exchange packets inside the host without ever touching the physical network.
Explain the forwarding path: virtual NIC to virtual switch to virtual NIC, all in software, so uplink mirrors and fabric flow exporters see nothing. Then name the three places a filter could stand instead.
Show that you would treat the gap as a placement decision, not a tuning problem: agent in the guest, filter in the hypervisor, or separate the workloads onto paths you already control — and state the cost of each.
Own the consequence when none of the options is available: same-host lateral movement is unenforced, and that residual needs a named owner, a review date and a written decision rather than silence.
## The claim a border firewall actually makes A firewall enforces on traffic that passes through it. That is the whole of its authority. A perimeter device sitting between your estate and the outside world makes a strong statement about *crossings* — what came in, what went out — and no statement whatsoever about conversations that stayed on one side of it. Interviewers ask this question because the answer separates people who reason about packet paths from people who imagine a firewall as a general-purpose observer of "the network". ## Why the same-host flow is invisible On a virtualised host, each guest's virtual NIC is attached to a software switch running in the hypervisor. When guest A sends a frame to guest B and both are on that switch, the hypervisor forwards it from one virtual port to the other in memory. It is a normal Layer 2 forwarding decision; it is simply made in software, and the frame never reaches the physical network adapter. Consequences that follow directly: - The border firewall never receives the packet, so it cannot allow, deny, count or log it. - A port mirror (SPAN) or a TAP on the physical uplink captures nothing either, for the same reason — mirrors copy what traversed the mirrored port. - Flow export from the physical fabric shows no record. A missing flow record is not evidence that nothing happened; it is evidence that nothing traversed the exporter. - Putting the two guests in the same VLAN or subnet does not help. A VLAN is a broadcast domain, not a filter; two guests in one VLAN on one host reach each other with no policy in the path at all. ## Why an adversary cares This is exactly the segment an intruder wants. Having taken one guest — through an exposed service, a stolen credential, a vulnerable dependency — the next move is lateral: reach the database, the build host, the management VM sitting beside it. If those neighbours live on the same hypervisor, that move happens entirely inside a box you may not filter or even observe. The intrusion never generates a border deny, and the absence of a deny reads, to anyone not thinking about paths, like the absence of an intrusion. ## What it costs to get a decision point there There are only three places to stand, and each buys a different view at a different price. | Vantage | What it can decide on | What it costs | |---|---|---| | Border / segment firewall | Crossings between segments; nothing that stays inside one | Cheap to run, blind to same-host and intra-segment traffic | | Firewall agent in each guest | The guest's own traffic, after any tunnel is decapsulated, with the process and user behind it | A fleet to deploy, keep running and keep in policy; it lives in the same privilege domain an intruder who owns the guest already holds | | Filter in the hypervisor's virtual switch | Every flow in and out of every guest on that host, including guest-to-guest | You must operate the hypervisor — in shared tenancy the provider does, so it is their feature, their change process, their failure mode; and it sees flows, never the process or user behind them | A fourth option is architectural rather than technical: force the traffic off the host. Place the two workloads on different hosts, in different segments, or in different tenancies so that the flow *must* cross something you already control. That works, and it costs capacity planning, possibly latency and cross-host bandwidth, and rules that keep the two from being scheduled back onto the same hypervisor. ## How to answer this in an interview Say the mechanism first — the packet is switched inside the host and never reaches the border — then name the vantages and be explicit that each one has a structural blind spot rather than a configuration problem. The strongest version adds the honest residual: if you cannot filter inside the host and cannot separate the workloads, then same-host lateral movement is unenforced, and that sentence belongs in a risk register rather than in nobody's head.
- If the two guests sit on different hypervisors, does the perimeter firewall see the flow then?Usually not. The packet now crosses the fabric between hosts, but that path rarely runs through the perimeter device — and if the hosts use an overlay, what crosses the wire is a tunnelled packet whose outer headers name the two hypervisors, not the two guests. You may get host-to-host byte counts and still have no view of the guest conversation inside them.
- Would mirroring the host's physical uplink port capture this traffic?No. A mirror copies frames that traversed the mirrored port, and same-host frames never do. You would need a capture or filter point inside the virtual switch itself, which on a provider's cluster is a feature you have to ask them for rather than something you can enable.
- The two guests are in the same VLAN. Does that change anything?It makes it worse. A VLAN defines who can reach whom at Layer 2; it applies no policy between members. Two guests in one VLAN on one hypervisor have an unfiltered path to each other by design, and nothing outside the host is in a position to intervene.
A gate on the driveway records everyone entering and leaving the house. It has nothing to say about someone moving from the kitchen to the study.
saying these in an interview costs you the question
- Assuming every packet in the estate passes the perimeter firewall
- Believing a physical port mirror or TAP captures same-host traffic
- Treating a shared VLAN or subnet as a filter between guests
- Concluding the firewall is misconfigured rather than out of the path
- Reading an empty flow record set as proof no traffic occurred