Screen Shot 2013-11-26 at 09.30.29

UPDATE: I was recently contacted by the folks at pfsense.org – who have a new updated and detailed guide on using pfsene – I recommend you check it out as this content is getting a bit dated:

Their team also put together a very detailed guide about VPN routers, including tips for setting up. I believe their guide is more thorough and can bring more value to your audiences. You can check it out here:

https://www.softwarehow.com/best-vpn-router/

 

This week I had a need to check out the pfSense Firewall with BareMetalCloud/AutoLab.

First, some backstory – one thing I’m offering to do with the regular VMUGs I visit is to deliver some informal/workshop style “training” at the events. I have this idea that VMUGs should have a strong educational content, and what could be better than delivering education around VMware products at a VMware User Group? For the moment I’m starting with a “Back to Basic” vSphere session – really geared up for folks who are relatively new the platform. Remember that about 60% of the folks who attend a VMUG are from an SMB background, and many have never received any instruction at all. It’s so difficult for people to convince management to pay for training for VCP after all. So often people are left to work things out for themselves via blogs, books and online video training.

In fairness it doesn’t work for every VMUG. Mainly, because to do anything meaningful/worthwhile you need quite a chunk of time, and I wouldn’t want my efforts to “undermine” the main VMUG event. Where it works is where a VMUG generally meets from Noon-til-5pm. But still have access to the venue for the full day. This used to be the case at the London VMUG group until the move to a fully-day, multi-track event. The first one of these sessions I’m doing is for the North-West VMUG in Manchester next week. So its a bit of an experiment, and I decided to use BareMetalCloud/AutoLab to spin up an environment. The great thing about it is you can save your configuration to a file – that means when I come back to part 2 I will just have to restore the lab environment to the state it was when we left off.

In my case I wanted to able to RDP to a VM in the BareMetalCloud/AutoLab as well as giving my VMs secure outbound access. There is a FreeSCO “NAT/Router” in AutoLab already but I wanted something equally slim and offering a bit more functionality. It was the folks at BareMetalCloud who put me on to the pfSense Firewall.

So before you look at pfSense its worth mentioning that AutoLab’s own Lab_Router could be reconfigured to support both outbound and inbound access to the VMs. In the BareMetalCloud version of AutoLab the external interface is configured with an internal 10.x.x.x address. If you want to allow an outbound/inbound access this IP address needs to be modified to use one of your 5 external internet IP addresses.

1. Open a remote console to Lab_Router

2. Login as root with a password of VMware1!

3. Type: setup

4. Type C to continue in Colour Mode

5. Type C to manage Advanced Settings

6. Type H to manage Local Networks

7. Type 0 to manage eth0

Screen Shot 2013-11-27 at 10.51.53

8. Type B to set one of your external IP addresses

Screen Shot 2013-11-27 at 10.53.33

9. Type C to set the Subnet Mask  in my case 255.255.255.248

