|
Scenario
|
Enabled
|
Details
|
|
Lab-To-Lab communication
|
Yes
|
This is available and documented. If students need two virtual machines we also recommend using Nested Virtualization.
|
|
Opening additional ports to the students VMs
|
No
|
This currently doesn’t work, even with advanced networking. One possible solution is to use PowerShell or Azure SDK to manually add the NAT rules for every VM in the lab (every private IP address) but it’s not a good solution because Load Balancers have a limit on allowed rules, it takes a lot of scripting to complete and the experience isn’t good for students (students won’t know what LB port goes to their VM).
|
|
Enable distant license server (on-prem, cross region, etc)
|
Yes
|
This works as expected, only need a User Defined Route to point to the license server. The only issue is sometimes specific software requires hitting the license server by name (and not by IP). To enable this, a customer-provided DNS server is needed or add to ‘hosts’ file on the template for the IP/Name lookup.
Please see Azure Networking best practices for Hub-Spoke model if you have multiple services accessing the license servers, using them from multiple regions, or if the licensing servers are included in other infrastructure.
NOTE: When using resources on-prem, don’t forget to add in a user defined route so the Lab virtual machines can reach the server.
|
|
Access to on-prem resources (like a license server)
|
Yes
|
Customer can do this by:
1. Via Express Route or Site-to-Site VPN (bridge the networks)
2. Add a public IP to their on-prem server with some firewall to only allow incoming connections from labs
NOTE: When using resources on-prem, don’t forget to add in a user defined route so the Lab virtual machines can reach the server.
|
|
Enable azure networking best-practices (hub-spoke model)
|
Yes
|
This works as expected - there is no extra ‘magic’ on networking side with Lab Services (with Lab Plans and advanced networking). There are a few things that don’t work – like adding a “Default Route” on a Route Table (breaks connectivity to the lab), changing the FQDN on the public IP.
|
|
Enable accessing student VMs by Private IP (private-only labs)
|
Not Recommended
|
This scenario is functional, but it’s difficult for students. In the Labs portal, the student doesn’t have a way to identify the private IP of their VM. In addition, the student VM’s connect button always points to public endpoint. The only way to make it work is if the teacher provided the students with the private Ips of their VMs (keeping in mind that the IP can change, if the VM is reset for example)
NOTE: If attempting this scenario, do not delete the public IP & load balancer associated with the lab. If those resources are deleted, the Lab will fail to scale or publish after that.
|
|
Protect license server (or on-prem resources) with a firewall
|
Yes
|
Firewall between student VMs and a specific resource works fine
|
|
Put student VMs behind a firewall (for content filtering, security, etc)
|
No
|
The typical firewall setup does not work with Lab Services unless the university is connecting to student VMs by private IP (see above).
The specific issue is that part of the firewall setup is adding a ‘default route’ on the route table for the subnet. When this is added, we introduce an asymmetric routing problem which breaks the RDP/SSH connections to the lab.
|
|
Use 3rd party over-the-shoulder monitoring software
|
Yes
|
This works with labs when using Advanced Networking.
|
|
Give labs a consistent domain name (lab1.labs.myuniversity.edu.au)
|
No
|
This doesn’t work. because when the lab is created, we get the FQDN from the public IP of the lab and save that for the lab VMs. This means that changes to the Public IP are not propagated to the ‘connect’ button for the template virtual machines or the student virtual machines.
|
|
Enable forced-tunneling for Labs (all communication to student VMs on secure channels, no internet traffic) - also called “Fully Isolated Labs”
|
No
|
This doesn’t work out of the box. As soon as a route table is associated with the subnet containing a default route, users will lose connectivity to the lab (see the firewall scenario above). The customer can follow the steps above for Accessing Student VMs by Private IP (that part works), but customer can’t delete the public IP & load balancer since that will break the lab (can’t scale/publish after that).
|
|
Enable Content Filtering
|
Depends
|
Content Filtering scenarios that work:
· Software on VM: Filtering works with 3rd party solutions
1. Students ideally should run as non-admin so they can’t uninstall or disable the software
2. Ensure that outbound calls to Azure are not blocked
· DNS-based content filtering: Filtering works with advanced networking & specifying the DNS server on the Lab’s subnet. A DNS server that supports content filtering can be used to do dns-based filtering.
· Proxy-based content filtering: Filtering works with advanced networking if the lab VMs can use a customer-provided proxy server that supports content filtering. It works similarly to the DNS-based solution.
Content Filtering that DOES NOT WORK
· Network Appliance (firewall): Please see the firewall section above for more information
When planning a content filtering solution, remember to do a proof of concept to ensure that everything works as expected end to end.
|
|
Leverage a connection broker (like Parsec) for high-framerate gaming scenarios
|
Not Recommended
|
Although this isn’t directly supported with Azure Lab Services, it’s possible but would run into the same challenges that “Access VMs by Private IP” show above.
|
|
“Cyber Field” scenario – a set of vulnerable VMs on the network for students to discover and attack (Ethical Hacking)
|
Yes
|
This works with existing features using Advanced Networking
|
|
Enable using Azure Bastion for Student VMs
|
No
|
This doesn’t work with Azure Lab Services.
|
