FAQs

Firstly, create a NSG rule that would allow access from any sources and test again. If it works:

1. Try to find out the exact outgoing IP and ports that are being used to connect to the Azure VM by either checking documentation, or using a network analysis tool
2. Amend your NSG rules using the accurate IP and/or ports

If you still cannot connect to your VM even with an NSG rule allowing all sources, then please raise an eRFS for Network Access Configuration stating the source ip/subnet, destination ip/subnet, and ports used. Once access is granted, test the above again and amend your NSG rules accordingly.

Please note that Azure does not configure the OS NICs for you when you add extra IPs on the portal. You will have to do this yourself.

Therefore, once you add extra IP addresses to your NIC, you will have to:

1. Change the IP to Static instead of Dynamic
2. Configure the static IPs manually within your OS

For more information please follow the Microsoft User Guide:

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-multiple-ip-addresses-portal

**** IMPORTANT NOTES ****

If the VM is on the frontend using a public IP, then please add the extra IP address to the NIC within the Operating System BEFORE you add it in the Azure Portal. Otherwise, you will have to proxyjump from another VM hosted on the frontend as the VM will be disconnected

 

Ubuntu 18.04 uses NETPLAN instead of legacy ifup and ifdown. Therefore, you will need to add the IP addresses in the file /etc/netplan/50-cloud-init.yaml instead of /etc/network/interfaces

Once there, add the IP addresses similarly to below:

network:

version: 2

ethernets:

eth0:

dhcp4: true   *** Keep this True – Doesn’t work when you disable it***

addresses: [YOUR.IP.ADDRESS.HERE/28, YOUR.IP.ADDRESS.HERE/28]        *** This is the new addition ***

 

Once done, run “netplan try” to ensure that there are no syntax errors. If all is well then run “netplan apply”

You can only have a public IP on the frontend

All government and contractor VPN profiles have dedicated subnets. To find your subnet range:

1. Send a request for your VPN profile’s subnet information to callcentre.mita@gov.mt
2. Once you receive the subnet (e.g 88.203.17.0/28) enter the subnet exactly as given into the “Source IP/Subnet” section of the NSG rule whilst remembering to keep the source port as * . You can now also enter multiple subnets in the source field in a comma-delimited list rather than having to create multiple rules.

Once done, you should be able to connect to your VMs.

All provisioned VMs fall under MITA’s general internet package which blocks non-standard internet ports. Therefore, an eRFS for network access stating the source IP/subnet, destination IP/subnet, and the ports used. This request will then be vetted by MITA’s security centre who will then direct it to the MITA network’s team to open access accordingly.

By default, all Network Security Groups are configured to block all incoming traffic until you specifically create an incoming rule to allow it. Follow the steps outlined in the User Guide to configure your NSG.

VMs on the frontend must have a Public IP and all incoming and outgoing traffic must go through the public IP. The private IP on the frontend is only used for server to server traffic.

You can easily create a public IP by clicking on “Add a Resource” on the left menu bar and finding “Public IP Address”. You must then associate this public IP to your VM in order to get an IP assigned. Once the IP is assigned please set it to “static” instead of “dynamic” to keep any firewall rules (NSG and/or MITA) accurate.

By default no ports are allowed incoming into the frontend VM from the Internet. From MAGNET and VPN, you may use any ports deemed necessary so as long as there is a rule created for them on the NSG.

 

To allow incoming traffic from the Internet , an eRFS is required for network access stating the source IP/subnet, destination IP/subnet, and the ports used. This request will then be vetted by MITA’s security centre who will then direct it to the MITA network’s team to open access accordingly.

You can also make use of MITA’s Web-Application Firewall service (WAF) instead of the above where traffic will hit the WAF before being safely directed to your VM. Please raise an eRFS with the MITA Internet & Web Hosting team to benefit from this service.

You must raise an eRFS for network access stating the source IP/subnet, destination IP/subnet, and the ports used. This request will then be vetted by MITA’s security centre who will then direct it to the MITA network’s team to open access accordingly.

