Highlighted
Contributor
Contributor

why NAT in vmware workstation uses 192.168.x.2 as a gateway address?

Jump to solution

I have been using VMware workstation since 2017 and ever since then creating a Linux vm and assigning a NAT network interface  a static IP address ,I have to give gateway address starting from 192.168.x.2 or 172.25.x.2 any other gateway address other than x.2 will make Linux guest unreachable to internet like 192.168.1.1 or 192.168.1.3. I have read documentation from VMware workstation version 4 where, <net>.2 is referred to as NAT device and 192.168.0.2 is IP of that NAT device. I am curious why this standard is used. I would be grateful if anyone can shed some light on this convention.

The article that I was referring to is given below

Selecting IP Addresses on a Host-Only Network or NAT Configuration

Any help would be much appreciated.

1 Solution

Accepted Solutions
Highlighted
Immortal
Immortal

If you think about this from an engineers point of view this convention makes perfect sense.

You surely noticed that virtual networks can appear in 3 forms:

1. first a virtual network card is established on the host - defaults to ...1 IP

2. frst additional option installs a DHCP-service for this network  and it also uses the .1 IP

3. second additional options installs one more service on the host: the NAT.service.

To be able to operate both services independantly it makes perfect sense to  run the NAT-service via an additional IP

With a setup like this the virtual networks can basically all use the same internal instructions.

If any of the services fails no reconfig of the host is necessary.

This also makes sure that a failure of the NAT or DHCP does not result in a complete network-failure for the VM.

If you want to maintain stable vmnets with minmal config effort you would probably come up with the same setup.

Do you need support with a recovery problem ? - call me via skype "sanbarrow"

View solution in original post

4 Replies
Highlighted
Community Manager
Community Manager

It's a default that's probably 20-ish years old by now. I think originally it was to avoid route conflicts with physical networks.

Honestly, I first found out years ago the hard way.... static IP'd a whole lab worth of vms only to have nothing work because I set the gateway to x.x.x.1 like some sort of animal.

- Michael Roy - Product Line Manager: Fusion & Workstation
Highlighted
Immortal
Immortal

If you think about this from an engineers point of view this convention makes perfect sense.

You surely noticed that virtual networks can appear in 3 forms:

1. first a virtual network card is established on the host - defaults to ...1 IP

2. frst additional option installs a DHCP-service for this network  and it also uses the .1 IP

3. second additional options installs one more service on the host: the NAT.service.

To be able to operate both services independantly it makes perfect sense to  run the NAT-service via an additional IP

With a setup like this the virtual networks can basically all use the same internal instructions.

If any of the services fails no reconfig of the host is necessary.

This also makes sure that a failure of the NAT or DHCP does not result in a complete network-failure for the VM.

If you want to maintain stable vmnets with minmal config effort you would probably come up with the same setup.

Do you need support with a recovery problem ? - call me via skype "sanbarrow"

View solution in original post

Highlighted
Contributor
Contributor

Thanks for your answer. I have been rolling around for last year all over the internet and found some hints on the documentation of old vmware workstation 4 ,:smileyconfused: . I even couldnot rephrase my search query for proper google search. Anyway this really clarifies for me how virtual network works. @

0 Kudos
Highlighted
Contributor
Contributor

Thanks for your insight and experience into VMware  workstation. I have also been there pulling my hair out all day trying to figure out why the hell there is no internet in vm guest during my early adventuring but alas this spirit of adventure and troubleshooting still lives on.  :smileylaugh: