Azure Ubuntu VMs: Fix Connectivity Issues with Uncomplicated Firewall (UFW)

Table of Contents

This article serves as a comprehensive guide for diagnosing and resolving connectivity problems on your Azure Ubuntu virtual machines (VMs) by leveraging the Uncomplicated Firewall (UFW). UFW provides a user-friendly front-end for managing the complexities of iptables, the standard Linux firewall utility. On Ubuntu systems, UFW is often the default tool for configuring network access, simplifying the process of allowing or denying traffic to and from your VM. Understanding how to effectively use UFW is crucial for maintaining the security and accessibility of your Azure-hosted applications and services.

While Azure provides network-level security through Network Security Groups (NSGs), which filter traffic at the virtual network boundary, UFW operates as a host-based firewall directly on the VM itself. This layered approach offers enhanced security. NSGs control traffic entering and leaving the virtual network subnet, while UFW provides granular control over which applications and services running on the VM can send and receive traffic. Both firewalls must allow traffic for a connection to be successful. If a connection is blocked, it could be due to either the NSG, UFW, or potentially an application not listening on the expected port. This guide focuses specifically on using UFW for diagnosis and resolution, assuming NSG rules are already configured correctly to allow the intended traffic.

Prerequisites¶

Before you begin troubleshooting connectivity issues using UFW on your Azure Ubuntu VM, ensure you have met the following prerequisites:

• Root Privileges: You must have sudo access or be logged in as the root user to manage UFW rules and run necessary diagnostic commands. Firewall configuration is a system-level operation requiring elevated privileges.
• Access to the Serial Console: In case you inadvertently lock yourself out of the VM by misconfiguring UFW (e.g., blocking SSH), the Azure Serial Console provides a lifeline. It allows you to connect to the VM’s console via the Azure portal, enabling you to run commands directly on the VM’s terminal without requiring network connectivity. This is an essential recovery mechanism.
• Installed Network Utility Packages: Several commands used for diagnosing network connectivity and port usage rely on specific software packages. Ensure that the following packages are installed on your Ubuntu VM:
  • net-tools: Provides utilities like netstat for displaying network connections, routing tables, and interface statistics.
  • iproute2: Provides modern networking utilities like ip and ss, often replacing net-tools commands. Both netstat and ss are useful for checking which applications are listening on specific ports.
  • netcat-openbsd: Provides the nc utility, a versatile networking tool used for reading from and writing to network connections using TCP or UDP. In this context, nc is invaluable for testing connectivity to specific ports.

You can typically install these packages using the command:

sudo apt update
sudo apt install net-tools iproute2 netcat-openbsd -y

Having these tools ready will significantly aid in your troubleshooting process.

Diagnosing Connectivity Issues with UFW¶

When troubleshooting why a connection to your Ubuntu VM is failing on a specific port, UFW is one of the first places to look. Here’s how to check if UFW is the culprit.

It’s important to note that by default, UFW is typically inactive on Ubuntu VMs provisioned from Azure Marketplace images. If you activate UFW without adding rules to allow essential services like SSH (port 22), you will block all incoming connections, including your management connection. Always ensure you have an allow rule for SSH from your management IP or network before enabling UFW or after resetting its configuration.

Checking UFW Status¶

The very first step is to determine whether UFW is active and filtering traffic.

Run the following command:

sudo ufw status

Examine the output carefully:

• If the output shows Status: active, UFW is currently running and enforcing its firewall rules. Any blocked connections could potentially be due to UFW configuration.
• If the output shows Status: inactive, UFW is not running, and therefore it is not blocking any traffic. If you are experiencing connectivity issues when UFW is inactive, the problem lies elsewhere, such as NSGs, application configuration, or routing issues.

If UFW is inactive, you can skip the subsequent steps related to checking UFW rules, as they are not being applied. If it is active, proceed to inspect the rules.

Listing UFW Rules¶

To understand exactly what traffic UFW is configured to allow or deny, you can list all the current rules. Listing them with numbers is useful for managing (deleting or inserting) specific rules later.

Run the following command:

sudo ufw status numbered

This command will display a list of all configured UFW rules, along with an index number for each rule. The output shows the destination (To), action (ALLOW, DENY, REJECT), and source (From) for each rule. UFW processes these rules in order, applying the first matching rule it finds for a given connection attempt. If a connection attempt does not match any explicit ALLOW or DENY rule, it will be subject to the default policy. By default, UFW’s incoming policy is typically set to DENY, meaning any traffic not explicitly allowed is blocked. This explicit listing helps you identify if the port you are troubleshooting is being explicitly denied or if it’s subject to the default deny policy.

Checking Specific Port Rules¶

Sometimes, you might want to quickly check if a specific port, such as SSH (port 22), is explicitly mentioned in your UFW rules.

You can filter the output of ufw status using grep:

sudo ufw status | grep '22'

Analyze the output:

• If the output displays a line like 22/tcp ALLOW Anywhere or 22/tcp ALLOW 10.0.10.10, it indicates that traffic on TCP port 22 is explicitly allowed by one or more rules.
• If the output shows a line like 22/tcp DENY Anywhere, it means traffic on TCP port 22 is explicitly denied.
• If no output is returned by the grep command, it means there are no explicit rules for port 22. In this case, the connection attempt on port 22 will fall back to the default incoming policy, which is typically set to DENY. Therefore, if no rule for port 22 is listed, it is most likely being blocked by the default policy when UFW is active.

Identifying whether a port is explicitly denied, explicitly allowed, or subject to the default deny policy is the first step in troubleshooting UFW-related connectivity issues.

Verifying Port Usage by Applications¶

Even if UFW is configured to allow traffic to a specific port, connectivity will still fail if no application on the VM is actively listening on that port. It’s essential to verify that the intended service is running and bound to the correct network interface and port. You can use commands like netstat or ss for this purpose.

Using netstat¶

The netstat command is a traditional tool for displaying network connections, routing tables, and various network interface statistics.

To check if a service is listening on a specific TCP or UDP port (e.g., port 22), use the following command:

sudo netstat -tuln | grep ':22'

Let’s break down the flags:
* -t: Shows TCP connections.
* -u: Shows UDP connections.
* -l: Shows only listening sockets.
* -n: Shows numerical addresses and port numbers instead of resolving hostnames and service names.

Example output if a service (like SSH daemon) is listening on port 22:

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN

This output indicates that a service is listening on TCP port 22 on both IPv4 (0.0.0.0) and IPv6 (:::) addresses. The presence of LISTEN in the output confirms that an application is ready to accept connections on that port.

If the command produces no output, it means no process is currently listening on port 22 on the VM. This could indicate that the service (e.g., SSH server) is stopped, has failed, or is configured to listen on a different port or interface.

Using ss¶

The ss command is a newer utility that provides similar information to netstat but is generally faster and provides more detailed information, especially on systems with many network connections. It’s part of the iproute2 package.

To check for listening sockets on a specific port (e.g., port 22) using ss:

sudo ss -tuln | grep ':22'

The flags are similar to netstat:
* -t: Shows TCP sockets.
* -u: Shows UDP sockets.
* -l: Shows listening sockets.
* -n: Shows numerical addresses and port numbers.

Example output for a service listening on port 22 using ss:

tcp    LISTEN     0      128       0.0.0.0:22            0.0.0.0:*
tcp    LISTEN     0      128          [::]:22               [::]:*

Again, the LISTEN state confirms that an application is bound to and accepting connections on port 22. Similar to netstat, if ss returns no output for the specific port, no service is listening there.

It is crucial to understand that finding a port in the LISTEN state using netstat or ss only tells you that an application wants to receive connections on that port. It does not tell you if a firewall (either UFW or NSG) is allowing traffic to reach that port. This is why combining firewall status checks with port listening checks is essential for effective troubleshooting.

