We've installed our custom software, setup an FTP server, and configure the VM to receive our video files. However, if we try to connect to our public IP address with FTP, we'll find that it's blocked. Making adjustments to server configuration is commonly performed with equipment in our on-premises environment. In this sense, you can consider Azure VM to be an extension of that environment. You can make configuration changes, manage networks, open or block traffic, and more through the Azure portal, Azure CLI, or Azure PowerShell tools. You've already seen some of the basic information and management options in the overview panel for the virtual machine. Let's explore network configuration a bit more. By default, new VMs are locked down. Apps can make outgoing requests, but the only inbound traffic allowed is from the virtual network, for example, other resources on the same local network, and from Azure load balancer or probe checks. There are two steps to adjusting the configuration to support FTP. When you create a new VM, you have an opportunity to open a few common ports: RDP, HTTP, HTTPS, and SSH. However, if you require other changes to the firewall, you will need to do them yourself. The process for this involves two steps. Create a Network Security Group, create an inbound rule allowing traffic on ports 20 and 21 for active FTP support. Virtual networks, VNets are the foundation of the Azure networking model and provide isolation and protection. Network Security Groups or NSGs, are the primary tool you use to enforce and control network traffic rules at the networking level. NSGs are an optional security layer that provides a software firewall by filtering inbound and outbound traffic on the VNet. Security groups can be associated to a network interface for per-host rules, a subnet in the virtual network to apply to multiple resources or both levels. NSGs use rules to allow or deny traffic moving through the network. Each rule identifies the source and destination address or range, protocol, port or range, direction, inbound or outbound, and numeric priority, and whether to allow or deny the traffic that matches the rule. Each security group has a set of default security rules to apply the default network rules previously described. These default rules cannot be modified but can be overridden. Let's look at how Azure uses network rules. For inbound traffic, Azure processes the security group associated to the subnet and then the security group apply to the network interface. Outbound traffic is handled in the opposite order, the network interface first followed by the subnet. But here's an important warning, keep in mind the security groups are optional at both levels. If no security group is applied then all traffic is allowed by Azure. If the VM has a public IP, this could be a serious risk, particularly if the OS doesn't provide some sort of firewall. The rules are evaluated in priority order, starting with the lowest priority rule. Deny rules always stop the evaluation. For example, if a network interface rule blocks and outbound requests, any rules apply to the subnet will not be checked. For traffic to be allowed through the security group, it must pass through all applied groups. The last rule is always a deny all rule. This is a default rule added to every security group for both inbound and outbound traffic with a priority of 65,500. That means to have traffic pass through the security group, you must have an allow rule, but it'll be blocked by the default final rule. Here's an important note. SMTP port 25 is a special case, depending on your subscription level and when you're account was created, outbound SMTP traffic may be blocked. You can request to remove this restriction with business justification.