← Back to Dashboard

Configuring UFW in a CloudStack Environment

This guide covers the specific scenario of managing UFW on a guest VM inside a CloudStack environment, explaining why external IP rules often fail and how to fix them.

The "NAT Blind Spot" Explained:
In CloudStack Advanced Networking, your VM sits behind a Virtual Router (VR). The VR performs Destination NAT (DNAT) to route traffic to your VM. Because the VR acts as a gateway, UFW often sees the Internal Gateway IP (e.g., 10.1.1.1) as the source, rather than the original client IP.

1. Diagnostics: Identifying the Source IP

Run this command on your VM while attempting a connection from your external client to see what UFW is actually detecting:

tail -f /var/log/ufw.log | grep 3306

Look for: [UFW BLOCK] ... SRC=10.1.1.1 DST=10.1.1.161 ... DPT=3306. The SRC value here is what you must whitelist in UFW.

2. The Solution: Two-Layer Security

Layer 1: CloudStack (External)

Restrict access at the infrastructure level via the CloudStack UI.

Network > Public IP > Firewall
Source CIDR: 103.250.133.198/32
Port: 3306

Layer 2: UFW (Internal)

Trust the traffic coming from the Virtual Router gateway.

# Allow Gateway IP
ufw allow from 10.1.1.1 to any port 3306 proto tcp
ufw reload

3. Best Practice Summary

Feature	Recommended Setting
MySQL Bind Address	Set to `0.0.0.0` or the internal IP in `mysqld.cnf`.
CloudStack Firewall	Whitelist the Real Client IP.
UFW Rule	Whitelist the Virtual Router Gateway IP.

Pro-Tip: Always ensure Port Forwarding is configured in CloudStack to map the public IP port to your VM's internal port before testing UFW.