Accepted Solutions
I consolidated all of your most recent questions into one response. See below.
1) So.. Just to make sure.. Maybe a strange setup, but I guess it
proves my question. Two VMs with IP on the same net, say
192.168.0.19/24 and 192.168.0.20/24. No vlans anywhere. Each connected
to different vShielded vSwitch, but pNICs on the vSwitches connect to
the same pSwitch to make them reach eachother. Now, would a vShield
rule of DENY ALL 192.168.0.19/32 192.168.0.20/32 stop traffic between
them?
While this is a bit of a strange setup, it would block the traffic because the traffic would be passing through the vShield.
-
2) More of a geek question maybe, but still.. How does the vShield VM
really work? How can it pick up all traffic from all portgroups like
that without actually being a def.gw for the traffic? Is there some
cool vSwitch API that it uses?
It the vShield appliance connects to a promiscuous mode port group in order to see all the traffic and be able to bridge that traffic between the internal vSwitch and the external vSwitch.
-
3) Also, would it be a good practice to locate the vsmgmt portgroup and
the vShield mgmtinterface in the vSwitch used for VMKernel (ESXi)
administration? That switch is supposed to be well protected anyway, so
I guess it makes more sense than to locate those portgroups on an
"external" vSwitch? I realise you can do either way, but would this not
be a good idea given that vMotion traffic happens on yet another
dedicated switch and pNICs?
The only problem with that is that you may inadvertantly connect another VM to that portgroup that you shouldnt. At which point that VM would have direct access to the management network. It may be better to set it up in a seperate management zone and then open the proper ports so the manager can communicate with the vCenter server. Definitly you will want to use the new roles and permissions in vSphere to limit access the vsmgmt port group to only authorized individuals. By doing that you can mitigate the issue of the port group being on the same vswitch as the vmkernel portgroup, so in that case it may be OK. 
The real key is to protect that management network from regular VM traffic. However you accomplish really depends on your situation.
-
4) Sorry to spam you, but do you know what would happen if you were to
connect a pNIC to the vShield vSwitch that is created? Will traffic
rather go out that way or still via the vShield?
If you connected a pNIC to it and that pNIC were connected to a physical switch then yes the traffic would just go directly that way. Actually you would likely end up creating a loop in the network because the vShield will still be repeating that traffic out to the physical network as well. I'd have to test this to be sure, but I am fairly certain this would be a bad thing to do.
-
I consolidated all of your most recent questions into one response. See below.
1) So.. Just to make sure.. Maybe a strange setup, but I guess it
proves my question. Two VMs with IP on the same net, say
192.168.0.19/24 and 192.168.0.20/24. No vlans anywhere. Each connected
to different vShielded vSwitch, but pNICs on the vSwitches connect to
the same pSwitch to make them reach eachother. Now, would a vShield
rule of DENY ALL 192.168.0.19/32 192.168.0.20/32 stop traffic between
them?
While this is a bit of a strange setup, it would block the traffic because the traffic would be passing through the vShield.
-
2) More of a geek question maybe, but still.. How does the vShield VM
really work? How can it pick up all traffic from all portgroups like
that without actually being a def.gw for the traffic? Is there some
cool vSwitch API that it uses?
It the vShield appliance connects to a promiscuous mode port group in order to see all the traffic and be able to bridge that traffic between the internal vSwitch and the external vSwitch.
-
3) Also, would it be a good practice to locate the vsmgmt portgroup and
the vShield mgmtinterface in the vSwitch used for VMKernel (ESXi)
administration? That switch is supposed to be well protected anyway, so
I guess it makes more sense than to locate those portgroups on an
"external" vSwitch? I realise you can do either way, but would this not
be a good idea given that vMotion traffic happens on yet another
dedicated switch and pNICs?
The only problem with that is that you may inadvertantly connect another VM to that portgroup that you shouldnt. At which point that VM would have direct access to the management network. It may be better to set it up in a seperate management zone and then open the proper ports so the manager can communicate with the vCenter server. Definitly you will want to use the new roles and permissions in vSphere to limit access the vsmgmt port group to only authorized individuals. By doing that you can mitigate the issue of the port group being on the same vswitch as the vmkernel portgroup, so in that case it may be OK. The real key is to protect that management network from regular VM traffic. However you accomplish really depends on your situation.
-
4) Sorry to spam you, but do you know what would happen if you were to
connect a pNIC to the vShield vSwitch that is created? Will traffic
rather go out that way or still via the vShield?
If you connected a pNIC to it and that pNIC were connected to a physical switch then yes the traffic would just go directly that way. Actually you would likely end up creating a loop in the network because the vShield will still be repeating that traffic out to the physical network as well. I'd have to test this to be sure, but I am fairly certain this would be a bad thing to do.
-
Excellent and fast answers! All points awarded. Btw, I just tried to connect a pNic to the vShield switch. It bypasses the vshield and I reached out to the internet when I wasn't supposed to. Now we know that for a fact.. 
/Henrik
-- While this is a bit of a strange setup, it would block the traffic because the traffic would be passing through the vShield.
So.. Sorry to bump this to the top again, but I want to be 1000% sure. In the first answer, you say that routng is required for filter to stop the traffic. But in my example, no routing is going on? Still it gets stopped? Slightly confused again..
/Henrik
Perfect answer! Thanks. I just wanted to get clear on the requirement of routing. I just talked to one of out network-guys at work, and he mentioned that it was probable that routing was needed in order for it to be able to filter stuff on higher layers (3/4), but I am glad to hear that vShield is smart enough to be able to handle filtering even though traffic is merely flowing straight through it. According to him, this is usually a requirement in the physical world of switches, and yet again I am happy to learn that virtualization is better than physical stuff.
Many thanks for your replies, I now think I have a clear understanding of the features of vShield.
My next thought here is how long we will have to install this separately and treat it as a separate VM at all? Its my guess, but I would not be very surprised if all this functionality moves straight into the vSwitch itself and is managed via the VIC as any other function.. VI 5.0? Maybe called vSquare?
/Henrik
Each time I think I got it all, I find something new.
1) If I check the box "log" on a rule, this means that this info is sent to the specified syslog server? There is no local logging going on that I can find?
2) When defining a L4 VM Wall rule, you specify Destination Application (like HTTP). Does this mean that it actually checks to see that is really IS an HTTP stream, and not, say, a Telnet session using port 80?
/Henrik