10. Type L to set the Default Gateway address (TIP: You can find this on the physical hosts “DNS & Routing” Settings

12. Finally, turn of the DHCP components with H and No, and i and No

Note: At the end of the configuration your setup should look something like this:

Screen Shot 2013-11-27 at 11.18.18

11. Select X to exit the Local Network

12. Select X to exit Advanced Settings

13. Select S to Save and Exit

14. Type reboot to restart the Lab_Router, and ensure your settings have taken effect

You should be able to connect out to the internet – and RDP to the vCenter using the public IP address – you can also connect to the Domain Controller using the public IP address on 3388.

So the configuration of the built-in Lab_Router is pretty painless – but you might want something with a bit more functionality – that’s what made me look at the pfSense Appliance…

Virtual Machine Configuration:

There’s is a virtual appliance of pfsense but they have discontinued the process of updating it – they now recommend just downloading the .ISO.GZ file and installing. Start by downloading the .GZ file, and then extracting it. I used the 7-zip File Manager which is already installed to the dc.lab.local VM. Then I used the vSphere Client datastore browser to upload the .ISO image into the BareMetalCloud/AutoLab host. Next, I powered of the default Lab_Router (this is the one that uses the FreeSCO NAT/Router), and created a new VM for the pfSense firewall. I created a VM with these attributes:

  • Custom
  • VM8
  • Other/FreeBSD (64-bit)
  • 1x vCPU
  • 512 MB RAM
  • 2x NICs (e1000) with NIC1 being patched to “LAB_Local” and NIC2 being patched to “VM Network” – These will be recognised as EM0 and EM1 respectively by pfSense. EM0 will be local ethernet connection, and EM1 will be regarded as our “WAN” ethernet connection
  • LSiLogic Parallel
  • New Virtual Disk of 8GB in size (It actually requires much less, but heck its thinly provisioned and what is 8GB amongst friends?). I decided to store the pfSense VM on local storage – along with all the “infrastructure” style VMs
  • After creating the VM attach the pfSense .ISO image

First Boot/Install of the pfSense .ISO

On the first boot of the pfSense .ISO you will be asked to ID your networks. I found the “Automatic” method didn’t really work that well. I ended up specifying the VM NIC’s by hand. That isn’t too difficult.

1. Choose NO for VLAN Configuration – notice the reference to the two NICs em0/1

Screen Shot 2013-11-22 at 13.57.10

2. Next type the name of the WAN interface, in my case em1 [ENTER]

Screen Shot 2013-11-22 at 13.59.04

3. Next set the interface for the LAN connection, in our case this em0 [Enter]

Screen Shot 2013-11-22 at 14.01.02

4. Press [Enter] again to indicate you do not wish to use an optional 3rd interface.This then should ask you to confirm that you wish WAN to be em1 and LAN to be em0

Screen Shot 2013-11-22 at 14.03.18

At this point some services will start, and you will be left with a number console menu. You can type 99 to indicate you wish to install the pfSense to the virtual disk:

Screen Shot 2013-11-22 at 14.05.16

Select to accept the default settings and for Quick/Easy installation. At the end of the install you can reboot the VM, a detached the .ISO image.

Configure IP Addresses

Next we can set the IP addresses of the internal/external (LAN/WAN) interfaces of the pfSense Firewall. By default the WAN interface picks up on DHCP server (10.x) at BareMetalCloud and sets a static internal LAN address of 192.168.1.1. These need to be changed to be a public IP address for the WAN interface and 192.168.199 address for the AutoLab environment.

1. At the main menu, press 2 to Set Interface(s) IP Address

2. Type 1, to indicate the WAN interface needs to be changed

3. Choose N to select not to use a DHCP address

4. Now type a valid IP address for the BareMetalCloud WAN network. When you signed up for an AutoLab on BareMetalCloud you will have provisioned a physical host with an IP address valid for the internet. For example 199.x.y.131. Each BareMetalCloud/AutoLab is allocated 6 IP address – one of these is claimed by the host (131) and the second is the default gateway (136). This leaves a small of block of IP address that can be assigned to the psSense Firewall.

IMPORTANT: Always consult with support at BareMetalCloud about the right IP addresses and ranges to use. Things can and will change over time.

Screen Shot 2013-11-22 at 14.18.21

5. Next type the subnet mask in my case this was 29-bits for 255.255.255.248 subnet mask.

Screen Shot 2013-11-22 at 14.23.03

6. Next specify the Default Gateway – this should be the SAME default gateway used by the physical BareMetalCloud/AutoLab host

Screen Shot 2013-11-22 at 14.25.20

From here you can choose N to supporting DHCP/IPv6. This should make the “WAN” portion of the network statically configured turning off the DHCP Client. Choose Yes to “revert to HTTP as the webConfigurator protocol, and [Enter] to continue.

Next, we need to repeat this configuration for the LAN interface. Setting the LAN address to be 192.168.199.2 address using 24-bit for the subnet mask (255.255.255.0). This is formally the IP address of the LAB_Router. The DHCP scopes provided by AutoLab default to this as the default gateway for all the instances in the lab itself. There’s is no need to set a default gateway on the LAN interface as it will be the gateway/firewall for all the AutoLab VMs.

Screen-Shot-2013-11-22-at-14.30.05

At the end of this process the LAN/WAN interface should be correctly configured – and the remained of the post-configuration can be carried using the WebConfigurator. The main admin portal for pfSense.

Screen Shot 2013-11-22 at 14.33.58

Configuring RDP Access to vCenter in BareMetalCloud/AutoLab

Next we are going to carry out the post-configuration steps required to make our VC in the BareMetalCloud/AutoLab accessible from the internet. Whilst the access is by the vSphere Client is incredibly quick, you maybe limited by the local bandwidth where you are located. You might find RDP into a Windows VM is more user friendly.

IMPORTANT:

Of course allowing direct RDP access to vCenter can hardly be regarded as “secure” but this is just a lab environment. You might prefer to setup a dedicate “jumpbox” VM running say Windows7 and then use it to gain access to the reset of the lab. Remember the “Administrator” account for the AutoLab is well-known and its available in publicly downloadable PDF guides! So… you might find a domain-less client box with no access to the domain is more secure option… Additionally, you might want to confirm you can RDP into your target VM locally using either the VC/DC VMs before attempting remote inbound connections – to valid RDP has been enabled and that theirs no firewall blocking the ports.

1. From either the DC or VC desktop, open a web-browser to http://192.168.199.2

2. Login as the user: admin with the password: pfsense

Screen Shot 2013-11-22 at 14.40.39

3. Set the preferred DNS Server, in my case I used 8.8.8.8 which is Google Open DNS service

Screen Shot 2013-11-22 at 14.42.49

4. Accept the default NTP/TimeZone settings

5. In the “Configure WAN Interface” confirm your settings – I found my Default Gateway that had been set earlier wasn’t present. So I re-inputted the value.

Screen Shot 2013-11-22 at 14.45.49

6. Accept the settings for the LAN configuration on the subsequent page

7. FInally, set a new password for the admin password for the WebConfiguration Portal.

Note: From this point any VM on the BareMetalCloud/AutoLab configured for the 192.168.199.2 gateway should have access tot he internet. You can confirm this by using nslookup www.vmware.com, and tracert www.vmware.com – both should result in successful outcomes.

Screen Shot 2013-11-22 at 14.50.56

8. Now we know communication is work outbound, we can configure an inbound NAT translation to allow MS-RDP access to the vc.lab.local VM. In the WebConfigurator Portal.

9. Under Firewall and NAT – in the Port Forward tab click the small + icon to add a rule

Screen Shot 2013-11-22 at 14.54.52

10. Under the “Destination Port Range” select MS RDP for both From: and To:

11. Under “Redirect Target IP” type in the IP address you wish to connect to, in my case 192.168.199.5

12. Under “Redirect Target Port” select MS-RDP… In this case the 192.168.199.5 node is listening on the default port number of 3389 for RDP

13. Under Description – type something meaningful

Screen Shot 2013-11-22 at 15.08.49

14. Click Save & Apply Changes

At this point you should be able to MS-RDP to the public IP address assigned to the pfSense Firewall. To make my own life easier I edit my hosts file to put in the IP address of both the esx.baremetalcloud.com and vc.baremetalcloud.com so I don’t expose IP addresses in screen grabs and so on.

Of course, it is possible for pfSense to re-map TCP ports as well – so PAT and NAT are supported.