This chapter is from the book
This chapter is from the book
This chapter is from the book
Security
The security settings on a vSwitch are probably one of the most misunderstood portions of a vSwitch configuration. There are three settings available for tuning: promiscuous mode, MAC address changes, and forged transmits, as shown in Figure 8.2.
)
Figure 8.2 Security settings on a vSwitch
Promiscuous Mode
If you think back to when we covered physical switching, you’ll probably recall that one major advantage to it is that we have the ability to switch traffic directly to a single destination MAC address. Unless the traffic is being flooded, broadcast, or specifically intended for a destination, devices on the network do not “see” the other traffic floating across the switch. This is great for most use cases as it provides for greater scalability and improved performance of the network, and is the default behavior on a standard vSwitch.
There are some situations where we really do want a VM to see traffic that is intended for another device. Imagine having some sort of network monitoring VM that needs to sniff traffic. This is where Promiscuous Mode comes in handy. By setting it to Accept, we are ordering the vSwitch to share traffic on each VLAN among other VMs on the same VLAN.
MAC Address Changes
The idea of MAC Address Changes tends to confuse a lot of people, so we’ll go deep into this one. First, what exactly is a MAC Address Change from a vSwitch perspective? To understand this, you must first know more about how the switch keeps track of MAC addresses for VMs.
To begin with, every VM has three different types of MAC addresses: the Initial, Effective, and Runtime MAC addresses:
- The Initial MAC address is configured on the virtual network adapter inside the VM. This is something you either let vSphere decide for you when the virtual NIC is created or manually set yourself by changing that vSphere-provided value. It is very similar to a physical NIC’s burned-in address (BIA).
- The Effective MAC address is configured within the VM by the guest operating system (OS). Typically, the guest OS just uses the Initial MAC address, much like your PC will by default use the BIA or your NIC.
- The Runtime MAC address is the actual live address that is being seen by the vSwitch port.
Figure 8.3 shows the Runtime MAC address of a VM in the vSphere Web Client.
)
Figure 8.3 The Runtime MAC address of a VM
So, now that you’re a MAC address expert, let’s go back in and discuss how the vSwitch polices MAC Address Changes.
When set to “Accept,” the vSwitch allows the Initial MAC address to differ from the Effective MAC address, meaning the guest OS has been allowed to change the MAC address for itself. Typically, we don’t want this to happen as a malicious user could try to impersonate another VM by using the same MAC address, but there are use cases, such as with Microsoft Network Load Balancing (NLB) where it makes sense.
When set to “Reject,” the vSwitch will disable the port if it sees that the guest OS is trying to change the Effective MAC address to something other than the Initial MAC address. The port will no longer receive traffic until you either change the security policy or make sure that the Effective MAC address is the same value as the Initial MAC address.
To sum it up, the MAC Address Changes policy is focused entirely on whether or not a VM (or even a VMkernel port) is allowed to change the MAC address it uses for receiving traffic. The next section covers sending traffic.
Forged Transmits
Very similar to the MAC Address Changes policy, the Forged Transmits policy is concerned with MAC Address Changes, but only as it concerns transmitting traffic.
If set to “Accept,” the VM can put in any MAC address it wishes into the “source address” field of a Layer 2 frame. The vSwitch port will just happily let those frames move along to their destination.
If the policy is set to “Reject,” the port will interrogate all the traffic that is generated by the VM. The policy will check to see if the source MAC address field has been tampered with. As long as the source MAC field is the same as the Effective MAC address, the frame is allowed by the port. However, if it finds a non-matching MAC address, the frame is dropped.
It’s very common to see issues with the Forged Transmit policy when doing nested virtualization. Nesting is the term used to describe running the ESXi hypervisor inside a VM, which then runs other nested VMs with their own unique MAC addresses. The many different MAC addresses will be seen by the port used by the nested hypervisor VM because the nested guest VMs are sending traffic. In this case, you would have to configure the policy for Forged Transmits to Accept.
Figure 8.4 illustrates this process.
)
Figure 8.4 Nested VMs cannot send traffic without accepting forged transmits