how to isolate a VM (Meraki + VMware)

[cabricharme]

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 task is to "air-gap" a VMware (ESXi / vCenter) VM yet allow it to print to a physical printer on a network. The printer can be dedicated to the task, i.e. it does not have to be shared with any other devices for printing.
• The VM is a P2V'd Windows Server 2000 machine (presumably vulnerable, presumably even running malware) running an old LoB application that occasionally needs to be accessed and records from it - printed out.

The stack is MX100 with MS switches, a few ESXi 7 servers, vCenter 7.

So far the plan is:

• VMware:
  • Create a vSwitch (vCenter / ESXi), set it to a unique VLAN that's not used elsewhere. E.g. 2001.
    • do not (yet) connect the VM's NIC to it: the VLAN is not fully isolated yet - not until the MX is configured to stop almost all of the traffic flow to/from it
• Meraki MX:
  • Connect a network printer to a Meraki switch port, "access" type, VLAN 2001, port isolation: disabled (no point given port isolation won't stop traffic flow within the vSwitch, or between VLANs?)
  • Create a "deny everything" Group Policy, name it something like "VLAN 2001 printing only"
  • Create a new VLAN on the MX ("Security & SD-WAN" -> "Addressing & VLANs" -> "Routing" -> "Add VLAN",
    • give it a non-routable subnet with the smallest range possible (e.g. "VLAN interface IP" of 10.201.0.128, Subnet 10.201.0.128/30, then give the VM and the printer .129 and .130 IPs)
    • assign the above group policy to it
• Now connect the VM's NIC to the vSwitch configured above, configure IPs on the printer and the VM, try pinging the printer's IP from VM, confirm no ICMP response
  • create an "allow" rule in the GP configured above allowing ICMP traffic from the VM to the printer (and back?)
  • try pinging again, confirm it's working
  • modify the "allow" rule configured above to include TCP/UDP traffic
  • testing printing

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!

[alemabrahao]

Create a security rule denying any and above of this rule create rules for what you want to allow.

[cabricharme]

---

@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".

[alemabrahao]

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

[cabricharme]

---

@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.

[AmyReyes]

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. 

[alemabrahao]

Sorry, I'm not a native speaker.

[cmr]

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.

[thaack]

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...

[cabricharme]

---

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.)

[cabricharme]

---

@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.)

[cmr]

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...

[Brash]

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.

[cabricharme]

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:

• if we can make it secure enough, can we connect that VM to a shared printer  on a different VLAN instead of dedicating one to it, given it's only being used once in a blue moon?
  • (I know, it's not what I said in the OP - but I can change my mind, can't I? 😊 If we can make it secure enough.)
• if we can make it secure enough, allow RDP-ing into that VM (with only RDP traffic allowed)

Thanks again - I wasn't aware of this possibility of avoiding any configuration changes on the MX.

[thaack]

Simple answer to both thoughts is I wouldn't.

• if we can make it secure enough, can we connect that VM to a shared printer  on a different VLAN instead of dedicating one to it, given it's only being used once in a blue moon?
  • Too complex but could reasonably be configured with strict ACL's but that's a little difficult and still potentially leaves security risks if you are unsure of what you're doing.
• 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.

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. 😁

[cabricharme]

---

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.

• The RDP access will only be open to specific IPs. Not to the entire network, VLANs or subnets. Just IPs.
• The server isn't domain-joined, there's nothing to pull.
• It'll be powered down most of the time, awaken only on request.
• It's read-only in a sense there's no new data written to it. If someone malicious manages to get in, and it goes up in smoke, no biggie. Restore a month-old version from backup or a snapshot.
• The security part isn't to protect that server, it's to protect the network in case the server is already loaded with malware. Far as I can tell, the precautions I am taking with everyone's help here would keep this setup reasonably secure.

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!

[cabricharme]

Could someone please say something about my proposed plan in the OP so I could accept it as a solution? Something like:

• The plan looks good with some concerns or side effects (list them please if you can). (I think @alemabrahao meant to say this with this reply - but can't be sure as he didn't explicitly say, "looks OK, except your 200 bullet points can be boiled down do just two.)
• The plan is not secure enough to my 👀 and here is why (list concerns)
• something else

Thank you!