How does one isolate (air-gap) a VMware VM yet allow it to print, using a Meraki stack?
Ideally in a series of easy-to-follow steps vs. "go RTFM".
(Trying to translate documentation - e.g. Switch ACL Operation - and related threads - e.g. Isolate vlan from all other vlans! - into actual configuration steps.)
The stack is MX100 with MS switches, a few ESXi 7 servers, vCenter 7.
So far the plan is:
Do the above steps do what's needed, to fully isolate the VM with the exception of talking to a printer? Did I miss anything obvious (or not so obvious)?
Thank you!
Create a security rule denying any and above of this rule create rules for what you want to allow.
@alemabrahao wrote:Create a security rule denying any and above of this rule create rules for what you want to allow.
Thank you. Which question are you answering with this?
This is the main one:
How does one isolate (air-gap) a VMware VM yet allow it to print, using a Meraki stack?
Ideally in a series of easy-to-follow steps vs. "go RTFM".
(Highlighting mine.)
This is the follow-up one:
Do the above steps do what's needed, to fully isolate the VM with the exception of talking to a printer? Did I miss anything obvious (or not so obvious)?
(It's two questions - yet both still boiling down to, "did I miss anything?")
Thanks again - and apologies for needing precision and well defined steps as opposed to "being pointed in the right direction".
Don't you know how to create a L3 security rule?
https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings#Outbound_rules
@alemabrahao wrote:Don't you know how to create a L3 security rule?
https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings#Outbound_rules
Ouch.
Hi @alemabrahao, friendly reminder of our community guidelines to be respectful of posters by keeping a positive tone and offering constructive comments to help others. We all have different levels of experience and expertise, and many of the members here are newer to Meraki.
Sorry, I'm not a native speaker.
Does the host have any free network ports?
If so connect the VM to a VMware switch that maps to that port. On the switches create two access ports on the new VLAN, don't create an interface for it. Connect the host NIC to one port and the printer to the other.
No risk of traffic getting outside of that.
Right - or USB passthrough was my second thought. No idea what support for that looks like on Server 2000 though...
My other thought is do users need to access this server? If so, OP's proposed solution will not work, and the server will only be accessible through VMRC...
Right - or USB passthrough was my second thought. No idea what support for that looks like on Server 2000 though...
Don't want to tie the VM in to a single ESXi - but can try it if it comes to it. (Good thought.)
My other thought is do users need to access this server? If so, OP's proposed solution will not work, and the server will only be accessible through VMRC...
What's wrong with giving select AD users access to specific VM's VMRC? (Seems to be working well although RDP is preferred of course.)
@cmr wrote:Does the host have any free network ports?
If so connect the VM to a VMware switch that maps to that port. On the switches create two access ports on the new VLAN, don't create an interface for it. Connect the host NIC to one port and the printer to the other.
No risk of traffic getting outside of that.
Plenty - something like 8 (Dell R740, 4 10Gb SFPs, 4 1Gb RJ45 - I didn't buy them 🙂 but hey it's nice to have spares) - but don't want to tie the VM to a specific ESXi in a cluster of 4 and occasionally 5 or 6 when we're testing new ones. (Good thought though - I'll come back to it if the original route ends up in smoke or is not secure enough.)
("On a vSwitch, will travel" is my preference vs. mapping a VM to a physical NIC, which ties it to a specific ESXi.)
You can create the network on each host and just connect one of those spare ports from each to the switch, or if you have distributed switches you could use one of those to go across hosts...
If the printer is dedicated to this VM, there's really no need to create a VLAN interface on the MX.
You can simply setup a new VLAN on the vSwitch, configure that VLAN on the trunk ports on the switches through the network to the switch where the printer is connected and configure the printer port as an access port in that VLAN.
Don't set any default gateway on either the printer or the computer and you're good to go. Those devices will not be able to communicate with anything outside of that VLAN.
The only 'risk' of this is VLAN bleeding if someone misconfigures the network in the future. To minimize that, you can add switch ACL's to allow on the specific communication (IP's and ports) on that VLAN and deny all other communication from those hosts.
Thank you - I am relatively new to Meraki (about a year) and only dealt with networking and VLANs occasionally in the past - yet a sort of a general impression is that for transparency and visibility, it's better to keep the configs in one place - on the MX (if it doesn't add too much overhead).
The other thoughts are:
Thanks again - I wasn't aware of this possibility of avoiding any configuration changes on the MX.
Simple answer to both thoughts is I wouldn't.
My recommendation is to use Brash/CMR's solution as it will be the simplest to implement. I would advise engaging VMWare support if you are unfamiliar with the VMWare networking management portion.
And of course, while I completely understand (been there), I would be remiss if I didn't recommend engaging with your stakeholders to move away from utilizing Windows Server 2000 in production for reasons I'm sure you are well aware of. 😁
If we can make it secure enough, allow RDP-ing into that VM (with only RDP traffic allowed)
- I'm pretty sure CVE-2019-0708 would work on Windows Server 2000 and an EOL patch was not released, allowing RCE on that box where a threat actor could easily pull the AD creds of users and further exploit your environment. I would not recommend this.
Thanks for the comment, understood. This doesn't quite apply to my situation and goals.
In terms of your kind suggestion to finally retire the damn thing: sounds like you're fully behind the idea of reducing technical debt and minimizing high effort useless tasks. Me too! 😎
Thanks again!
Could someone please say something about my proposed plan in the OP so I could accept it as a solution? Something like:
Thank you!