Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am currently examining Hypervisor firewalls for my graduate thesis, but I unfortunately don't have a lot of experience with IaaS environments. How are IaaS Virtual Machines network isolated from each other (if at all)?

Do IaaS Providers solely rely upon VLAN's for network isolation? Are IaaS VM's bridged onto a network to obtain an IP? Can most IaaS VM's ping other VM's that are present on the same Hypervisor?

Thank You

share|improve this question
up vote 3 down vote accepted

IaaS servers use traditional hypervisors you can install on any computer, typically Xen or KVM (or Hyper-V if you hate money). These typically connect to the network using one of:

  • an internal virtual interface (TUN/TAP), which you can then bridge or firewall or do whatever you want with at the containing host level
  • programatic in-process NAT (unlikely in an enterprise setting)
  • network card sharing (managed by the hypervisor)
  • dedicated network card

The network model is up to the implementor. The TUN/TAP interface provides the greatest flexibility, since the VM's network interface shows up as an otherwise unconnected interface in the host OS. When and if to send packets to the virtual interface is determined entirely by the host server's firewall and routing tables. It can be complicated to set up and get right, though.

The network card sharing system is probably the simplest, and therefore the most likely. To all the world, it looks like each VM has an ethernet interface all connected to the same switch. But in reality there's only one interface listening in promiscuous mode, with the host OS determining whether or not to send packets to a given VM. The security model there is the same as you'd get with multiple servers on a single broadcast network.

Finally, dedicating an interface to each VM is the most expensive, but also the easiest to understand intuitively from a security perspective. Each VM has a network adapter, you plug the correct cable into the appropriate adapter, and there you go. This is highly unlikely to find at scale, though, since changes require manual intervention.

As far as what security models are in play; again that's up to the implementor. Simpler places will typically provide NO network security (your server is on the Internet, deal with it), but if they do provide private networks, then their mechanism for doing so is their own secret. There are only so many things you can do, though, so you probably can guess.

share|improve this answer
Thank you for that explanation. However, are TUN/TAP interfaces the same as "network card sharing"? Is that effectively the same as bridging each network card interface? – Phanto Jun 9 '13 at 14:02
As an FYI, my research is centered around Linux KVM and iptables. I was never able to get specific TUN/TAP interfaces working, but I was able to get KVM VM's to use specific virtual interfaces of my choosing that KVM automatically creates upon the start of the VM. – Phanto Jun 9 '13 at 14:13
@Phanto if you're using libvirt, it has its own ideas about how to configure networks and will tend to override any changes you make. – tylerl Jun 9 '13 at 20:21
@Phanto The difference between TUN/TAP and card sharing is that if you create a TUN or TAP adapter, then no data passes to/from the VM unless explicitly forwarded by the host kernel using routing, bridging, or NAT. The host has to act like a gateway or router for the guests. – tylerl Jun 9 '13 at 20:26
@ tylerl, +1 and thank you for explaining that. I was never able to figure out why making TUN/TAP interfaces never worked out for me. – Phanto Jun 9 '13 at 21:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.