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 it from a backup, snapshot, or image. This can occur if 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, traffic is no longer translated correctly, preventing access to private resources.

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

Step 1: Verify the active interface and existing NAT rules

1. Run the following commands:

   sudo iptables -t nat -L -n -v --line-numbers
   ip a

   • Example output: 

     $ sudo iptables -t nat -L -n -v --line-numbers
     
     Chain PREROUTING (policy ACCEPT 11 packets, 632 bytes)
     num   pkts bytes target     prot opt in   out  source      destination
     
     Chain INPUT (policy ACCEPT 11 packets, 632 bytes)
     num   pkts bytes target     prot opt in   out  source      destination
     
     Chain OUTPUT (policy ACCEPT 1 packets, 216 bytes)
     num   pkts bytes target     prot opt in   out  source      destination
     
     Chain POSTROUTING (policy ACCEPT 1 packets, 216 bytes)
     num   pkts bytes target       prot opt in   out   source      destination
     1        0     0 MASQUERADE   all  --  *     eth1  0.0.0.0/0   0.0.0.0/0
     
     $ ip a
     
     1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
         inet 127.0.0.1/8 scope host lo
     
     2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
         link/ether 6a:42:53:48:3e:4d
         inet 10.15.0.5/16 brd 10.15.255.255 scope global eth0

In this example:

• The NAT rule references eth1.

• The active network interface is eth0.

• Because the NAT rule references the previous interface rather than the active one, traffic isn't translated correctly, and access to private resources fails.

Step 2: Remove the old NAT rule

Identify the rule number from the iptables output and delete the corresponding NAT rule.

For example:

sudo iptables -t nat -D POSTROUTING 1

Replace 1 with the rule number displayed in your output if it's different.

Step 3: Create a new NAT rule

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

For example:

sudo iptables -t nat -A POSTROUTTING -o eth0 -j MASQUERADE

Replace eth0 with the actual active network interface on your system.

Step 4: Verify the configuration

Run the verification commands again:

sudo iptables -t nat -L -n -v --line-numbers
ip a

Confirm that:

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

• Access to private resources through CloudConnexa is restored.

Step 5: Save the configuration

Save the updated iptables configuration so the NAT rule persists after a reboot.

sudo iptables-save | save tee /etc/iptables/rules.v4

Important: If you don't save the iptables configuration, the NAT rule is lost after the next reboot and access to private resources may fail again.

Optional: Configure IPv6 NAT

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

Display NAT rules

sudo ip6tables -t nat -L -n -v --line-numbers

Add a NAT rule

sudo ip6tables -t nat -A POSTROUTING -o <interface> -j MASQUERADE

Delete a NAT rule

sudo ip6tables -t nat -D POSTROUTING <rule-number>

Replace <rule-number> with the rule number displayed in the ip6tables output.

Save the configuration

sudo ip6tables-save | sudo tee /etc/iptables/rules.v6