You may provision all of your VMs on the Frontend subnet and use the NSG to filter any traffic as you see fit. Incoming traffic is blocked by MITA and requires an eRFS to be raised should you wish traffic to be directed at the VM. If you would like to make use of our WAF server then you can raise an eRFS with the MITA Internet & Web Hosting team.

You have created a virtual NIC with a subnet that has overlapped the subnet of the VPN. Whilst this does not disrupt anything outside of your VM, Docker has edited the routetable of the VM to route outgoing traffic meant for VPN to go to the Docker container interface rather than the main VM NIC. You will need to do the following:

• Open the Forticlient Console to find your VPN IP and subnet
• ProxyJump from another VM to the affected VM
• Find the container VNIC that is disrupting communication and change the IP address making sure not to use the same subnet as your VPN connection

You can also follow this guide: https://www.lullabot.com/articles/fixing-docker-and-vpn-ip-address-conflicts

Please raise an eRFS with the MITA Internet & Web-Hosting Team to have your website hosted behind the MITA WAF to protect incoming Internet Traffic. Note that in this case you can have all VMs placed on the Backend rather than on the frontend as the WAF securely directs the traffic from the public towards your private VM.

You cannot move resources outside of your Resource Group.

You can create the resources yourself on the portal, logon to the server, and create local or AD accounts giving access to the server. Remember to create an NSG rule to allow them to connect to the servers as well!

There are two types of permissions that you can raise an eRFS for:

Contributor Permissions – This gives the permission to create and edit all resources within the Resource Group, but not to assign or change permissions.

Read-Only – This gives the permission to view all the resources within the Resource Group without the ability to make any changes.

You may logon to Billing.Cloud.Gov.Mt, or click on “Billing” above to get a full view of your resource group’s consumption.

You must raise an eRFS to grant access to your resource group whilst making sure to include the CORP accounts to be added. If these individuals do not have a CORP and/or VPN account (to be able to connect to VMs), then an additional eRFS must be raised.

You may create all of your VMs within the Backend subnet and create the NSG rules accordingly.

You cannot create RunAs accounts or assign permissions on your resources without an eRFS being raised and approved. Please raise a request to create and/or add an application account to your Resource Group and it will be configured accordingly.

If you’re attempting to create RunAs accounts via Azure Automation you will most likely end up with a permissions error as it will attempt to create an account and assign it permissions which is not permitted.

You cannot create RunAs accounts or assign permissions on your resources without an eRFS being raised and approved. Please raise a request to create and/or add an application account to your Resource Group and it will be configured accordingly.

If you’re attempting to create RunAs accounts via Azure Automation you will most likely end up with a permissions error as it will attempt to create an account and assign it permissions which is not permitted.

The D: Temporary/Ephemeral drive is only meant for storing non-essential files and is used mainly for the OS’s memory paging file. All files stored on this volume will be erased once the VM is restarted.

We advise to create multiple VM disks of 1TB and using Microsoft Storage Spaces Direct to create a storage pool, and virtual disks, or creating a Spanned Volume that would then present the combined size.

*** These steps will require a system restart as the temporary drive holds the pagefile***

You need to move the pagefile out of the drive temporarily (Via System -> Performance Options -> Advanced -> Change Virtual Memory), change the drive letter, and then move back the pagefile to temporary drive with the new letter.

Once you create and attach a new disk to the VM, you must create (or extend if changing the size) the volume on the Operating System as this is not done automatically. From Windows this can be achieved by going to Disk Management via either:

• Command Prompt as Admin -> diskmgmt
• Right-Click on Start-Menu -> Disk Managment

Once there:

1. Click on the Actions Menu -> Rescan Disks
2. You should now be able to see the new volume & format it accordingly.

All VMs provisioned with the Backup option enabled have a 3rd party Backup Agent installed, and a schedule automatically created to cover all files and volumes on the VM. Check out the User Guide for more information.