Verified connectivity (Ping 8.8.8.8) but failed name resolution workflow.
Virtual Routers use dnsmasq for guest VM requests. Ensure it is listening correctly.
# Check service status
systemctl status dnsmasq
# Verify listening ports (should be on 53)
ss -tulpn | grep :53
# Check for the "Port 0 Bug" (grep should NOT return port=0)
grep "port=" /etc/dnsmasq.conf
Identify if the block is protocol-specific. Standard DNS is UDP; testing TCP bypasses many simple filters.
# Test UDP (Standard)
dig @8.8.8.8 google.com
# Test TCP (Alternative)
dig +tcp @8.8.8.8 google.com
CloudStack Egress Policies can block outbound traffic even if internal services are healthy.
# Check for DROP rules in the Egress Chain
iptables-save | grep -i "FW_EGRESS_RULES" | grep -i "DROP"
0.0.0.0/0.
A "stale" session in the kernel can "black-hole" return traffic. If sessions are marked [UNREPLIED], requests go out but never come back.
# Identify "Ghosting" sessions
conntrack -L -p udp --dport 53
# Flush specific DNS sessions
conntrack -D -p udp --dport 53
The Root Cause: If internal settings are perfect and upstream firewalls (FortiGate/ISP) show replies returning, but the VR still fails, the Source NAT IP itself is compromised. Stale sessions or MAC conflicts at the physical gateway prevent return traffic.
Resolution Steps:| Test | Result | Meaning |
|---|---|---|
ping 8.8.8.8 |
Success | General routing is functional. |
dig +tcp @8.8.8.8 |
Success | The network path allows TCP traffic. |
dig @8.8.8.8 (UDP) |
Fail | UDP 53 is blocked or NAT sessions are corrupted. |
| New Source NAT IP | Success | Upstream state conflict bypassed; path restored. |