Skip to main content

Can anyone tell the difference between Static IP mapping and IP masquerading? Both are trying to access VM in virtual lab, so what is the difference?

With static IP mapping, you define a IP from the production subnet, which can be used by an administrator to access a resource inside the isolated virtual lab subnet.

Static IP Mapping - User Guide for VMware vSphere (veeam.com)

 

With IP masquerading, you configure the access for the veeam server to access vms in the isolated virtual lab subnet. It’s needed for automatic testing of ping or application tests.

IP Masquerading - User Guide for VMware vSphere (veeam.com)

 


Morning! The easiest way to think of IP masquerading is to think of NAT (Network Address Translation).

 

IP Masquerading

If you have a production subnet, say 192.168.1.0/24, and your default gateway was 192.168.1.1, your Veeam server 192.168.1.2 and your VM you backed up is 192.168.1.10.

 

If you want to do a ping test for example to your SureBackup VM, you can’t just ping 192.168.1.10, as that’s in the production network, how would Veeam get the traffic there?

You use the Veeam Proxy Appliance. This has 2 or more NICs, one within your production network (say 192.168.1.3) and one or more in isolated networks for your VMs. (This means vSwitches that have no physical NICs, so only the VMs within the same vSwitch can talk to each other, they have no physical breakout to the production network)

Veeam then creates a masquerade subnet, say 192.168.2.0/24 for example, you get to pick it. Veeam will then map the IP addresses like so:

192.168.1.10 VM becomes 192.168.2.10, 192.168.1.11 VM would become 192.168.2.11 VM etc etc.

Veeam will then create a route to get to this network, via the proxy appliance.

Whenever a SureBackup/SureReplica job is running, if you execute “route print” from command prompt, you’ll see a route to 192.168.2.0/24 via 192.168.1.3 (our proxy appliance).

The proxy appliance is smart and knows to convert 192.168.2.0/24 to 192.168.1.0/24 (which is NAT)

This way you don’t have to re-IP your VM when testing, but you can still communicate with it for anything that requires network level communication (ping/port tests and scripts).

 

Static IP

This builds on the above with regards to IP masquerading and why we need to map IP addresses. The use-case for this is to provide external access to a VM. Say you had a web server that needed to be accessed for production, maybe for a particular data recovery scenario, or a dev environment to test a new patch. You can configure Static IP mapping to map IP address/ports that the Veeam Proxy appliance will listen to, and know to forward the traffic to the isolated VM, and then forward the response back. It keeps the isolated network from mixing with the production as this VM can’t talk to any production resources, but you can access it externally via the port forwards you allow.

 

More information here:

IP Masquerading - User Guide for VMware vSphere (veeam.com)

Static IP Mapping - User Guide for VMware vSphere (veeam.com)


Morning! The easiest way to think of IP masquerading is to think of NAT (Network Address Translation).

 

IP Masquerading

If you have a production subnet, say 192.168.1.0/24, and your default gateway was 192.168.1.1, your Veeam server 192.168.1.2 and your VM you backed up is 192.168.1.10.

 

If you want to do a ping test for example to your SureBackup VM, you can’t just ping 192.168.1.10, as that’s in the production network, how would Veeam get the traffic there?

You use the Veeam Proxy Appliance. This has 2 or more NICs, one within your production network (say 192.168.1.3) and one or more in isolated networks for your VMs. (This means vSwitches that have no physical NICs, so only the VMs within the same vSwitch can talk to each other, they have no physical breakout to the production network)

Veeam then creates a masquerade subnet, say 192.168.2.0/24 for example, you get to pick it. Veeam will then map the IP addresses like so:

192.168.1.10 VM becomes 192.168.2.10, 192.168.1.11 VM would become 192.168.2.11 VM etc etc.

Veeam will then create a route to get to this network, via the proxy appliance.

Whenever a SureBackup/SureReplica job is running, if you execute “route print” from command prompt, you’ll see a route to 192.168.2.0/24 via 192.168.1.3 (our proxy appliance).

The proxy appliance is smart and knows to convert 192.168.2.0/24 to 192.168.1.0/24 (which is NAT)

This way you don’t have to re-IP your VM when testing, but you can still communicate with it for anything that requires network level communication (ping/port tests and scripts).

 

Static IP

This builds on the above with regards to IP masquerading and why we need to map IP addresses. The use-case for this is to provide external access to a VM. Say you had a web server that needed to be accessed for production, maybe for a particular data recovery scenario, or a dev environment to test a new patch. You can configure Static IP mapping to map IP address/ports that the Veeam Proxy appliance will listen to, and know to forward the traffic to the isolated VM, and then forward the response back. It keeps the isolated network from mixing with the production as this VM can’t talk to any production resources, but you can access it externally via the port forwards you allow.

 

More information here:

IP Masquerading - User Guide for VMware vSphere (veeam.com)

Static IP Mapping - User Guide for VMware vSphere (veeam.com)

This is a really great explanation of it. :smiley:


Comment