November 15th, 2024
A core component of our lab will be our Netgate appliance running pfSense. Netgate is the official sponsor of the pfSense open-source project, so why not use their hardware?
Well, you could save some money by running pfSnense on a dedicated and less expensive (but not purpose-built) piece of hardware. This might be a good middle ground if your keeping a close eye on your budget, but want extra ethernet interfaces.
You could save even more by running pfSense in a VM on your server, but part of the home lab experience is working with hardware. Plus, those extra interfaces on the Netgate appliance I'm suggesting (i.e., the Netgate 4200) will come in handy as your lab grows.
Whatver you decide, it's important to know that our Netgate appliance is more than just a firewall. We'll be using it for Dynamic DNS to host our website as well as for local routing, DNS resolution, Network Address Translation, and so much more as our use cases grow (NTP, DHCP, etc.).
This lab guide assumes that you've reviewed Netgate's "Getting Started" guide for the 4200 appliance and that you're able to access the adminstrative web interface. Once we're logged in using the default credentials of "admin" for the username and "pfsense" for the password, the first change to make to our Netgate (pfSense) firewall is to change the default administrator password to something more complex.
I suggest using setting a much longer password (twelve or more characters) consisting of upper and lower case letters as well as numbers and symbols. Follow these steps from pfSense's documentation to change the default administrator password. Once that's taken care of, we'll start configuring our firewall to support our lab requirements.
Before we begin, it couldn't hurt to remind ourselves of what we're building by reviewing the network diagram that was shared in the "Gear Up" blog post that kicked off this series:
Now that we're ready, let's configure the Netgate appliance's physical interfaces (ports). There are only a few changes we need to make to our physical interfaces and most of these configurations will be repetitive with only a few deviations along the way.
In general, when configuring a physical interface, our first step will be to enable the interface. Next, we'll want to choose whether or not the interface will receive its IP address via Dynamic Host Configuration Protocol (DHCP) or if we will set the interface's IP address statically. For this exercise, we will always give our interfaces a static IP address. We then may or may not need to assign an upstream IPv4 gateway and that should pretty much cover it.
Port 1/4 is our WAN interface and now is the time, if you haven't already, to physically connect it to an open port on your internet modem or wireless router in order to get Internet access for anything behind our firewall. By default, Port 1/4 should be configured to receive it's IP address assignment via Dynamic Host Configuration Protocol (DHCP); however, I suggest you set a static IP address on this interface if you can.
On my Amplifi home router, I have the ability to reserve a portion of the IP addresses issued from the router's DHCP pool for static IP address assignment. In my lab, I have configured my Amplifi router to reserve 192.168.132.1 through 192.168.132.99 for static IP address assignement, leaving 192.168.132.100 through 192.168.132.254 for DHCP to use on other devices—connected either wirelessly or hardwired to the Amplifi router. If your network requirements are different, then feel free to deviate from this guide to suit your needs. I will be setting a static IP address of 192.168.132.7 for my PORT1WAN interface.
Port 2/4 is reserved for our LAN interface and should be configured out of the box with a static IP address of 192.168.1.1. For our lab purposes, this interface is our Netgate appliance's primary management interface and we will hardwire our computer to this port in order to manage our Netgate appliance. In a subsequent lab, we will configure secure remote management using Zscaler Private Access (ZPA).
Don't forget to assign your computer with a static IP address within the same subnet as the management interface (e.g., 192.168.1.2). You should know this already, though, since you've gone through the Netgate 4200 Getting Started guide and it's likely the port you're connected to right now!
Port 3/4 is reserved for our Lab network interface. Off of this interface, we will connect a small switch which we will configure with four Virtual Local Area Networks (VLANs). We will discuss the switch configuration in a separate blog post, but suffice it to say that the majority of our lab components will be connected to this switch and will be tagged to specific VLANs (e.g., Proxmox Server on VLAN 20 "Services VLAN"). We'll be setting a static IP address assignment for this interface and we'll need a new subnet. To keep things easy, we'll choose 192.168.2.0/24 for our subnet and our IP address for this interface will be 192.168.2.1. Ensure the interface is enabled and save your changes.
Port 4/4 is reserved for our Guest network interface. You'll likely want to plug your home wireless router into this port and completely isolate it from the rest of the network by ensuring, with pfSense, that no traffic is allowed to pass between the Home Network and the Lab Network. This is an optional step that is outside of the scope of this lab, but it should be simple enough to implement using the concepts you'll learn here as we build out our lab. For now, we'll leave this interface disabled.
In a later lab, we'll map our VLANs to physical interfaces on our lab's switch. Then, we'll physically connect our switch to Port 3 on our Netgate appliance and we'll configure what's called a "trunk" port. Our trunk port will include all of our VLANs and it's effectively how we get our VLAN traffic passed between our pfSense firewall and our switch. We'll use our pfSense firewall to create routing and firewall rules to allow only the appropriate communications between VLANs. These communications are considered east/west traffic (as opposed to north/south traffic to/from our LAN to/from the Internet.)
So, all traffic from our switch goes up to our pfSense firewall where policy is applied and devices connected to the switch cannot communicate to one another without passing through the pfSense firewall. That said, now is a good time to configure our VLAN interfaces within pfSense. Feel free to use the IP addressing shared below if you'd like to keep your lab consistent with this guide:
VLAN 10 - Services VLAN - Interface
VLAN 20 - Users VLAN - Interface
VLAN 30 - Storage VLAN - Interface
VLAN 40 - Management VLAN - Interface
pfSense aliases make it easier to implement our configurations. Instead of having to remember IP addresses and type out URLs, we can simply create aliases which we can later select from dropdown menus as we create policies in the administration portal. Furthermore, updating an IP address requires only one corresponding update to the firewall-the alias.Imagine how difficult managing your pfSense policies would be without aliases! That said, and in preparation for deploying our Nginx web server, we'll configure an alias for our Nginx web server. We'll use this later when configuring policies to allow. Don't forget to save your changes!
As is typical of a web server, our Nginx web server will be listening on port 80 and port 443, so we'll want to forward port 80 and port 443 to our Nginx web server. Using our new alias for our Nginx web server, we'll create a port-forwarding NAT rule to forward those ports. We'll also need to forward those ports on our home router (in my case, my Amplifi home router) so that we're not blocking those connections further up in our network. Please refer to the "Amplifi" blog post to review those steps.
Another amazing capability built in to pfSense is its ability to act as both a DNS Forwarder or DNS Resolver. Having a DNS resolver give us more control over DNS by providing the ability to serve resources using easy to remember Fully-Qualified Domain Names (FQDNs) instead of IP addresses. For example, fw.krauscloud.com vs 192.168.1.2 is pretty much a super power for our home lab purposes.
With that in mind, we want to forward all DNS traffic on all interfaces (both physical and virtual) to our loopback address in order to use our Netgate appliance for DNS resolution. Don't worry about the VLAN interfaces as we haven't configured those yet. We'll configure VLANs when we set up our switch. For now, just focus on the physical interfaces.
Once in place, these NAT port-forwarding rules will redirect all DNS (port 53) requests from local clients destined to any external IP address. Those requests will be redirected to the Netgate appliance itself and, in the next section, we will configure pfSense to either resolve those requests or forward them to another DNS provider.
As was mentioned earlier, having a DNS resolver gives us more control over DNS such as the ability to serve resources using domain names instead of IP addresses (e.g., fw.krauscloud.com vs 192.168.1.2). If you want to make life easier for yourself and your users, then having your own DNS Resolver is the way to go. We'll be specifying two “Host Overrides” which will effectively swap an IP address for a hostname. Since domain names are easier for humans to remember, this is a no-brainer.
With that in mind, you'll need to register your own domain because "krauscloud.com" is my domain. Also, feel free to choose subdomains that make sense for you. Lastly, there's no need to add all of these host overrides at once. If you don't plan on following the Zscaler Private Service Edge lab course, then there's no need to add a host override since it won't exist on your network. So, for starters, let's just add host overrides for our Netgate appliance (pfSense), our Proxmox server (the MS-01), and our web app (Next.js app).
For port 1/4, our WAN port, we want to ensure that our NAT auto-generated rule was created to forward any port 80 traffic to our Nginx server. Here, we're using an alias for our Nginx server, the details of which you can see when you hover over the alias. My alias of nginx_server is simply an alias for the IP address of my Nginx Web server (Ubuntu Desktop virtual machine).
For port 2/4, we will need four rules in place. The first rule should already be created for you and we'll call this the “Anti-Lockout Rule”. This rule helps to ensure that you do not get locked out of your pfSense firewall should you make a misconfiguration. In the event that you make a misconfiguration, you should be able to make a wired connection to port 2/4 to access the web user interface.
The second rule is to redirect DNS traffic to the firewall itself (it's loopback address) because, as was detailed in the prior step “Configure DNS Resolver”, we are using our Netgate appliance as a DNS resolver. Considering the fact that I only have a PC hard wired to this port, I have set the source to the IP address of my PC. The loopback address is the destination, and we're only concerned with port 53 (i.e., DNS) traffic.
The third and fourth rule are not ideal for a production environment. They effectively let all IPv4 and IPv6 traffic from any subnets on port 2/4 to go to any reachable destination on the network known to pfSense. Obviously, we would be much more granular in on policy on production networks.
At this point, there are no rules to configure on port 3/4. The only rule required on this interface is the one that was created when we configured port forwarding on all interfaces for DNS Resolution (i.e., by selecting 'Add Associated Filter Rule').
For now, this port is disabled, so, you shouldn't even see an option to configure firewall rules for this interface. In the future, consider enabling this interface and adding a wireless access point. You could then apply what you've learned in this lab and build out additional use cases with wireless devices (guest network, IoT/OT, etc.).
TBD...
For now, we don't need any rules for the Services VLAN, because we we've already configured the DNS redirect rule when creating our NAT redirect policy. The other three rules are to allow access from our Zscaler App Connector to other resources on our network. We will cover Zscaler App Connectors in a future lab.
Our first rule for the Users VLAN is to redirect all DNS traffic to the firewall for resolution. Since we've already configured that rule when creating the NAT redirect policy, that should already be created for us. Our second rule can be skipped for now, but it will come in handy when we implement a Zscaler Branch Connector in a future lab. The remaining four rules allow access from our lab PC to various applications and resources. We can set those rules up at a later date when we go through hardening our firewall. For now, all you should have to do is create an "allow all" rule for your lab PC.
We won't be configuring our Storage VLAN in this lab; however, if you'd like to take a sneak peek then feel free! In a future lab, we'll cover not only implementing a Terramaster NAS, but providing secure remote access to it using our Zscaler App Connector—a component of Zscaler Private Access.
Our Management VLAN is critical—especially when we've locked ourselves out of our switch, but it also comes with a risk. With the "allow any" firewall rule in place, anybody who connects to the Management VLAN will have full access. We'll cover steps we can take to harden our lab in a future post. Finally, so as to not introduce confusion, the Management VLAN will be used to manage our network Switch and not our Firewall. As was mentioned in a previous step, the PORT2LAN interface is our management interface for our pfSense firewall.