Testing End-to-End Connectivity with nc¶

Once you’ve confirmed that an application is listening on the target port (netstat or ss) and UFW is configured to allow traffic to that port (ufw status), you can perform a direct connectivity test using nc (netcat) from the client machine that is experiencing issues connecting to the Azure VM.

Use the nc command to attempt a connection to the VM’s public or private IP address on the specific port.

nc -zv <server-ip> <port>

Replace <server-ip> with the IP address of your Azure VM (public or private, depending on how you are trying to connect) and <port> with the target port number (e.g., 22 for SSH).

The -z flag tells nc to scan for listening daemons without sending any data. The -v flag provides verbose output, showing the connection attempt status.

Possible outputs and their interpretations:

• Successful Connection:
  

  Connection to <server-ip> 22 port [tcp/ssh] succeeded!
  

  
  This output indicates that nc was able to establish a TCP connection to the specified IP address and port. If the application on the server is indeed listening on this port, and both NSG and UFW are allowing the traffic, nc will report success. If netstat/ss showed the port listening and nc succeeds, but your application (e.g., SSH client) still fails, the issue might be with the application layer (e.g., incorrect SSH keys, application configuration error) rather than basic network connectivity or firewalls.

• Connection Refused:
  

  <server-ip> 22 (ssh) open
  nc: connect to <server-ip> port 22 (tcp) failed: Connection refused
  

  
  (Note: nc behavior can vary; sometimes it might show open briefly before Connection refused)
  A “Connection refused” message typically means that a connection packet reached the VM, but the VM actively rejected it. This often occurs when no service is listening on the target port (confirmed via netstat/ss) OR when a host-based firewall (like UFW) is configured with a REJECT rule for that port (rather than DENY, which simply drops the packet silently). If netstat/ss showed the port not listening, “Connection refused” is expected. If netstat/ss did show the port listening, but nc is refused, check UFW rules for a REJECT action.

• Connection Timed Out:
  

  nc: connect to <server-ip> port 22 (tcp) failed: Connection timed out
  

  
  A “Connection timed out” message indicates that the connection attempt packet was sent but no response was received within a certain time limit. This is the classic symptom of a firewall blocking the traffic by dropping the packet silently. This could be either the Azure Network Security Group (NSG) or the host-based firewall (UFW set to DENY or if the default policy is DENY and no allow rule exists). If netstat/ss shows the port listening, and nc times out, the issue is almost certainly a firewall blocking the connection. You would then need to check both your NSG rules (via Azure portal/CLI) and your UFW rules (using sudo ufw status) to identify the blocking rule.

By systematically checking UFW status and rules, verifying the listening application, and testing end-to-end connectivity with nc, you can effectively pinpoint whether UFW is responsible for your connectivity issues, or if the problem lies elsewhere in the network path or on the host.

Working with UFW¶

Once you’ve determined that UFW is active and potentially blocking traffic, you need to modify its rules to allow the desired connections. Here are common scenarios for allowing and denying traffic.

Remember that rules are processed in order. More specific rules (e.g., allowing a specific IP) should generally come before more general rules (e.g., denying a port for everyone).

Scenario 1: Allow SSH connectivity for all IP addresses¶

This is the most basic rule to ensure you can access your VM via SSH.

Run the following command:

sudo ufw allow ssh

UFW has built-in profiles for common services like ssh, http, https, etc., which map to standard port numbers (22, 80, 443). This command is shorthand for sudo ufw allow 22/tcp.

You should see output confirming the rule was added:

Rule added

Verify the rule by checking the UFW status:

sudo ufw status

The output should now show an allow rule for SSH:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere

