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! ... View more

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! ... View more

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

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

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

Thank you.   Is it safe to assume that the following is then the best (so far) answer to the original question?   I.e. the answer to the OP question ("what is the best practice...") seems to be a "no, Meraki does not appear to offer a good, simple way to connect a non-Meraki VPN peer to auto-VPN sites, however the simplest way to do this is using a non-Meraki S2S VPN gateway - especially if the number of auto-VPN sites is large enough."   ... View more

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

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

Sorry that I am not entirely following.   You configure the non-meraki VPN once, and any branch that is configured in the Availability option, will build an individual IPsec-tunnel. With that you have a very small config even for a large amount of branches. Doesn't the idea of building individual tunnels to each branch contradict the idea of a "very small config"? I.e. could a set of 20+ individual VPN tunnels be called a "very small config" even if they're configured similarly?   (We are essentially asking the MSP to build and maintain a fairly large number of individual tunnels on their side - all because we on our side can't route single VPN tunnel traffic to/from our branches? That doesn't quite make sense to me.)   Your non-meraki VPN-Hub still needs to be configured to accept the session from all branches. What is a "non-Meraki VPN-hub"? I've poked around searching for it, and not seeing much. Native Azure VPN gateway SKUs all seem to be site-to-site, i.e. there isn't a way to configure a single one to connect to multiple endpoints in a hub-like fashion., and you pay separately for each one you set up. Similarly, most other S2S VPN gateways seem to be set up in a similar fashion: separately configured individual tunnels vs. anything resembling a "hub".   P.S. It seems (to this VPN/networking rookie) that setting up one VPN tunnel from our HQ to the MSP using non-Meraki tech e.g. a standalone Aruba S2S appliance is all there should be to it: Meraki will see it as a direct-attached subnet, and thus allow to route traffic to/from it, including to/from Auto-VPN sites the MSP only has to maintain one tunnel we only have to maintain that one appliance and the associated tunnel with its routing and ACLs   (At least that's what I am seeing suggested on the interwebs when searching for "connect a non-Meraki VPN peer to Auto-VPN sites".)   P.P.S. Granted, the above (using a non-Meraki VPN appliance configured outside of Meraki) falls outside of the OP question scope:   What is the best practice to connect a non-Meraki VPN peer (e.g. our Azure or AWS services) to our auto-VPN sites (networks)? ... but then so does the vMX.   I.e. the answer to the OP question ("what is the best practice...") seems to be a "no, Meraki does not appear to offer a good, simple way to connect a non-Meraki VPN peer to auto-VPN sites, however the simplest way to do this is using a non-Meraki S2S VPN gateway - especially if the number of auto-VPN sites is large enough."   Thanks! ... View more

vMX is not always an option with MSPs. In our case - not (yet) an option.   The goal is to make it work between a non-Meraki peer and auto-vpn peers. Performance requirements are negligible. ... View more

I hear you on simplicity, security and reliability.   One reason to use a switch like that is because we have it... 🙂   The other - to counter ISP's assertion of "you have a lot of errors on your side" and get port error stats from a switch that can collect and report them.   (Generally, get a little better visibility into WAN traffic.)   Yet another: ease of configuration and testing. Configure two ports for one ISP circuit, another two - for the 2nd one, another - for a cellular uplink, isolate them all, see them all... ... View more

Thank you, that deck helped tremendously. I don't have enough networking background to translate everyone's suggestions into actual configuration settings, and that deck more or less did it. ... View more

A breakout switch between the MX and the ISP should be working as layer 2 only. Please make sure there is not L3 interface configured. Thank you.   Not sure what this means in terms of where to go in the switch configuration and what to change, to ensure the switch stays in L2 mode. If it means "there is not L3 interface configured" - then what does that mean in terms of Interface (switch port?) configuration?   The recommended configuration is to have a copule of ports in access mode. Assuming (for now) the switch will only have two connections - to the ISP circuit, and to the MX100, does this mean both of those should be in access mode?   If you are using other ports on the switch, is recommended if are trunk interfaces to prune the VLAN. Ex. use ports 1 and 2 for ISP modem and MX100, both in access VLAN 999. In any other trunk port in the switch do not allow VLAN 999. I hope it makes sense. The switch is dedicated to just being the breakout switch, i.e. no plans to use it for other tasks. This means ports other than the primary ones (one - to the ISP circuit, the other - to MX100's WAN port) can be used for two purposes only: management - connect to MX100's LAN port to ensure the MS220 switch remains manageable even if the ISP circuit drops testing and diagnosis - if there are issues with the ISP circuit, to ensure there can be a direct connection to it that bypasses MX100, yet that does not require disconnecting the MX100   With all that in mind - does something like this make sense, and does it look secure enough?   Scenario 2: breakout switch MS220-8, 3 connections: Port 1: to ISP circuit Port 2: to MX100 WAN port Port 3: to MX100 LAN port (for management)   Configuration: MS220-8 Port 1: to ISP circuit 1 Type: Access VLAN: 991 (not present anywhere else on the network) MS220-8 Port 2: to MX100 WAN 1 port Type: Access VLAN: 991 MS220-8 Port 3: to MX100 LAN port (for management) Type: Trunk Native VLAN: ? Allowed VLANs: none? MX100 WAN 1: VLAN ID: 991? IP config: (specific to the ISP circuit) MX100 LAN port (e.g. 5): no configuration options available Switch management: via MX100 LAN port   Thanks again! ... View more

The cable modem is using a plain routed address block, like a /29?   If it is passing through PPPoE then you may have issues. Two ISP circuits in play: a cable modem (Spectrum Business) + 4-port router with DHCP, with static IPs that come with the service a so called "DIA" circuit from Frontier with a RAD ETX-203ax "demarcation" device - with a /29 address block.   Either one is working OK when connected directly to the MX100. I'd like to put a "breakout" switch(es) between the circuits and the MX, and configure everything securely.   Got a good response from Meraki support:   The first thing you will need to take care of is the switch configuration. The switch can get its management from the LAN of the MX, unless you want it to always be reachable even if the MX is down, in which case you will need to assign it a public IP from the same pool the MX is getting. The ports that are assigned to the ISP circuit will be configured as access ports on a VLAn that will not be used on the LAN. Depending if you assign a public IP to the switch or not, the management of the switch will be statically configured on that VLAN, otherwise it will get the management from your vlan of choice from the MX. No configuration changes will be needed on the MX and you will need to connect cabling accordingly to the selected ports for the ISP circuit on the switch.   ... although still have trouble translating it to actual configuration steps.   So far my "translation" into configuration steps or options is as follows:   Scenario 1: breakout switch MS220-8, only two connections: ISP circuit, MX100 MS220-8 Port 1: to ISP circuit 1 Type: Access VLAN: 991 (not present anywhere else on the network) MS220-8 Port 2: to MX100 WAN 1 port Type: Trunk Native VLAN: not configured (empty) Allowed VLANs: all MX100 WAN 1: VLAN ID: not configured (empty) IP config: (doesn't matter - whatever works for that specific ISP circuit, including DHCP) Switch management: via static IP configured for the ISP circuit   Does the above sound right, and does it comply with best practices in terms of security and manageability? Should port 2 on the switch be configured as "Trunk" and no VLAN configuration?     Scenario 2: breakout switch MS220-8, 3 connections: ISP circuit, MX100 WAN port, MX100 LAN port (for management) MS220-8 Port 1: to ISP circuit 1 Type: Access VLAN: 991 (not present anywhere else on the network) MS220-8 Port 2: to MX100 WAN 1 port Type: Trunk Native VLAN: not configured (empty) Allowed VLANs: all MS220-8 Port 3: to MX100 LAN port (for management) Type: Trunk Native VLAN: not configured (empty) Allowed VLANs: all MX100 WAN 1: VLAN ID: not configured (empty) IP config: specific to the ISP circuit MX100 LAN port (e.g. 5): no configuration options available Switch management: via MX100 LAN port   Ditto, does this configuration look OK? Does the LAN port connection from MX100 to switch (and thus, directly to the ISP circuit) make the configuration vulnerable in any way?   Lastly, is it possible to connect two different ISP circuits to the switch, and then connect each to a respective WAN port on MX100? (I am assuming the two connections would need to be isolated via VLANs?)   ... View more

Thanks - that makes sense!   (Except perhaps that the tunnel should still work when VPN is active-active over two uplinks? In other words why does it stop working if VPN is active-active on two uplinks, the peer is to set up to an IP on, say WAN 2, and the primary uplink is switched to WAN 1?)   (Leaving the main question unsolved as I'd still like to get answer to that, too - how to determine the timestamp of the last successful connection over a non-Meraki VPN peer.) ... View more

We just tried switching the primary uplink back to the secondary WAN (WAN 2) - and the peer came up.   (We changed the primary uplink to WAN 1 from WAN 2 last week trying to stabilize our site-to-site VPN which was frequently going down. I didn't help - but didn't seem to make things worse other than today's discovery of the VPN peer being down.)   Guess the peer is somehow hard-wired to a specific uplink being the primary one? (Traffic is load balanced between uplinks, VPN "active-active" status doesn't seem to matter, nor does "immediate" vs. "graceful" failover.   Is there a way to configure it to work regardless of which uplink is primary?   P.S. The original question still stands though, how to track down the time a VPN peer went down or was last successfully used. ... View more

Done before I even posted here. As I mentioned in my original post, the goal of this thread was to rule out me doing something wrong, or known Meraki (mis)behavior. Looks like it's neither - which is strange given seemingly a lot of orgs using Meraki, VLAN GPs, and allow-listing being a common tool to troubleshoot issues. Thanks for the help with this! ... View more

Yes, thank you, saw it. In other words, the behavior I am describing (if I am describing it accurately) - is unexpected, runs counter to Meraki docs, and does not represent a known bug? ... View more

Sorry that I am so slow. You're saying that explicitly allow-listing a device in a VLAN with a GP applied to it will have no effect with respect to active VLAN Group Policy rules. Does that sound right? (That - despite "Policy - Show Details" showing no Layer 3, 7 or traffic shaping rules applied to the device at all...) (It doesn't sound right to me - it's not what Meraki docs say - but OK. Let's assume for a second you're right.) What I am saying is this: Allow-list a device. Observe the traffic still being blocked. Add a random "deny" rule to the Group Policy. (Adding such a rule should not allow any traffic from anywhere to anywhere, least of all from/to non-existent IP addresses... correct?) Observe the previously blocked traffic now flowing. How does this make sense? ... View more

I am not sure how to read it, or what it means for my case. If allow-listing a device is not supposed to work at all due to "network default" policies, then why does making an unrelated change to a group policy all of a sudden allow-lists the device anyway? (See "how to reproduce" step 4 above.) ... View more