Using pfSense for a VMware home lab: Part 2


This post is a continuation of part 1 where we installed and performed the initial setup of pfSense for use in a VMware home lab. In this post we will finish up by creating VLANs, firewall rules, NAT and verify connectivity.

VLAN Creation

In the first post we configured the LAN interface (em0) with an IP address of  Now we will create VLANs 20 & 21, create an additional interface on em0 and assign the VLANs.

Select Interfaces > Assign > VLANs and select the plus sign.


Make sure the parent interface is set to em0, set the VLAN tag to 20, provide a description and save:


The VLAN should look like this:


Select Interfaces > Assign > Interface assignments and set WAN to VLAN 20.



Select the WAN link under Interfaces and perform the following

  1. Enable the interface.
  2. Fill in the description.
  3. Change the IPv4 Configuration Type to Static IPv4.
  4. Verify the IP address.
  5. Uncheck to block private networks.
  6. Select Save.
  7. Select Apply changes.


Interfaces > Assign > Interface assignments should now look like this:


Now we will create VLAN 21.  It’s a little bit different from VLAN 20 because we will be creating a new interface that lives on em0.  You can think of this as a sub interface.  For each new VLAN you want to create, you will create a new sub interface on em0 and assign the VLAN to it.  You can create additional em# devices by adding additional NICs to the VM in vCenter.

Select Interfaces > Assign > VLANs and select the plus sign and create VLAN 21 on em0.

Select Interfaces > Assign > Interface assignments

  1. Change the Available network ports drop-down box to VLAN21.
  2. Press the add button.



Select the OPT1 link under interfaces to configure it.

  1. Enable the interface.
  2. Provide a description.
  3. Change the IPv4 Configuration Type to Static IPv4.
  4. Set the IP of the interface.  This will be the gateway off all of the VMs that connect to this network.
  5. Select Save.
  6. Apply changes


Interface assignments should look like this:


Firewall Rules

We need to establish some firewall rules in order for traffic to be allowed. For this demonstration I’ll just create a rule that allows all traffic, but you can modify the rule set as you see fit. If I’m working on an issue where I suspect a firewall is preventing functionality, I’ll jump into my lab, add a firewall rule to block specific traffic, verify functionality then back out the firewall change and verify again. Let’s work on VLAN20 first:

Go to Firewall > Rules > VLAN20:


Set the action to Pass and the protocol to any:


Save and apply changes. The firewall rules should look like this and all traffic will be allowed:


Do the same for VLAN21.

 Testing Connectivity

To test that everything is working correctly I created a VM and placed it on the vlan20-blog portgroup:


Once the VM is up and running we can do the following:

  1. Set a valid IP address on VLAN 20 (
  2. Verify the IP
  3. Ping the gateway, which is an interface on our pfSense VM:


You can then spin up another VM on VLAN 21 and verify connectivity between the two VMs. The VMs should be able to communicate within your network regardless of which ESXi host they are on. If they aren’t, one thing you want to make sure is that the switches that your ESXi hosts are on are trunking our VLANs (20-25).

If you need to add the default gateway, run:

ip route add default via

If you need to remove a previous default gateway, run:

ip route delete default via

My ESXi hosts are connected to a Cisco SG-300-10. Here is how I created the VLANs on it.

Go to VLAN Management > Create VLAN  and enter:

  • VLAN ID: 20
  • VLAN Name: vlan20-blog


Go to VLAN Management > Port to VLAN  and:

  • Change VLAN ID equals to to 20 and press Go.
  • Change each port that your ESXi hosts are connected to Tagged
  • Press Apply


Do the same thing for VLAN 21.

Static routes and NAT

At this point your VMs should be able to communicate within your network. However, let’s say our VM has the IP address of and tries to ping When the request gets to, the request may be seen as coming from, which may be okay but needs to know how to send the request back to If it doesn’t have a route back to the network, the request will fail.

We can either add a static route so that will know how to reach VMs on the network or create NAT rules so that requests coming from the network will look like they are coming from the pfSense device ( and since this is the same network as, it will be able to communicate with it.

On Windows, here is how we would add a static route to the network via the pfSense device:

add mask

This says that if you need to reach anything on the network, talk to and it will take care of it.

Let’s go to Firewall > NAT > Outbound and look at our NAT rules.

This section looks different than what I’m used to because I’m running and older version of pfSense.

We see that the NAT mode is set to automatic and in the automatic rules we see that there are rules in place for our and networks:


If I ping a VM with the IP of on my local network from my VM and view the traffic with tcpdump, I see:


Here we see that the request is coming from, which is our pfSense device so we know the automatic NAT rules above are working.


If you look around the pfSense interface, you’ll see a lot of features that could be useful in a lab environment. It’s certainly been useful for me throughout the years. While I’m not a networking expert and didn’t intend to thoroughly cover things like firewall rules and NAT, if you have any questions, let me know and I’ll try to help.


Listing all key pairs in OpenStack

I’m pretty to new OpenStack, but I’ve noticed that pre-Liberty if you wanted to list all key pairs for a user, you needed to be logged in as that user. If this isn’t correct, please let me know. We are working on a project at work where I needed to retrieve key pairs for specific users while acting as an admin user.  In this post I’ll show how to do just that. All commands are ran as an admin user.

In my Kilo lab my nova client is version 2.22.0

nova –version

Displaying help for the keypair-list command results in:

nova help keypair-list
usage: nova keypair-list

Print a list of keypairs for a user

Note that there are no options available for specifying other users, tenants/projects, etc so it only acts on the user who is running the command.

I then found the following bug report: keypair-list should allow you to specify a user or all-users. To test this out I installed a DevStack instance of Liberty. Let’s see what version of the nova client is in provided:

nova –version

Now for the options:

nova help keypair-list
usage: nova keypair-list [–user <user-id>]

Print a list of keypairs for a user (Supported by API versions ‘2.0’ –
‘2.latest’) [hint: use ‘–os-compute-api-version’ flag to show help message
for proper version]

Optional arguments:
–user <user-id>  List key-pairs of specified user ID (Admin only).

Notice the new –user argument.

Let’s see if we can view the key pairs of the demo user. First we will get the demo user’s ID since the nova –user argument specifies that it only accepts an ID:

openstack user list 
| ID                               | Name     |
| 0f170c032ff74a1f9e5548c16bd76dcc | nova     |
| 2848a301af4e4b6faec536102b3d292b | glance   |
| 290e7f84f951426a9c5d63fa67aa506d | admin    |
| 5d1a93152efb4b00af59b3620bfd8cc3 | alt_demo |
| 6fc465ae0e944dc3b08eb661c43ba922 | demo     |
| d961ddcad066415f96a44fa8c7349166 | cinder   |
nova keypair-list --user 6fc465ae0e944dc3b08eb661c43ba922
| Name | Type | Fingerprint                                     |
| demo | ssh  | 8d:e2:65:ec:8c:91:52:bb:40:22:55:2e:9b:1f:f0:45 |

I’d probably do it differently, but for something quick, if you want to list all users/key pairs, you could do something like this.

for user in $(openstack user list -f value -c ID); do nova keypair-list –user ${user} | grep -P “\|\s(([a-f0-9]{2}:)?){15}[a-f0-9]{2}\s\|$”; done

| admin | ssh  | 2e:93:fd:9b:45:30:e1:47:fe:93:4e:4a:21:74:40:d0 |
| demo | ssh  | 8d:e2:65:ec:8c:91:52:bb:40:22:55:2e:9b:1f:f0:45 |