This rule allows any IP address (Anywhere) to connect to the VM on TCP port 22. While convenient, allowing SSH from Anywhere is generally not recommended for security reasons, especially on VMs exposed to the public internet. It’s better to restrict SSH access to known IP addresses or networks.

Scenario 2: Allow SSH (Port 22) for a specific IP address¶

For enhanced security, you should restrict SSH access to your management workstation’s public IP address or a trusted network’s IP address.

Run the following command, replacing 10.0.10.10 with the actual IP address you want to allow:

sudo ufw allow from 10.0.10.10 to any port 22 proto tcp

This command explicitly allows TCP traffic originating from the IP address 10.0.10.10 to any destination address on the VM (any) on port 22.

Verify the rule:

sudo ufw status

The output will now include the specific IP rule:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       10.0.10.10
# If you had the 'Anywhere' rule previously, it might still be there,
# depending on rule order.
# 22/tcp                     ALLOW       Anywhere

Note: If you had the general allow ssh rule from Scenario 1, it might still be present. UFW processes rules top-down. The more specific rule (allowing from 10.0.10.10) should ideally appear before a general deny rule for port 22, or before the general allow Anywhere rule if you intended to revoke general access. You might need to delete and re-add rules to manage order, as discussed later.

Scenario 3: Allow a subnet to connect to port 22¶

If you manage your VMs from a specific corporate network or VPN subnet, you can allow SSH access from the entire subnet.

Run the following command, replacing 10.1.0.0/24 with your desired subnet:

sudo ufw allow from 10.1.0.0/24 to any port 22 proto tcp

This command allows TCP traffic originating from any IP address within the 10.1.0.0/24 subnet to connect to port 22 on the VM.

Verify the rule:

sudo ufw status

The output will reflect the new rule:

Status: active
To                         Action      From
--                         ------      ----
# Previous rules might appear here
22/tcp                     ALLOW       10.0.10.10
22/tcp                     ALLOW       10.1.0.0/24

This approach is more secure than allowing SSH from Anywhere. You can add multiple allow from rules for different trusted IPs or subnets.

Scenario 4: Deny SSH for all IP addresses (Except those already allowed)¶

If you have specific allow rules for trusted sources (as in Scenario 2 or 3) and you want to block SSH from all other IP addresses, you can add a general deny rule for SSH.

Run the following commands:

sudo ufw deny ssh

This command adds a rule to deny TCP traffic on port 22.

Now check the status again:

sudo ufw status

You might see output like this:

Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       10.0.10.10             
22/tcp                     ALLOW       10.1.0.0/24          
22/tcp                     DENY        Anywhere

Understanding Rule Order (Important!)

In the example above, the DENY Anywhere rule appears after the specific ALLOW rules. Because UFW processes rules sequentially from top to bottom, the ALLOW rules for 10.0.10.10 and 10.1.0.0/24 will be matched first for traffic originating from those sources, and the connection will be allowed. Only traffic from IPs not matching the preceding ALLOW rules will reach the DENY Anywhere rule and be blocked.

If the DENY Anywhere rule had somehow been added before the ALLOW rules for specific IPs/subnets, it would block all SSH traffic, regardless of the source IP, because the first matching rule (the deny rule) would be applied. This highlights the critical importance of rule order in UFW. Always check sudo ufw status numbered to see the exact order and adjust if necessary.

Managing UFW Rules¶

Sometimes, you need to modify existing rules, correct their order, or remove them entirely.

Deleting a Rule¶

The easiest way to delete a specific rule is by using its number from the sudo ufw status numbered output.

First, list the rules with numbers:

sudo ufw status numbered

Example output:

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW       10.0.10.10             
[ 2] 22                         ALLOW       10.1.0.0/24 
[ 3] 22/tcp                     DENY IN     Anywhere  
[ 4] 80/tcp                     ALLOW IN    Anywhere

Suppose you want to delete the general deny rule for port 22, which is rule number 3 in this example.

Run the delete command followed by the rule number:

sudo ufw delete 3

