Using pfSense for a VMware home lab: Part 2

Overview

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 192.168.20.1.  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.

2016-02-13_10-23-17.jpg

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

2016-02-13_10-24-15.jpg

The VLAN should look like this:

2016-02-13_10-24-40.jpg

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

2016-02-13_10-26-24.jpg

2016-02-13_10-26-52.jpg

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.

2016-02-13_10-52-51.jpg

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

2016-02-13_10-42-14.jpg

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.

2016-02-13_10-42-37.jpg

2016-02-13_10-43-12.jpg

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

2016-02-13_10-44-19.jpg

Interface assignments should look like this:

2016-02-13_10-46-04.jpg

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:

2016-02-13_10-56-41.jpg

Set the action to Pass and the protocol to any:

2016-02-13_10-57-47.jpg

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

2016-02-13_10-58-27.jpg

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:

2016-02-13_10-21-51.jpg

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

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

2016-02-13_11-02-41.png

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 192.168.20.1

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

ip route delete default via 192.168.3.1

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

2016-02-13_11-09-18.jpg

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

2016-02-13_11-16-49.jpg

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 192.168.20.100 and tries to ping 192.168.1.1. When the request gets to 192.168.1.1, the request may be seen as coming from 192.168.20.100, which may be okay but 192.168.1.1 needs to know how to send the request back to 192.168.20.100. If it doesn’t have a route back to the 192.168.20.0/24 network, the request will fail.

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

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

add 192.168.20.0 mask 255.255.255.0 192.168.1.130

This says that if you need to reach anything on the 192.168.20.0/24 network, talk to 192.168.1.130 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 192.168.20.0/24 and 192.168.21.0/24 networks:

2016-03-28_9-50-27.jpg

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

2016-03-28_10-26-33.jpg

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

Conclusion

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
2.22.0

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
3.2.0

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 |