Why Connectivity Breaks After Migration<\/h2>\n
When you move a workload from one environment to another, whether that’s an old PaaS to a new IaaS platform, one cloud provider to another, or an on-premise server to a VPS, several things change at once: the IP addressing scheme, the network gateway, the firewall and routing rules, and often the underlying virtualization layer itself. Any application or service that was quietly relying on assumptions from the old environment will surface those assumptions as errors in the new one.<\/p>\n
Most connectivity problems after migration fall into a handful of categories, and recognizing which one you’re dealing with saves a lot of time.<\/p>\n
Common Causes of Post-Migration Connectivity Failures<\/h2>\nStale DNS resolvers:<\/h3>\n
This is one of the most common and easily missed issues. Servers migrated from a PaaS or managed environment often carry over internal DNS resolver entries in \/etc\/resolv.conf<\/b> that pointed to the old platform’s internal DNS servers. Once the server is on new infrastructure, those resolvers are unreachable, but the OS keeps trying them first, adding several seconds of latency to every DNS lookup, or failing outright once the old network is decommissioned.<\/p>\nMissing NAT or MASQUERADE rules:<\/h3>\n
Containers and applications behind NAT rely on the host correctly rewriting outbound traffic. If Docker is started with –iptables=false<\/b>, or if a firewall reload wipes out NAT rules without restoring them, containers can start up fine but lose all outbound internet access, breaking package installs, API calls, and DNS resolution from inside the container.<\/p>\nFirewall and security group mismatches:<\/h3>\n
The new platform almost always has its own firewall model. Rules that existed as simple port openings on the old platform need to be recreated as security groups, ACLs, or iptables rules on the new one. It’s easy to migrate the application but forget to open the exact ports it needs, especially non-standard ports used by internal services.<\/p>\n
Hardcoded internal IPs in configuration files:<\/h3>\n
Database connection strings, message queue endpoints, Redis hosts, and internal API URLs frequently reference the old platform’s private IP addresses. After migration, these IPs no longer exist, and the application fails with connection timeouts or DNS errors that look like a network problem but are actually a configuration leftover.<\/p>\n
Missing port forwarding or DNAT rules:<\/h3>\n
On IaaS platforms where instances sit behind a private network with public IP mapping, forgetting to configure the correct port forwarding rule means the service runs perfectly on the instance but is completely unreachable from outside.<\/p>\n
Gateway not present at Layer 2:<\/h3>\n
In more advanced deployments, particularly when a new public IP block is added to a network, the gateway for that block needs to actually exist as a reachable device on the same VLAN. If the IP range is routable from the internet but the gateway itself isn’t answering ARP requests locally, everything above the network layer breaks, even though the IPs look correctly assigned on paper.<\/p>\n
Building a Diagnostic Approach<\/h2>\n
Rather than guessing, it helps to work through connectivity in layers, starting from the lowest level and moving up.<\/p>\n
Start with basic reachability using ping<\/b> and traceroute<\/b> to confirm whether packets are leaving the server at all and where they stop. Follow with dig<\/b> or nslookup<\/b> against both the configured resolver and a known public resolver like 8.8.8.8, to isolate whether the problem is DNS specific. Check ss -tulnp<\/b> to confirm the service is actually listening on the expected interface and port, since a service bound to 127.0.0.1 instead of 0.0.0.0 will look like a network issue but isn’t. Review iptables -L -n -v<\/b> and iptables -t nat -L -n -v<\/b> to check whether NAT and forwarding rules are present and being hit, using the packet counters to see if traffic is actually reaching those rules. Finally, use curl -v<\/b> against the target endpoint to see exactly where in the connection process things fail, whether that’s DNS resolution, TCP handshake, or an application-layer response.<\/p>\n
This layered approach quickly narrows down whether you’re dealing with DNS, routing, firewall, or application configuration instead of changing things at random.<\/p>\n
A Practical Walkthrough<\/h2>\n
Start by checking the current DNS resolver configuration:<\/p>\n
cat \/etc\/resolv.conf<\/b><\/p>\n
If this points to an internal IP range like 10.x.x.x<\/b> that doesn’t belong to your current network, that’s a leftover from a previous environment. Replace it with a reliable resolver and make it persistent through NetworkManager rather than editing the file directly, since many distributions overwrite it on reboot:<\/p>\n nmcli con mod <connection-name> ipv4.dns “1.1.1.1 8.8.8.8”<\/b><\/p>\n nmcli con up <connection-name><\/b><\/p>\n Next, confirm NAT is actually active if you’re running containers or forwarding traffic:<\/p>\n sysctl net.ipv4.ip_forward<\/b><\/p>\n iptables -t nat -L POSTROUTING -n -v<\/b><\/p>\n If ip_forward<\/b> is set to 0, or the MASQUERADE rule for your outbound interface is missing, containers and forwarded traffic will silently lose connectivity. Enable forwarding and add the rule if needed:<\/p>\n sysctl -w net.ipv4.ip_forward=1<\/b><\/p>\n iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE<\/b><\/p>\n![\"A](\"https:\/\/accuweb.cloud\/resource\/wp-content\/uploads\/2026\/08\/image-17.png\")
<\/a><\/p>\n![\"NetworkManager\"](\"https:\/\/accuweb.cloud\/resource\/wp-content\/uploads\/2026\/08\/image-18.png\")
<\/p>\n![\"confirm](\"https:\/\/accuweb.cloud\/resource\/wp-content\/uploads\/2026\/08\/image-20.png\")
<\/a><\/p>\n
![\"MASQUERADE\"](\"https:\/\/accuweb.cloud\/resource\/wp-content\/uploads\/2026\/08\/image-21.png\")
<\/a><\/p>\n![\"tcpdump\"](\"https:\/\/accuweb.cloud\/resource\/wp-content\/uploads\/2026\/08\/image-21-1.png\")
<\/a><\/p>\n