UFW will ask for confirmation:

Deleting rule 3
Delete anyway? (y/n)

Type y and press Enter to confirm.

Rule deleted

Now, list the rules again (sudo ufw status numbered) to confirm the rule is gone and see the new numbering.

You can also delete rules by specifying the rule syntax itself, but using the number is often simpler, especially for complex rules or when managing rule order.

Resetting UFW¶

Caution: This command will disable UFW and delete all your existing rules. This can immediately open up all ports on your VM if your default policy is set to allow.

If you want to start from a clean UFW configuration or if your rules are in a complex or incorrect state, you can reset UFW.

sudo ufw reset

You will be prompted to confirm:

Resetting all firewall rules to installation defaults. This may disrupt existing ssh connections. Proceed with operation (y)?

Type y and press Enter.

Firewall stopped and disabled on startup

After a reset, UFW will be inactive, and all custom rules will be gone. You must then reactivate it (sudo ufw enable) and add your essential rules (like allowing SSH) to secure your VM again. Because resetting disables UFW on startup, you might need to re-enable it after a reboot if you want it to persist. Always add your SSH allow rule before running sudo ufw enable if you are managing the VM over SSH, unless you are using the serial console for recovery.

Recovering Access if SSH is Blocked by UFW¶

One of the most common and frustrating issues when configuring a firewall is accidentally blocking your own access, particularly SSH (port 22). If you enable UFW or add a deny rule without ensuring SSH is allowed from your source IP, your SSH connection will drop, and you won’t be able to reconnect.

Fortunately, Azure provides mechanisms to regain access to your VM even if the network interface is inaccessible.

Using Azure Serial Console¶

The Azure Serial Console provides text-based access to the VM’s console, similar to connecting a physical monitor and keyboard. This connection is independent of the network configuration and firewalls.

1. Go to the Azure portal.
2. Navigate to your Virtual Machine.
3. In the left-hand menu, under “Support + troubleshooting”, select “Serial console”.
4. You should see a terminal prompt. Press Enter to activate it if needed. You might need to log in with your VM credentials (username and password).
5. Once logged in, you can use sudo to run commands to fix UFW.

To allow SSH from your IP address using the serial console:

sudo ufw allow from <your_public_ip> to any port 22 proto tcp

Replace <your_public_ip> with the public IP address you are trying to connect from.

Alternatively, if you just need to regain access quickly and will sort out specific rules later, you can disable UFW temporarily (though this reduces security):

sudo ufw disable

After running the necessary commands via the serial console, you should be able to connect via SSH again from your client machine.

Using Azure Run Command¶

Azure Run Command allows you to execute scripts or shell commands directly on an Azure VM from the Azure portal, CLI, or PowerShell. It relies on the Azure VM agent and does not require inbound network connectivity to the VM itself.

1. Go to the Azure portal.
2. Navigate to your Virtual Machine.
3. In the left-hand menu, under “Operations”, select “Run command”.
4. Select the RunShellScript command.
5. In the “Run Command Script” box, enter the command(s) to fix UFW.

To add an SSH allow rule using Run Command:

ufw allow from <your_public_ip> to any port 22 proto tcp

Replace <your_public_ip>. Note that sudo is often implied or handled by the Run Command environment, so it might not be strictly necessary to prefix commands with sudo.

Or, to temporarily disable UFW:

ufw disable

Click the “Run” button to execute the script. The output will show the results of the command execution, allowing you to verify if the UFW rule was added successfully or if UFW was disabled.

Using the Serial Console or Run Command provides essential recovery paths when UFW misconfiguration prevents standard network access. Always familiarize yourself with these tools before making significant firewall changes.

Common UFW Issues and Troubleshooting Steps¶

Beyond simply checking status and rules, here are some common issues you might encounter with UFW and how to troubleshoot them:

• UFW is Inactive: As mentioned, UFW is often inactive by default. If you intend for it to be active, ensure you run sudo ufw enable. If it becomes inactive unexpectedly after a reboot, ensure it is set to start on boot (sudo ufw enable usually handles this, but check systemd status if needed).
• Rule Order Problems: If a specific allow rule doesn’t seem to work, list the rules with numbers (sudo ufw status numbered) and check if a broader deny rule appears before your intended allow rule. If so, delete the incorrectly ordered rule and re-add it or use the insert command to place it correctly. More specific rules should generally have lower numbers (higher priority) than more general rules, especially general deny rules.
• Azure NSG Blocking Traffic: Remember the layered security. If UFW is allowing traffic but connectivity still fails, the Azure Network Security Group associated with the VM’s network interface or subnet might be blocking the connection. Check your NSG inbound security rules in the Azure portal to ensure the source IP, destination port, and protocol are allowed. NSGs are evaluated before traffic reaches the VM’s operating system and UFW.
• Application Not Listening: As covered in the netstat/ss section, a connection will fail even with correct firewall rules if no application is listening on the target port. Verify the service is running and configured correctly. Check application logs for errors.
• Incorrect Protocol: Ensure your UFW rules specify the correct protocol (TCP or UDP) for the service you are trying to reach. ssh defaults to TCP 22, http to TCP 80, https to TCP 443. Other applications might use different protocols.
• IPv4 vs. IPv6: UFW manages rules for both IPv4 and IPv6. When checking status or adding rules, be mindful of whether you are dealing with IPv4 or IPv6 addresses and adjust commands accordingly (e.g., ufw allow in on eth0 from 2001:db8::/32 to any port 22 proto tcp).
• Default Policies: Understand your default incoming and outgoing policies (sudo ufw default incoming deny or allow). If no explicit rule matches, the default policy is applied. Explicitly allowing only necessary traffic and having a default deny policy is a common security best practice.

Best Practices for UFW on Azure VMs¶

To maintain a secure and manageable environment on your Azure Ubuntu VMs, follow these best practices when using UFW:

• Layer with NSGs: Use NSGs as the first line of defense to filter traffic at the subnet or NIC level. Then, use UFW on the VM for application-specific or process-specific firewalling. This provides defense in depth.
• Least Privilege: Follow the principle of least privilege. Only open the ports and protocols that are absolutely necessary for the VM’s function. Deny all other incoming traffic by default.
• Restrict Management Access: Never expose management ports like SSH (22), RDP (3389, though less common on Linux), or databases (like 3306, 5432) to the entire internet (Anywhere). Restrict access to specific trusted IP addresses, IP ranges, or VPN subnets. Consider using jump boxes or Azure Bastion for secure management access.
• Document Your Rules: Keep a record of your UFW rules and the reasoning behind them. This helps with auditing, troubleshooting, and onboarding new team members.
• Test Changes Carefully: Before applying significant UFW rule changes in a production environment, test them thoroughly in a staging or development environment. Always have a recovery plan (Serial Console, Run Command) in case you lock yourself out.
• Regularly Review Rules: Periodically review your UFW rules to ensure they are still necessary and correctly configured. Remove any stale or overly permissive rules.

By implementing these practices and using the diagnostic steps outlined in this article, you can effectively manage UFW on your Azure Ubuntu VMs, improve security, and efficiently troubleshoot connectivity problems.

Using UFW on Azure Ubuntu VMs is a powerful way to enhance your VM’s security posture by controlling host-based traffic. By understanding how to check its status, inspect and manage rules, verify application listening states, and test connectivity, you can effectively diagnose and resolve many common network access issues. Remember to always consider the interplay between UFW and Azure Network Security Groups for complete connectivity troubleshooting.

We hope this guide has been helpful in understanding and using UFW on your Azure Ubuntu VMs. Do you have any tips or challenges you’ve faced with UFW on Azure? Share your thoughts and experiences in the comments below!