vSwitch security policy REJECT / REJECT / REJECT

[kwg66]

Couple questions around these recommended settings:

1)  Are they needed on portgroups that don't run any VMs?   like an ISCI portgroup?

2)  ARe they needed on isolated portgroups that run VMs but that don't touch the outside world?

3)  ARe they recommended for a dedicated portgroup that is used for appliances like vShield?  and on that note, would the settings break vShield functionality?

Thanks in advance for your replies. 

[kermic · Accepted solution]

If you ask whether reject / reject / reject is needed then

1) Needed - No

2) Needed - No

3) Recommended - probably yes, as far as I know , however might depend on solution requirements.

It is the default setting in dvSwitches however.

Mac Changes and Forged Transmits deal with changed / spoofed mac addresses. So if you don't expect any administrator or piece of software from within Guest changing either the effective MAC or mocking around with "Source MAC" field in outgoing frames, these can safely be set to "Reject". The one case that comes to my mind where you _need_ to set these 2 to "Accept" would be 2 or more of your VMs participating in a MS NLB cluster, where the virtual cluster MAC jumps around the nodes.

Nested hypervisor might be another case however that should not really be a production topic.

As for the promiscuous mode - it's set to reject by default in both - standard and disti switches. If you set that one to "accept", that effectively turns that particular portgroup into a hub - anything that is connected to that portgroup will be able to hear all traffic within the switch (on the same VLAN). This normally is used as exception only, for things like traffic analysis, monitoring, IDS / IPS.

Hope this helps.

[kwg66]

you confirmed what I was thinking so this is good enough for me to move forward.  Thanks for the quick reply.