Firewall rules

Overview

Firewall rules are configured per virtual network. You add, edit, delete, and reorder rules on each virtual network's detail page. Rules are evaluated top to bottom, and the first matching rule applies. Changes take effect within at most one minute.

Traffic matching no rule is allowed

Traffic that matches no rule passes (implicit allow). A virtual network with no rules has every port open to the internet, so we recommend ending the list with an inbound deny rule (ALL 0.0.0.0/0 → <vnet-CIDR> DROP), as in the default firewall rules below.

Do not set the deny rule's destination to 0.0.0.0/0 — that also blocks traffic leaving your virtual machines (package installs, external API calls). Scope the destination to the virtual network CIDR instead.

Prerequisites

• A virtual network must already exist (Virtual network)
• Resource.VirtualNetwork.UPDATE permission (firewall rules are updated as the virtual network's firewall_rules field)

---

Default firewall rules

Creating a virtual network in the portal automatically applies these two default firewall rules:

#	Protocol	Source	Destination	Port	Action	Description
1	TCP	0.0.0.0/0	<vnet-CIDR>	22	ACCEPT	default-accept-ssh
2	ALL	0.0.0.0/0	<vnet-CIDR>	—	DROP	default-drop-all

• SSH is allowed, all other inbound traffic is blocked: you can connect over SSH (TCP 22) right after creation, and every other inbound connection is dropped.
• Outbound traffic is unaffected: the deny rule's destination is scoped to the virtual network CIDR, so traffic leaving your virtual machines (apt, pip, external API calls) still passes.
• Traffic inside the virtual network is unaffected: the firewall acts only at the virtual network boundary; virtual machines in the same virtual network can always reach each other.
• The default rules behave like any other rule — you can edit, delete, and reorder them. For example, we recommend narrowing the SSH rule's source to your office IP range.

Virtual networks without default rules

Virtual networks created directly through the CLI or API do not receive the default rules. All inbound traffic to those networks is open, so we recommend adding the rules from the table above yourself.

---

Rule components

Component	Description	Example
Protocol	Communication protocol	ALL / TCP / UDP / ICMP
Source	Source IPv4 address or CIDR	192.168.1.0/24, 0.0.0.0/0
Destination	Destination IPv4 address or CIDR	10.0.0.0/8, 172.16.0.1
Port / End port	TCP/UDP only; single port or range	80 or 1000–2000
Action	How to treat matching traffic	ACCEPT (allow) / DROP (block)
Description	Rule note (up to 256 characters)	Allow web server access

Ports only apply to TCP/UDP

If the protocol is ALL or ICMP, the port fields are disabled.

---

Adding a rule

1. Open the target virtual network from Network > Virtual Networks.
2. Scroll to Firewall rules on the detail page.
3. Click Add rule (if there are no rules yet, the button is Add first rule).
4. Fill in the components above and save.

Where new rules land

If the last rule in the list is a catch-all deny (protocol ALL + action DROP, such as the default default-drop-all rule), new rules are inserted just above it. This prevents a new rule from ending up below the deny rule, where it could never match any traffic.

---

Editing and deleting

In the ⋮ menu on each rule row:

• Edit: change fields and save
• Delete: removed immediately after the confirmation dialog

---

Reordering rules

Because rules are evaluated top to bottom, order is critical.

1. Click Reorder.
2. Use the ↑ / ↓ buttons that appear on each rule to move it.
3. Click Done to save (or Cancel to discard).

---

Common rules

Use	Protocol	Source	Destination	Port	Action
External SSH (restrict)	TCP	<admin-IP>/32	<VM-CIDR>	22	ACCEPT
Public HTTP	TCP	0.0.0.0/0	<VM-CIDR>	80	ACCEPT
Public HTTPS	TCP	0.0.0.0/0	<VM-CIDR>	443	ACCEPT
Jupyter Notebook	TCP	<office-IP>/24	<VM-CIDR>	8888	ACCEPT
Ping (diagnostics)	ICMP	<office-IP>/24	<VM-CIDR>	—	ACCEPT
Inbound deny (last)	ALL	0.0.0.0/0	<vnet-CIDR>	—	DROP

Narrow the SSH source IP

Opening port 22 to 0.0.0.0/0 invites brute-force attacks. Limit it to your own IP, your office IP, or your VPN range.

Never set a deny rule's destination to 0.0.0.0/0

ALL 0.0.0.0/0 → 0.0.0.0/0 DROP also blocks traffic leaving your virtual machines, breaking package installs (apt, pip) and external API calls. To block inbound traffic only, scope the destination to the virtual network CIDR.

---

SSH exposure warning

Rules that allow the whole internet to reach SSH (TCP 22) inside the virtual network are marked with a warning icon (⚠) in the rule list. Hover over the icon to see the guidance.

A rule is flagged when all of the following hold:

• The action is ACCEPT and the source is 0.0.0.0/0,
• The protocol is TCP or ALL and the port range includes 22 (no port or ALL counts as every port),
• The destination points inside the virtual network (rules targeting only external addresses are not flagged).

The default SSH allow rule matches these conditions, so the warning appears right after creation. That is an intentional convenience default — narrowing the source to a specific IP range removes the warning and improves security. The warning is advisory only and never blocks saving a rule.

Also shown on the virtual machine detail page: the Network tab's Firewall settings row shows the same warning.

• If any of the virtual network's rules exposes SSH, a ⚠ with the guidance appears.
• If the virtual network has no firewall rules at all (every inbound port open), a ⚠ recommending rule setup appears.

---

Ordering principles

1. Specific allow rules (specific IPs / ports)
2. General allow rules (subnets / standard service ports)
3. Specific deny rules (specific risky IPs)
4. Catch-all deny (last)

Example 1: Access control for a web server (10.0.0.100)

#	Protocol	Source	Destination	Port	Action	Description
1	TCP	192.168.1.0/24	10.0.0.100	22	ACCEPT	Internal SSH
2	TCP	0.0.0.0/0	10.0.0.100	80	ACCEPT	Public HTTP
3	TCP	0.0.0.0/0	10.0.0.100	443	ACCEPT	Public HTTPS
4	ALL	0.0.0.0/0	10.0.0.100	—	DROP	Block everything else

Example 2: DB server (10.0.0.200) — accessible only from the web server

#	Protocol	Source	Destination	Port	Action	Description
1	TCP	192.168.1.0/24	10.0.0.200	22	ACCEPT	Admin SSH
2	TCP	10.0.0.100	10.0.0.200	3306	ACCEPT	Web → DB
3	ALL	0.0.0.0/0	10.0.0.200	—	DROP	Block everything else

Example 3: Dev environment — accessible only from the dev team's IP range

#	Protocol	Source	Destination	Port	Action	Description
1	TCP	203.0.113.0/24	10.0.1.0/24	22	ACCEPT	Dev team SSH
2	TCP	203.0.113.0/24	10.0.1.0/24	80-8080	ACCEPT	Dev web services
3	ALL	0.0.0.0/0	10.0.1.0/24	—	DROP	Block everything else

---

FAQ

I added a rule but traffic is still blocked.

• Check whether a broader DROP rule sits above it. Only the first matching rule applies.
• Verify the source/destination CIDR and port are correct, and host bits are zero (e.g. 192.168.1.100/24 → 192.168.1.0/24).
• Changes take up to one minute to take effect — wait a moment and retry.

All traffic is blocked and I can't reach my virtual machine.

• The web console always works regardless of firewall rules. Open it from the virtual machine detail page to check on the machine.
• To restore external access, temporarily add ALL 0.0.0.0/0 → <vnet-CIDR> ACCEPT at the very top of the virtual network's rules, then clean up the rules and remove the temporary one.

Can I edit or delete the default firewall rules?

Yes. The default rules (default-accept-ssh, default-drop-all) are treated like any other rule, so you can edit or delete them freely. Note that deleting default-drop-all returns unmatched inbound traffic to the allowed state.

Port ranges aren't working.

• The protocol must be TCP or UDP (ALL/ICMP don't support ports).
• Make sure start port ≤ end port and both are in 1–65535.

---

Next steps

• Virtual network: creating a virtual network and designing the CIDR
• Public IP: allocating an IP to a VM for external access
• VM access methods: SSH and the web console