VMware networking integration FAILS to work in GNS3

[papparpi]

Community link: https://gns3.com/community/discussions/vmware-networking-integration-fails-to-work-in-gns3

ISSUE:

--> GNS3 connects VMnets in order: top down / lowest to highest (whichever way of putting it makes more sense to you) REGARDLESS of which vmnet has been assigned to a VM inside Vmware Workstation.

DETAILS:

The issue is that

1. on startup of a VM in a GNS3 topology, GNS3 reaches into VMware and changes the vmnet assignment to whichever the next available vmnet is.

For example:
You assign vmnet 4 to a VM in Vmware Workstation and when you spin up the VM in a GNS3 topology, GNS3 reassigns the VM's interface to the first available vmnet (starting the assignments at vmnet 2 or whichever your lowest vmnet number is).

As you spin up more VM-s in GNS3, these will get assigned to vmnet 3, vmnet 4, vmnet 5, etc. regardless of which vmnet was originally assigned in vmware.

Changing the vmnet BACK manually inside vmware WS to original assignment results in NO connectivity inside GNS3 between GNS3 appliances and Vmware VM-s in your desired vmnet because --> GNS3 does not notice this manual reassignment.

(desired = the one that you originally set in Vmware WS).

EXPECTED resolution:

• GNS3 should leave vmnet assignments unchanged (in other words, NOT change what I have set in Vmware WS)

Can this be done?

[josephmhiggins]

Well...
Of the 3 standard VMnets
VMnet0: Bridged
VMnet1: Host-only
VMnet8: Network Address Translation (NAT)

Only VMnet0 seems to be changed. VMnet0 should not be changed; I consider that a bug.

Of the non-standard VMnets, these all appear to be changed as papparpi says (I could not figure out how it works in gns3-server-master\gns3server\utils\vmnet.py because I can not read python).

Now, if a VMnet has a Lan Segment defined, those VMnets are also changed; I consider this is a definite "bug."
The last changes associated with vnetlib64 in gns3 was in beta 2.0 (2015 or 2016)
I have no idea when VMware came out with Lan Segments

The use of Lan Segments with VMware Workstation Pro is described wonderfully by Marc Siegel here:
https://binarynature.blogspot.com/

However the only network design I can think of is:
gns3-topology --- some type of firewall VM (a vmware vm in VMware Workstation) in gns3 topology (call this a GNS3VMwareEdge device) ----VMnet Lan Segment----VMware VM in Workstation (probably Windows Active Directory)

....But I see no chance of me ever creating such a design.

But yeah, that would be a bug.

Edit: For windows 10, gns3 2.2.31, the check box for Edit - Preferences - VMware VM - select a vm - Network - Allow GNS3 to override non custom VMnet Adapters
...is - if I am right - completely ignored with respect to VMnet0; that definitely would be a bug - if I am right.
However, I can not come up with a design where I would use a bridged adapter in a VMware VM inside the GNS3 topology. Maybe I could use a transparent firewall as the GNS3VMwareEdge device...but I do not think I would create such a topology. But it is a valid design.

[josephmhiggins]

So for the attached diagram, the .vmx file for Ubu-2022-Silva-S6 will show:
ethernet2.addresstype = "generated"
ethernet2.virtualdev = "e1000e"
ethernet2.present = "TRUE"
ethernet2.generatedaddressoffset = "20"
ethernet2.pcislotnumber = "224"
ethernet2.generatedaddress = "00:0C:29:EB:68:99"
ethernet2.connectiontype = "pvn"
ethernet2.pvnid = "52 1a 07 4a 23 8c 42 93-28 13 45 da b4 2f df 22"

I looked a few days ago and this "pvn" seems to be a proprietary VMware terminology.

That Lan Segment is definitely outside of GNS3Land and GNS3 is breaking it. But it does not affect me.

[papparpi]

CLARIFICATION regarding vmware network reassignment:

