Win10 with GNS3 with FGT VMs, but which type of FGT VM?

[MartScho]

We want to set up an SD-WAN / ADVPN / etc. lab in Azure. Base should be a Win10 Pro VM in Azure. On this machine GNS3 would be installed.
Inside GNS3 we want to set up some FGT VMs to simulate SD-WAN, ADVPN, etc.

We want to do it this way to have a network/routing behaviour like in the 'real' world, not the type of cloud networking/routing.
(Of course we would love to run this on hardware, but we do not have the necessary hardware lab equipment available.)

In the scenario described above, which type of FGT VM should we use? KVM, like in the real world, or something else?
Any help or ideas appreciated.

[MartScho]

It seems I have found the information that I needed.
Microsoft Azure Lab descriptions pointed directly to a GNS3 documentation page covering the GNS3 marketplace: https://docs.gns3.com/docs/using-gns3/beginners/install-from-marketplace/

In the GNS3 marketplace there are only KVM images available, covering also FortiGate and FortiManager.
This is what I had in mind, as KVM is the VM image type which is needed in 'standard' GNS3 environments, but things could have been different when implementing this scenario in Azure.
I plan to leave this thread open, until I have found some time to implement this lab. This could take some days or two weeks...
Please feel free to post any additional information, if you have experience or ideas on this.
Thanks.

[JoerVan]

Hi,

The Azure Labs documentation is very good. You will be using nested virtualization. Your GNS3 will run as a VM on Hyper-V in Windows and in that VM you will be running your FortiGate and FortiManager based on KVM. You will need to verify that your instance type in Azure support nested virtualization.

Regards,

Joeri

[MartScho]

Although I knew this already, thanks for the hint, Joeri
Might be helpful for others, too.

Regards, Martin

[MartScho]

Hi,
finally I had some time to set this up.

Everything seems to be running fine. GNS3 is set as server up in Hyper-V, the client part runs directly on the Win10 VM.

I have access to the FGT consoles of the different FGT VMs in GNS3.

What I am missing right now, is HTTP access to the FGTs.

I would like to access the FGT GUI from a browser running on my Win10 VM. So I have to cross Hyper-V and GNS3 to get to the FT GUI.

Currently only the Network adapter 'default switch' is configured for the GNS3 VM. This one gets different IP addresses via DHCP each time the system is started.

The FGTs in GNS3 are connected to the GNS3 cloud item, which should connect them to the outside world.

By now I can not access the FT VMs from the Win10VM, neither via HTTP, nor via Ping.

Would I have to set up a second virtual switch for the GNS3 VM in Hyper-V, and how would I have to configure the FGT interfaces?

Any hint appreciated.

Martin

[JohnTanoh]

Hi, 

• To allow your GNS3 VM to access the outside (and vice versa), it is often necessary to create a second virtual switch in Hyper-V
• Make sure GNS3 uses the new virtual switch you created in Hyper-V.

• Connect the Cloud element in GNS3 to this new virtual switch. This will allow the FortiGate (FGT) to access the internet and be accessible from your Windows 10 machine.

[MartScho]

Hi John,

thx for your quick answer (-:

>Make sure GNS3 uses the new virtual switch you created in Hyper-V.

From what I have read earlier, an 'internal' or an 'external' switch could be used for that.

If I create an 'external' switch, I have to select a network adapter. The only one available is 'Microsoft Hyper-V Network Adapter'. Would that one be fine? I would guess this one is already in use for the 'default switch'.

Or would an 'internal' switch be the right choice?

Regards, Martin

[JohnTanoh]

To enable your GNS3 VM to access external networks and ensure proper communication, you need to use External Switch.

• The "Microsoft Hyper-V Network Adapter" you see is typically a virtual adapter used by Hyper-V itself, not a physical one. To create an external switch, you should select the physical network adapter that your host machine uses to connect to your local network (like your Ethernet or Wi-Fi adapter).
• Also, the default switch in Hyper-V is a lightweight virtual switch that primarily provides simple connectivity for VMs. For your setup, creating a dedicated external switch is preferred.

[MartScho]

Hi John,

an 'external' switch would be fine for me.

As my Win10 VM is running on Azure, there are no real 'physical' network adapters available. I have the adapter that came from the Azure vnet. It shows up as 'Microsoft Hyper-V Network Adapter' und Windows 'Network Connections' and carries the IP address 10.0.0.4 which is quite common in Azure.

The network adapter that is in use for the default switch is shown as 'Hyper-V Virtual Network Adapter', so it is quite different from the one which was delivered by Azure. I could use the first one (10.0.0.4).

Alternatively I have set up a Loopback Adapter 'Microsoft KM-Test Loopback Adapter' with an IP address 192.168.0.1/24. Would that be a better choice?

Nevertheless, I have figured out one big issue in my Lab. I had a standard GNS3 switch installed between the FGTs and the GNS3 cloud item.

All devices are located on the GNS3 VM, besides that switch, which is installed on the Win10 VM.

I will fix this, before I get back to the Hyper-V switches.

Maybe that would solve some of my issues.

I will get back to this discussion when I have fixed the switch topic.

Many thanks by now, Martin