Pfsense Gns3

Posted : admin On 1/26/2022
GNS3 provides a GNS3 VM for ESXi. It has Ubuntu preinstalled with GNS3 and preconfigured. GNS3 will not control your ESXi and by default ESXi limit what GNS3 can do, you will need to configure ESXi in order to properly run the GNS3 VM.3 VM.
Before using GNS3 on ESXi you need to know how to use it locally.
*ESXi Version 6.5 only can use web interface.The GNS3 VM is known to work with ESXi 5.5 and 6.0 but configuration interface will be different.
Note: VMware fixed the bug related to GNS3 after the official release of 6.5 so make sure to apply all updates.Especially you need to have the last web interface you installed.
*Download the GNS3 VM
- Be careful to doenload the ESXi version for VMware and not the Workstation or VirtualBox Version.
* Import the VM : open the web interface and create new VM. Choose 'Deploy a virtual machine from an OVF or OVA file'.
*Enter the name and upload the .ova of the GNS3 or if your OS unzip the OVA when extract the zip all the files.
*Select the datastore of your choice and continue.At the end of wizard wait for disk upload.
After booting the VM you will see that KVM is not available
This prevent fast Qemu VM; in order to solve that we need to allow the nested virtualization.
GMS3 versions: 2.1.11
VM Version: 0.10.14
KVM support available: False
IP: 192.168.129
Stop the VM and edit the settings. You need to check expose hardware assisted virtualization:
Previous Version of ESXi If you want do expose nested version on previous version. You need to edit the .vmx file and change the settings inside:
hypervisor.cupid.v0 = 'False'
By default VMware for security reason will block forged packets, which means the cloud will not work. To fix that create a new port group and accept everything. Edit the VM stettings to use the new network.
Use it as a central server. With these methid you can share a GNS3 instance with multiple clients. All the settings, images , projects will be stored on the GNS3 VM in ESXi. It's a common way to deploy GNS3 for multiple users.
*If you want to keep data local and run some workload on your computer you can use it as remote compute node. First add the node in the remote server. Apply the settings. After that you need to alias the GNS3 VM as your remote server.
Note: Why alias the remote server as the GMS3 VM? This allow portability, if you move the project to another computer the GNS3 VM alias could be an instance of VMware Workstation, Virtualbox or a cloud server.
*Note: Default port of GNS3 VM is 80.
Acces to the GNS3 Vm via internet.

Welcome back to this series, in which we discuss and configure the various features of pfSense. In the previous article, we set up VLANs on pfSense so that we could use pfSense for inter-VLAN routing. In that article, we also touched a bit on firewall rules. In this article, we will take a deeper look at configuring firewall rules on pfSense.

OPNsense started as a fork of pfSense® and m0n0wall in 2014, with its first official release in January 2015. The project has evolved very quickly while still retaining familiar aspects of both m0n0wall and pfSense. A strong focus on security and code quality drives the development of the project. An unexpected error has occurred. Error Message: Unexpected end of JSON input Report Feedback Return to Home page.

The blog is for the new GNS3 VM (Virtual Machine) users on Windows 7/8/10. It’s a graphical network simulator that allows you to design complex network topologies, where you can run different devices (irrespective of vendors) like cisco, juniper, chCheckpointFortinet, PFSense etc. PfSense is an open source routing and firewall software that is based on the FreeBSD distribution. The basic features including: pfSense Home Topology Static/default/dynamic routing Stateful firewall Network Address Translation (NAT) Virtual Private Networks (VPN) Dynamic Host Configuration Protocol (DHCP) Domain Name System (DNS) Load balancing and so on. With many supported add-on packages. Playlists:

Firewall Rules

Among the most important features you will configure on a firewall are the firewall rules (obviously). When you install pfSense, all connections from the LAN are automatically permitted by default. However, all connections from the WAN are denied. We can view/configure firewall rules by navigating to Firewall > Rules:

Hint: In that article, we also saw that there are no firewall rules defined by default for new OPT interfaces. This means that any traffic seen on those interfaces will be denied, even traffic destined to pfSense itself!

Except for rules defined under the Floating tab, firewall rules process traffic in the inbound direction only, from top to bottom, and the process stops when a match is found. This is similar to how a Cisco router processes access lists, so one should be careful to put more specific rules at the top so that they are matched before generic rules.


Let’s configure a sample security policy as follows:

  • Any traffic from the LAN to any destination should be allowed.
  • Allow SSH/HTTPS only from hosts and in the DMZ to the LAN network.
  • Allow DNS, HTTP, and HTTPS from the DMZ to the Internet.

Note: Because I’m trunking the VMware interface used for both LAN and DMZ, I may not be able to access the webGUI from the host PC anymore via the LAN IP address. Therefore, I will leave the rule for WAN access open. Keep in mind that, if you are using DHCP, the host PC’s IP address may change from the one you configured in the firewall rule and you won’t be able to access the webGUI anymore (depending on how strict your rule was).

Policy #1: Permit all traffic from LAN

As we have seen above, all traffic (IPv4 and IPv6) from the LAN is permitted by default. Therefore, we don’t need to do anything extra to configure this security policy.

Policy #2: Permit ICMP from DMZ

In the last article, we configured a firewall rule that allows ICMP from the DMZ to any destination, as shown below:

Let’s leave this rule configured but, by walking through the steps of configuring firewall rules for policy #3 and #4, you can understand how this rule was configured.

Policy #3: Permit SSH/HTTPS from and to LAN

I decided to include this policy here so that we could see another feature available in pfSense – Aliases. This feature is similar to object groups on the Cisco IOS, where we group similar objects together to make configuration simpler. With aliases, instead of specifying the individual objects, you just specify the alias name.

Therefore, let’s configure two aliases: one for SSH and HTTPS and the second one for the hosts and To do this, we will navigate to Firewall > Aliases:

As you can see, we can create aliases for IP, Ports, and URLs. We will start with the one for IP and then move to the one for ports.

When you are done with your configuration, apply your changes and we can move on to creating the firewall rule itself. We will navigate to Firewall > Rules and then select the DMZ tab. The settings for my own rule are shown below:

As you may have noticed when creating the port aliases, you don’t specify the protocol. It is when we are creating the firewall rule that we specify the protocol, as shown above. Also notice how we specified the source as the alias we created—once you start typing the name, aliases that match that name show up. We also used the alias we created for the ports under the Destination port range field. Finally, there are some default names such as LAN address (i.e., LAN interface IP address of pfSense) and LAN net (i.e., LAN network and other static routes configured on that interface) that we can use when configuring rules. These make your life easier because, if an address/network changes, you won’t have to alter the rule as the rule will be automatically updated to match the new address(es).

Policy #4: Allow DNS, HTTP, and HTTPS from DMZ to Internet

There are several ways you can configure this rule, depending on how restrictive you want your rule to be. DNS (not zone transfers) uses UDP port 53 by default, while HTTP and HTTPS use TCP port 80 and 443, respectively. If you create a port alias matching the three protocols, you will have to use “TCP/UDP” in the Protocol field of the firewall rule. This means that TCP/UDP ports 53, 80 and 443 will be allowed which is more than you want.

Let’s practice the principle of least privilege and be as restrictive as possible. We will create a port alias for HTTP and HTTPS and then create a standalone rule for DNS.

If you were able to identify a gap in this our configuration, I salute your observation skills. Because firewall rules apply to traffic coming into an interface and since we didn’t specify a destination network, it means this last rule we just created also allows hosts on the DMZ to open DNS, HTTP, and HTTPS connections to the LAN!

To remedy this situation, we need to add a rule that blocks traffic from the DMZ network to the LAN and place this rule between Policy #3 and Policy #4.

First, let’s create the rule: by default, new rules are added at the bottom.

To move the rule to the correct position, we will select the checkbox in front of the rule and click the “Move selected rules before this rule” button for the rule which we want the selected rules to precede (highlighted above):

With this, we have come to the end of our rules definition. The last policy says that everything else should be denied, but that is already implicit in the rules table (just like a Cisco ACL). Explicitly defining a “deny all” rule is useful when you want to log such traffic.

Pfsense Vm

It is always advisable to test your firewall rules to make sure you have not accidentally permitted traffic that should be blocked or denied traffic that should be allowed. In our case, we may want to add some smarter devices (than VPCS) onto the LAN and DMZ that will allow us open SSH and HTTPS connections. Therefore, our GNS3 topology now looks like this:

Note: I have basic IP configuration on the routers. I have also enabled SSH on the LAN-RTR. Both routers are configured to use pfSense as their DNS server.

Pfsense download vm

Pfsense Gns3 Qemu

Pfsense Gns3

Let’s begin our test by checking that the LAN-RTR can ping an Internet URL (i.e., DNS and ICMP):

Next we will ping from a DMZ host to the LAN since ICMP from the DMZ is allowed to any destination (policy #2):

To test the third policy, I will open an SSH connection from the DMZ-RTR to the LAN-RTR:

For the fourth policy, I can ping from the DMZ-RTR to an Internet URL. Since this will involve DNS, we can confirm that our fourth policy works:

Just to confirm that our deny rule works (the one denying DMZ from accessing the LAN), I will change the IP address of the DMZ-RTR from to and try to open SSH to LAN-RTR again. As shown below, it won’t work:

Although the webGUI doesn’t (yet) provide a way to check the counters on firewall rules, we can use the following command through the Shell: pfctl -vvsr:

Note: To access the Shell, enter option 8 at the console of pfSense or via the terminal when connected via SSH.


This brings us to the end of this article, in which we have configured firewall rules on pfSense. I hope you have found this article insightful and I look forward to writing the next one in the series.


  • Firewall rule basics:
  • Firewall rules hit counter:
  • Firewall rule processing order: