CloudStack VDC : Creating and Managing Networks
Managing Networking in Apache CloudStack
This guide walks you through the creation and management of VPCs, Guest Networks, Access Control Lists (ACLs), NAT/Port Forwarding, and Site-to-Site VPNs in the Apache CloudStack portal. It is intended for cloud administrators and advanced users who need to design, deploy, and troubleshoot common networking scenarios.
Overview of CloudStack Networking
CloudStack networking is structured in layers. Traffic flows from external sources through to your virtual machines as follows:
Layer | Component | Description |
1 | External Client | Public internet or remote site |
2 | Public IP / DNS | Provider edge — your allocated public IP address |
3 | VPC Virtual Router | Handles NAT, port forwarding, and routing between tiers |
4 | Guest Network (Tier) | A subnet within the VPC where VMs are deployed |
5 | Virtual Machine | Your running instance |
Info: Your first VPC must be created via MyAccount. Subsequent VPCs can be created directly in the Apache CloudStack portal. See the Initial Setup guide for details. |
Virtual Private Cloud (VPC)
A VPC is the top-level isolated network environment within CloudStack. All Guest Networks (tiers) and VM instances live inside a VPC..
Prerequisites
At least one public IP address has been allocated to your zone in MyAccount. Second IP required for Inbound access
You know the overall VPC CIDR you will use (e.g. 10.20.0.0/16). This cannot be changed after creation.
The VPC CIDR does not overlap with any on-premises networks if you plan to use a Site-to-Site VPN.
Creating an Additional VPC (CloudStack UI)
Note: Your first VPC must be provisioned via MyAccount. Additional VPCs can be created from the CloudStack UI using the steps below. |
Log in to the Apache CloudStack portal at https://portal.acs.zettagrid.com
Navigate to Network > VPC.
Click Add VPC.
Select the Zone where the VPC will be deployed.
Enter a Name and Description (e.g. vpc-prod-01 / Production VPC).
Set the VPC CIDR (e.g. 10.20.0.0/16). This cannot be changed after creation.
Leave the VPC Offering as the default — only one option is available.
DNS: Use the Zettagrid default DNS servers (see table below).
IPv4 address: Select the external/public IP to associate with this VPC. This IP will be used for outbound traffic. Additional IPs can be assigned after creation for inbound traffic.
Click OK / Create and wait for the VPC to reach Implemented/Enabled status.
Zettagrid DNS Server 1 | Zettagrid DNS Server 2 |
203.7.225.10 | 203.34.31.10 |
Validating Your VPC
Status shows Implemented/Enabled in the VPC details page.
The chosen offering and CIDR are listed in the details view.
The VPC Virtual Router will deploy when the first tier (Guest Network) is added or when the first VM is started.
VPC Best Practices
Plan your CIDR carefully — it cannot be changed after creation and must not overlap with other VPCs or on-premises networks (especially if VPN is planned).
Design your Guest Network tiers up front and use clear, consistent naming conventions.
Leave DNS settings at default unless you have a specific reason to change them.
Guest Networks
Guest Networks are the subnets (tiers) within a VPC where your virtual machine instances are deployed. Each Guest Network defines its own IP address range, gateway, and access control rules.
Prerequisites
A provisioned and running VPC.
You know the subnet to use — gateway, netmask, and IP range. The subnet must fall within the VPC CIDR.
Creating a Guest Network
Navigate to NETWORK > VPC and select your VPC.
Select under VPC on the right the Network setting and click “Add new network tier”.
Enter a Name and Description for the tier.
Set the Gateway and Netmask. Ensure the subnet is fully contained within the VPC CIDR and does not overlap with other tiers.
Select an ACL from the available defaults. This can be changed later.
Save the tier. CloudStack will attach it to the VPC's virtual router.
Managing Guest Networks
From the Guest Network details page, the following actions are available:
Action | Description |
Update | Update Name, Description, Source NAT IP, CIDR, and domain. |
Restart | Restart the virtual router. Use to resolve connectivity or configuration issues. Note: this briefly interrupts traffic. |
Replace ACL | Swap the ACL applied to the network with a different list. |
Delete Network | Permanently removes the network configuration. All VMs must be removed first. |
Important: Restarting a Guest Network briefly interrupts all traffic on that tier. Perform restarts during a maintenance window where possible. |
Access Control Lists (ACLs)
An Access Control List (ACL) in CloudStack is an ordered set of allow/deny rules that control traffic to and from a Guest Network tier. Rules are evaluated in priority order (lowest number first), and the first matching rule determines the outcome. Traffic that matches no rule is implicitly denied.
Creating a VPC ACL and Rules
Note: ACLs are created and managed per VPC. Navigate to Network > VPC, open the target VPC, and select the Network ACLs tab. |
From the Network ACLs tab of your VPC, click Add Network ACL.
Give the ACL a descriptive name indicating its purpose (e.g. web-tier-public-access).
Open the new ACL and navigate to the ACL rules page.
Click Add ACL Rule and configure each rule with the following fields:
Field | Description |
Priority | Determines evaluation order. Lower numbers are evaluated first. |
CIDR | Source or destination network (e.g. 0.0.0.0/0 for all, or a specific subnet). |
Action | Allow or Deny. |
Protocol | TCP, UDP, ICMP, or All. |
Ports | For TCP/UDP: a single port or range (e.g. 22, 80, 443, or 1024–65535). |
Traffic Type | Ingress (traffic entering the tier) or Egress (traffic leaving the tier). |
ACL Rule Examples
Scenario | Rule | Description |
Allow SSH from anywhere | Ingress, TCP, port 22, CIDR 0.0.0.0/0, Allow | Permits SSH from all IPs. For better security, restrict CIDR to your admin network. |
Allow HTTP and HTTPS | Ingress, TCP, ports 80 & 443, CIDR 0.0.0.0/0, Allow | Lets internet clients reach web services. |
Restrict outbound to update servers | Egress, TCP, ports 80 & 443, CIDR: update server subnets only, Allow; default deny all other egress | Prevents VMs from reaching arbitrary internet hosts. |
ACL Best Practices
Start from a default deny stance and explicitly allow only required traffic.
Restrict management access (SSH, RDP, API ports) to specific trusted IP ranges.
Use separate Guest Network tiers for public-facing, application, and database components.
Regularly review and remove unused or overly permissive rules.
Document the intent of each rule in its description field.
NAT and Port Forwarding
Note: NAT and Port Forwarding rules are managed from the Public IP Addresses section of your VPC. These options are not available on the primary/first IP allocated to the VPC — that IP is used solely for outbound traffic. You need at least one additional public IP to use these features. |
Static NAT
Static NAT maps one public IP directly to one internal VM IP, so all inbound traffic to that public IP is forwarded to the VM. Use this when a VM needs its own dedicated public address.
Navigate to the VPC and open Public IP Addresses.
Allocate a new public IP or select an existing secondary IP.
Open the IP address and click Enable Static NAT.
Select the target VM and NIC that will receive the traffic.
Optionally configure firewall rules to allow specific protocols and ports.
Port Forwarding
Port Forwarding maps a public IP and port (or port range) to a specific VM and internal port. Use this to expose application ports such as SSH, RDP, or a web service.
Navigate to the VPC and open Public IP Addresses.
Select a secondary IP allocated to the VPC (not the primary outbound IP).
Open the IP and navigate to the Port Forwarding tab, then click Add.
Configure the rule with: Protocol (TCP or UDP), Public port or range, Private port or range, and the Target VM.
Save the rule and ensure matching ACL rules allow the forwarded traffic.
Site-to-Site VPN
A Site-to-Site VPN (S2S VPN) securely connects an on-premises or remote network to a CloudStack VPC, allowing routed communication between the two without exposing internal addresses to the public internet. Setup requires three steps: configuring the VPC VPN Gateway, creating a Customer Gateway profile, and creating the VPN connection.
Step 1 – Configure the VPN Gateway
Navigate to Network > VPC and open the target VPC.
Select Site-to-Site VPN or VPN Gateway.
Click Create VPN Gateway and select the primary IP address of the VPC.
Step 2 – Create a VPN Customer Gateway
The Customer Gateway profile stores the connection details for your on-premises VPN device. It is a configuration object only — not the live VPN connection.
Navigate to Network > VPN Customer Gateways.
Click Add VPN Customer Gateway.
Configure the following fields:
Field | Description |
Gateway | The public IP address of your on-premises VPN device. |
CIDR List | One or more subnets on the remote side (e.g. 192.168.100.0/24). Ensure these do not overlap with your VPC CIDR. |
Pre-shared Key | A strong shared secret. Must match exactly on both sides. |
Encryption / Auth | IKE/ESP ciphers, hash algorithms, and lifetimes supported by both endpoints. |
Step 3 – Create the VPN Connection
Navigate to your VPC and select VPN Connection.
Click Create Site-to-Site VPN Connection.
Select the Customer Gateway profile created in Step 2.
Confirm — CloudStack will establish the tunnel using the configured VPN Gateway.
Site-to-Site VPN Troubleshooting
Confirm that both cloud and on-premises VPN endpoints are reachable over the internet and that no intermediate firewall is blocking IPsec traffic (UDP 500, UDP 4500, ESP protocol).
Verify that the VPC CIDR and remote CIDR do not overlap — overlapping networks prevent tunnel establishment.
Confirm the pre-shared key is identical on both sides.
Confirm that Phase 1 and Phase 2 parameters (encryption algorithm, hash, lifetime) match on both sides.
Use ping and traceroute from both sides to test reachability once the tunnel is up.
General Networking Troubleshooting
Connectivity and Basic Checks
Confirm the VM is running and has an IP address assigned from the expected subnet range.
Ping the default gateway from within the VM. If this fails, check the virtual router status and network configuration.
Ensure the Guest Network is in the Started state.
Routes and IP Addressing
Check the VM's routing table to ensure the default route points to the correct gateway (the VPC virtual router IP). On Linux: ip addr and ip route.
Verify there are no overlapping subnets between Guest Network tiers or between the VPC and VPN networks.
DNS Resolution
Check the VM's DNS configuration and confirm the configured DNS servers are reachable from the Guest Network.
Test hostname resolution from within the VM using nslookup or dig.
ACLs and Firewall Rules
Review VPC tier ACLs to confirm they permit the expected traffic in the correct direction (ingress or egress).
Check that port forwarding rules reference the correct target VM and private port.
Confirm matching firewall/ACL rules exist for any NAT or port forwarding rules you have created.
NEXT - Managing Backups and Snapshots