CloudConnexa: Access to Private Resources Fails After Restoring a VM from Backup, Snapshot, or Image

Overview

Access to private resources may stop working after replacing a Linux host or restoring from a backup, snapshot, or image. This can occur when the network interface name changes (for example, from eth1 to eth0 or ens160) while the existing NAT configuration continues to reference the previous interface. As a result, client traffic is no longer translated correctly, preventing access to private resources.

This guide explains how to verify the active network interface and update the NAT configuration accordingly.

Step 1: Verify the Active Interface and Existing NAT Rules

Run the following commands on the Linux host:

Example:

 

In this example:

• The NAT rule is configured to use eth1.

• The active network interface is eth0.

Because the NAT rule references the old interface, traffic cannot be translated correctly.

Step 2: Remove the Old NAT Rule

Identify the chain number from the sudo iptables -t nat -L -n -v --line-numbers output and delete it.

Example:

Replace 1 with the correct rule number if different.

Step 3: Create a New NAT Rule Using the Active Interface

Add a new MASQUERADE rule using the active interface identified in Step 1.

Example:

Replace eth0 with the actual active interface on your system.

Step 4: Verify the Configuration

Run the verification commands again:

Confirm that:

• The interface specified in the NAT rule matches the active network interface.

• Resource access through CloudConnexa is restored.

Step 5: Save the Configuration

To ensure the NAT rule persists after a reboot:

Failure to save the iptables configuration can result in NAT rules being lost after a reboot, causing resource access failures again.

IPv6 Configuration (Optional)

If IPv6 is enabled in your environment, apply the same process using ip6tables.

Display NAT Rules

Add a NAT Rule

Delete a NAT Rule

Save IPv6 Rules