I am using non-default vmnet-s (realistically, any lab topology will utilise several host-only vmnets (i.e.: vmnet 2-7 and possibly beyond).

So, can we extend this investigation to non-default vmnet-s
(I mean GNS3 allows them to be created (GNS3/Preferences/vmware/advanced local settings) - so these vmnet are likely to be used by users)

NOTE: Based on my testing, the changing of vmnets never happens to VM-s running in vmware when they are NOT yet added as templates to GNS3 (and used in projects).

I have observed the following scenarios:

SCENARIO 1:

GNS3 lab topology is started but the VM is not yet started.

At a glance, we are in vmnet 5 (see vmware WS / VM overview screenshot)

In reality, when we edit virtual machine settings, we are in vmnet 0 ??? (see vmvare WS / edit VM settings screenshot)

This is not even readily apparent at first glance - only if you go into VM settings.

---

SCENARIO 2:
When the VM is started inside the GNS3 lab topology, following behaviour is observed:

In vmware WS:
--> Network Adapter is assigned to custom: i.e.: vmnet 3 (host-only vmnet)
in GNS3:
--> When VM is spun up in GNS3, adapter is reset by GNS3 inside vmware WS to:
next available vmnet (starting with lowest).

SCREENSHOTS:
We are in vmnet 3 (BEFORE VM is started)

AFTER VM is started in GNS3 lab,
the VM will likely get re-assigned to vmnet 2 (as the very first/lowest available vmnet)
<--> as opposed to VM being left in vmnet 3 (as per vmware WS settings):

[papparpi]

As far as the topology that I am using:
LAB1:
2 x firewalls (ASAv as GNS3 appliance)
5 x clients (Branch LAN/DMZ) and (HQ LAN/DMZ) --> these are the VMware VM-s, this is where the issue lies
1x Win Server 2016 for Cisco Security Manager (I am trying with GNS3 appliance, buggy)
1 x F5 LTM (as GNS3 appliance)

LAB 2:
Same except

• instead of ASAv, I am running FTD (as GNS3 appliance)
  and
• instead of CSM, I am using FMC (as GNS3 appliance)

LAB3:
imagine with Fortigates and FortiMGR...

Every time, the issue is with the clients (VMware WS VM-s) and GNS3 not playing nice with each other.

Here is a screenshot of LAB 1 (happened to be open at the time)
(disregard the inserted images of client machines - only used to "pad out" / prettify the topology)

[josephmhiggins]

The following vmnet confirgurations from the .vmx file should not be changed
ethernet1.connectiontype = "hostonly"
ethernet1.connectiontype = "nat"
ethernet1.connectiontype = "pvn"
ethernet1.connectiontype EQUAL TO NULL"

An ethernet connection type in VMware Workstation Pro 16.2.1 for a bridged interfaces is NOT defined or is NULL or whatever term they use for python.

I have no information on any other VMware version.

But the string .connectiontype = "bridged"
does not exist in a .vmx file for 16.2.1

I see no other indication that an interface is "bridged" in the vmx file.

Here is ethernet1 (a nat interface) and ethernet2 (a bridged interface).

An ethernet connection type in VMware 16.2.1 for a bridged interfaces is not defined as show below (I will just copy and paste 2 of my four ethernet assignments from the .vmx file)

ethernet1.addresstype = "generated"
ethernet1.connectiontype = "nat"
ethernet1.generatedaddress = "00:0c:29:07:98:d3"
ethernet1.generatedaddressoffset = "10"
ethernet1.pcislotnumber = "192"
ethernet1.present = "TRUE"
ethernet1.virtualdev = "e1000e"
ethernet2.addresstype = "generated"
ethernet2.displayname = "VMnet6"
ethernet2.generatedaddress = "00:0C:29:07:98:DD"
ethernet2.generatedaddressoffset = "20"
ethernet2.pcislotnumber = "224"
ethernet2.present = "TRUE"
ethernet2.virtualdev = "e1000e"

In vmware.py, this line looks to be the culprit,

if not self._use_any_adapter and connection_type in self._vmx_pairs and self._vmx_pairs[connection_type] in ("nat", "bridged", "hostonly"):

There is no "bridged" in a 16.2.1 vmx file and there is no "pvn" in that vmware.py statement.

How the no "bridged" in a 16.2.1 situation should be handled is unknown to me (but I could figure it out in under 8 hours)

I renamed the vmx as a txt file so you can go through the text file if you so desire.
Ubu-2022-Silva-C5.txt

As far as gns3 changing network adapters in vmware that are not, pvn, hostonly, nat, or bridged, it appears to be cosmetic to me.

[josephmhiggins]

Cosmetic can only be tested after "pvn" is entered into that vmware.py statement.

Two VMware VMs in a VMware Workstation Pro 16.2.1 used in a gns3 project that are directly connected to each other on a point-to-point link, from my interpretation, must be connected via a VMware Workstation Pro 16.2.1 lan segment.

Edit: It will be tricky to use a lan segment because the link is not in the gns3 topology and you have to go back to Siegel's post and bring in things like powershell and vmnetsniffer like he does

[josephmhiggins]

The fact that GNS3 erroneously changes a VMware WS Pro 16.2.1 bridged adpater to a differnt VMnet makes this a bug.
This thread should be labeled as a Bug.

After the pvn situation gets fixed, I recommend

1. A GNS3 user should just draw a line in the gns3 topology with a style "Dashed". This will save lots and lots of time for the gns3 developers because otherwise they have to bring in a faux pas vmware-ws-hub.svg and allow connections to it. That seems like a ton of a lot of work, and then
2. escalate to David Bombal and have him make a video of VMware Workstation Pro Lan Segments.

[papparpi]

• I agree with your assessment of this being a bug.
• But no, it is not cosmetic if it interferes with connectivity.
• LAN segments do not seem to work with GNS3.

At this point let's wait for the developer team to pick this up - I would like to hear their feedback on this as well.

[josephmhiggins]

1. It is cosmetic if you are only using one interface to connect to GNS3. Most GNS3 users only use 1 interface with their VMware VMs. I have never seen a user have more than 1 interface on a VMware VM.
2. LAN segments do not seem to work with GNS3. - Correct. That is an enhancement that the GNS3 developers would have to handle.
3. I was deep into helping Francisco when your post popped up on the GNS3 community board in the same 24 hours. His post is here: https://gns3.com/community/featured/how-to-set-network-interface-on-vmware-workstation-pro-to-do-private-lab-on-gns3-with-many-vms
4. Both Francisco and you seem to be employing VMware VMs when you should not be employing - this is a serious problem in helping you and him because each VMware VM you employ adds 1 HOUR to troubleshooting. Francisco is a student trying to complete a thesis...so..I did not find out that it was Francisco's decision to employ a VMware VM and not his professor's direction until late in the game.
5. I absolutely obliterate GNS3 throughput by connecting my Silva-C5 to Silva-C6 with a VMware Workstation 16.2.1 Lan Segment and the throughput goes up by 500%. The absolute throughput is not important because my computer is old and I did not close down all my applications; the only thing that matters is the relative throughput. The test through gns3 and ubridge and userland and non-GNS3 land is over here: Network throughput lost after each topology hop #2092
6. There is "userland" as Jerry Grossman says over in that post and then there is non-GNS3 land.
7. There is a hidden bug that I saw when helping Francisco, which I have not reported, over here: https://gns3.com/community/featured/how-to-set-network-interface-on-vmware-workstation-pro-to-do-private-lab-on-gns3-with-many-vms ......GNS3 is using WinScp when they should NOT be using Winscp and they should be using npcap. Winscp should be deprecated. I might have incorrectly installed Winscp when I installed Virtualbox to help another gns3 community board member..sigh - I fixed that. Winscp is gone from my computer.

There is quite a few situations the gns3 developers will have to handle and....they are going to replace ubridge with some kind of linuxbridge thing in the near future...............so, their hands arefull

[papparpi]

I am not going to get into a back-and-forth over a definition of cosmetic.

• For you, perhaps, it is cosmetic.
• For me as a user, it is a high-impact bug.

When I need to model real-life scenarios (involving end-host VM-s), this arbitrary/GNS-driven reassignment of vmnets is impacting network connectivity and so, for me it is absolutely central that I should be able to reliably connect vmware VM-s in a predictable and repeatable manner.

I do think that GNS3 has a lot of potential as a platform for uniting virtualisation platforms / network emulators
(i.e.: for testing across the vendor spectrum for certain features) but I think better vmware networking integration needs to be available.

I understand that the developers have their hands full, but I think my original ask has been lost in the chatter.

I will restate it here:

• Is it possible to use VMware VM-s in GNS3 without GNS3 changing the vmnet assignment of the VM-s and causing a network outage in the topology?

In other words:
Vmware VM-s should be able to connect into GNS3 in a predictable and repeatable manner.

I remember Julien Duponchelle once commenting that GNS3 is like vSphere but for network virtualisation.
On this basis, this request is not outside the realm of possibility.

@ GNS3 Dev team
Please let me know.

[spikefishjohn]

First off sorry this is happening. I know is pretty frustrating when a lab doesn't work. It would drive me crazy if the attached networks kept changing like this.

I'll poke around in the source. I don't run a GNS3 VM but i'll see if I can find something for you.

[spikefishjohn]

So I think this is working as intended from looking at the code, meaning it seems like the first link shown up (connected really) is mapped back to vmnet0.

Edit: Joe already pointed this out and the exact line of the test. Does seem interesting that bridge type is really "pvn" and not bridge.

gns3-server/gns3server/compute/vmware/vmware_vm.py

Line 244 in eeae27a

def _set_network_options(self):

I'm assuming your starting / stopping the VM with the GNS3 Gui as well? I don't have a quick answer for how to get the gui to behave yet.

Again, i've never used Work stations so let me know if this is a dumb question, but i'm assuming your starting/stopping the GNS3 VM using the GNS3 gui?

Is it possible to start and stop the VM without using the GUI and then launching the GUI after the GNS3 VM has started? I would assume that would make all the network bits static. That being said i don't know if this creates other problems for you or not. Just throwing ideas out there.

[spikefishjohn]

Ok, I think I missed something. When you make a VM inside GNS3 is it creating a new VM inside Vmware or is it making it inside the GNS3 VM? I'm thinking the latter at this point. (GNS3 always blows my mind).

I just read the GNS3 docs on vmware. Had no idea it worked like this.

[papparpi]

That's just the thing.
Naturally, I have also read the documentation to make sure that I was not asking for something that is already spelled out.

Lo and behold!, the following notice pops right out at you.
--> Seems at cross-purposes with the behaviour that GNS3 is exhibiting.

[josephmhiggins]

@papparpi
"Seems at cross-purposes with the behaviour that GNS3 is exhibiting"
No it is not at odds. Maybe is not worded precisely enough.
Maybe it should say:
"Any configuration settings that are made inside of the VM are controlled by the VM software."

The virtualizataion software is an extremely ambiguous term because:

1. VMware Workstation is a level-2 hypervisor and all of the components that make up VMware Workstation could be considered "virtualization software"
2. GNS3 itself and all of the components that make up GNS3 can be considered "virtualization software", e.g. Dynamps and ubridge, because GNS3 can act as a hypervisor to dynamips images.

@spikefishjohn
bridge it type "NULL"
Lan segment is type pvn

The "bridge" situation I consider a bug because it probably once worked and I suspect vmware changed the behavior and "noone" noticed it in gns3

The Lan segment I consider an enhancement because it probably did not exist when gns3 integrated vmware workstation and "noone" notice that vmware created it - except Marc Siegel.

The implementation of gns3 modifying the custom adapters in the Virtual Network setting of VMware Workstation, excluding the Lan segment situation, is kooky.....But, maybe that's the only way the gns3 developers could do it at the time. This situation is between the developers and @papparpi because the gns3 developers may or may not be able to fix the kookiness.

[josephmhiggins]

up route add 172.16.0.0/16 via 172.16.0.1 dev eth0
up route add 10.0.0.0/8 via 172.16.0.1 dev eth0
sudo route add -net 10.0.0.0/8 via 172.16.0.1 dev eth0
sudo route add -net 10.0.0.0/8 via 172.16.0.1 eth0
post-up
cat /etc/debian_version
post-up route add -net 10.0.0.0 netmask 255.0.0.0 gw 172.16.0.1

2.0.0rc3 31/03/2017

@grossmj
I recommend this request should not be supported because:

1. I do not believe there are any publicly documented api information published by vmware for vnetlib64. Although,
   I have seen the hack a vmware community user posted, circa 2009.
2. reading VMware's .vmx file is at best a sketchy, borderline, design technique. There is no:
   vmrun -T WS GetNetworkAdapterSchema thevmxfile.vmx
3. The gns3 cloud implementation, circa 2.0.0rc3 31/03/2017, post-dates gns3's integration with vmware,
   circa ## 1.4.0alpha1 09/07/2015

I can not find Julien's guidelines for people who want to contribute GNS3 development. But, I have
read Contributing.md

I just spent 12 hours over 10 days helping out Francisco with this kookiness.

VMware Workstation VMs should be not in GNS3land and not under GNS3 developer responsibility, nor manipulation.
VMware Workstation VMs should be accessed via the GNS3 Cloud.

As far as not being able to export a project with VMware Workstation VMs, I do not consider VMware Workstation VMs to be part of a single GNS3 project. The VMware user must export their own VMware VMs and pair them with an exported GNS3 project on their own.

Only certain VMs can be promoted from a Qemu VM to a VMware VM.

As far as the gns3.com documentation and the youtube videos that use VMware Workstation VMs as GNS3 VMware VMs, that is not my responsibility.
Nor is the "Use as a linked base VM" (experimental) anything that I am concerned with.

Presently, I view the whole GNS3 VMware integration a completely illegal design technique (from a freshman level of college student course) and I strongly suspect I can find a published book where the author says do not do what is being done by breaking encapsulation.

I recommend withdrawing support, in totality, GNS3 VMware VMs.

[eantowne]

For the most part, I expect this will not really be an issue due to the local server on windows and OS X will be going away in GNS3 3.0. The ability to integrate a VMware WS/Virtualbox VM into a GNS3 projects topology is tied to the local server capability currently, according to my understanding. This conceivably could be an issue still on Linux host systems. Without a local server to manage ubridge and make the api calls to vmrun there is not really a way to integrate external VM’s. I know this is an issue for some people, however, I think the dev teams time is better spent on 3.0.

On Tue, Sep 6, 2022 at 08:31 josephhiggins ***@***.***> wrote: up route add 172.16.0.0/16 via 172.16.0.1 dev eth0 up route add 10.0.0.0/8 via 172.16.0.1 dev eth0 sudo route add -net 10.0.0.0/8 via 172.16.0.1 dev eth0 sudo route add -net 10.0.0.0/8 via 172.16.0.1 eth0 post-up cat /etc/debian_version post-up route add -net 10.0.0.0 netmask 255.0.0.0 gw 172.16.0.1 2.0.0rc3 31/03/2017 @grossmj <https://github.com/grossmj> I recommend this request should *not* be supported because: 1. I do not believe there are any publicly documented api information published by vmware for vnetlib64. Although, I have seen the hack a vmware community user posted, circa 2009. 2. reading VMware's .vmx file is at best a sketchy, borderline, design technique. There is no: vmrun -T WS GetNetworkAdapterSchema thevmxfile.vmx 3. The gns3 cloud implementation, circa 2.0.0rc3 31/03/2017, post-dates gns3's integration with vmware, circa ## 1.4.0alpha1 09/07/2015 I can not find Julien's guidelines for people who want to contribute GNS3 development. But, I have read Contributing.md I just spent 12 hours over 10 days helping out Francisco with this kookiness. VMware Workstation VMs should be not in GNS3land and not under GNS3 developer responsibility, nor manipulation. VMware Workstation VMs should be accessed via the GNS3 Cloud. As far as not being able to export a project with VMware Workstation VMs, I do not consider VMware Workstation VMs to be part of a single GNS3 project. The VMware user must export their own VMware VMs and pair them with an exported GNS3 project on their own. Only certain VMs can be promoted from a Qemu VM to a VMware VM. As far as the gns3.com documentation and the youtube videos that use VMware Workstation VMs as GNS3 VMware VMs, that is not my responsibility. Nor is the "Use as a linked base VM" (experimental) anything that I am concerned with. Presently, I view the whole GNS3 VMware integration a completely illegal design technique (from a freshman level of college student course) and I strongly suspect I can find a published book where the author says do not do what is being done by breaking encapsulation. I recommend withdrawing support, in totality, GNS3 VMware VMs. — Reply to this email directly, view it on GitHub <#2109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APZX5IYBICVSK2MWFAN7LPLV442TFANCNFSM6AAAAAAQCJZ7B4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Ean L. Towne ***@***.***

[josephmhiggins]

@ean,
Point well taken.
I do not know what the gns3 developers are doing with 3.0
And I do not want to load any kind of 3.0 alpha or beta versions.
So, I wait for 3.0

[cristian-ciobanu]

Other emulation products on the market like EVE-NG, Cisco CML are only focused on Qemu/KVM integration which offers great support for linked clones VMs. As now the linked clones VM support for VirtualBox and VMWare in GNS3 is stated as experimental.

Also the in GNS3 registry most of the appliances are provided in qcow2 format with only few using vmdk disks for which Qemu has good support ( they can be easily converted to qcow2).

VirtualBox and VMWare are good for small topologies using individual VMs (Linux, Windows etc) and not recommended to large topologies which involve dozens of networking devices like routers, switches etc.

In my opinion maintaining support for these platforms delays the development of other useful features which GNS3 can offer due to bugs and support required by users.

[papparpi]

I am very happy that @grossmj has added this as a 2.2.35 milestone.

May I just say that while I appreciate the diversity of opinion that has stemmed from my original request and I enjoy the plethora of suggestions as to what course GNS3 should steer as regards this topic, I would also love to hear what the the GNS developer team have got to say about this...

Personally, I have always thought that what sets GNS3 apart from EVE-NG and Cisco CML crowd (these are mentioned in the previous post) is that GNS3 has dared to go where there virtualisation platforms dare not (vmware and virtual box integration, to name but a few).
I would be very sorry, indeed, to see GNS3 become just like 'other emulation products on the market' - to quote the previous post.

[grossmj]

It should be possible to tell GNS3 to only use a range of vmnet interfaces. Please try to edit %APPDATA%\GNS3\2.2\gns3_server.ini and add the following at the end the file:

[VMware]
vmnet_start_range = 10
vmnet_end_range = 19

Please let me know if this solution solves your issue.

[grossmj]

@papparpi have you tried my solution?

[papparpi]

Hi Jeremy,
will re-install GNS3 and try.