Following my previous post on how to make your Jamf Pro server public, I gave it a try in my homelab…

Just note that this is only a proof of concept, as there are many reverse proxies, or load balancers, available for a production environment (both hardware as software). (For Load Balancing my clustered Jamf Pro setup, on another test server, I used HAProxy which has Reverse Proxy functionality as well).

An in depth discussion of how I configured my homelab for testing different scenario’s (both Jamf related as more general) might be for another time, but let’s quickly have a high level look at the following setup.

To skip the small talk and go straight to the tutorial on installing Squid on pfSense: click here 🙂

I’m running an ESXI Hypervisor on a HPE Proliant Server behind my home router (a Netgear Nighthawk X10). To separate the virtual environment, from my home network (last thing you want to do is to kill the network the lady of the house is using for streaming Netflix, Interactive TV, Social Media etc… by building and breaking stuff for testing purposes 🙂 ), I configured a virtual switch in ESXI (linked to one of the 2 network ports of the HPE Proliant server), I installed pfSense on a VM, and connected the WAN side of pfSense to the virtual switch in ESXI. Hence the “WAN” side is getting a private IP address in my home network, but still behind the firewall of my Netgear router. Super handy when testing so called “public” servers running on the hypervisor, as my home network can be considered as the public side of the virtual environment. This with pfSense as the firewall/router in between, and a static route between the home network and the virtual IP range behind the pfSense.

So far, whenever I needed to test a “public” service, I opened ports on the pfSense, or moved the server to the DMZ (WAN side), allowing me to test from any device connected to my home wifi. However, when I needed to really make the service reachable from the Internet I also had to enable port forwarding on the Netgear router. This actually worked fine, but except from the fact that I like to avoid punching any holes in the firewall on ports other than 443 and 80, this gave me one big limitation.

While the Netgear X10 is actually packed with a lot more features than the average consumer router, advanced networking features are still limited. Hence port forwarding a specific port to a specific internal server, means that I couldn’t make another server publicly available on the Internet over the same port. 

Following my previous post on Jamf Pro and reverse proxy, as well as to give me more flexibility for future projects, I decided to do things differently by using a reverse proxy. This allows me to port forward port 80 and 443 (or any port I need) from the Netgear to the pfSense… and the reverse proxy does the magic to point the traffic to the server I want.

Let’s see how that works:

Install Squid on pfSense:

Pre-requisites:

  • A (virtual) machine with pfSense (freeBSD) installed
  • A WAN interface configured on the pfSense
  • A LAN interface configured on the pfSense, most likely a virtual Switch on your hypervisor

Before we can dive into the reverse proxy settings, we first need to install the service in pfSense, and, while there are for sure other proxy tools offering the same functionality, I went for Squid.

To install Squid on pfSense, log into your portal, go to System-Packet Manager-Available Packages and install Squid:

Next, you’ll have to enable the overall Squid proxy service, as the reverse proxy only becomes available if the normal Squid proxy is enabled. Go to Services-Squid Proxy Server

When enabling Squid, it will ask you to configure Local Cache first. For the purpose of this exercise, I left the default settings, but in view of accelerating the performance of the web servers you are configuring reverse proxy for, this is where you would tweak the caching settings for Squid to speed up your website.

Next, we go to Service-Squid Reverse Proxy

First of all, you’ll have to select the interface on which the reverse proxy will listen. Logically, looking at reverse in reverse proxy, this will be the WAN interface of your pfSense. If needed you can add additional proxy IP’s, such as any virtual IP address of your pfSense firewall on which Squid should listen as well.

Below this you will see the options to enable “Squid Reverse HTTP Settings” and “Squid Reverse HTTPS Settings”, where you will define the ports on which both protocols should listen. Apart from more advanced setups, this is most likely going the be the standard ports 80 and 443. However, as usual, ports below 1024 are reserved ports, and Squid will give you an error when trying to save the settings under the General tab.

The error you’ll see (my apologies for omitting to take a screenshot of this specific error) , will tell you to change the value of net.inet.ip.portrange.reservedhigh in System-Advanced-System Tunables to “0”, but I noticed this variable doesn’t exist by default.

Only the net.inet.ip.portrange.first, which is set to 1024, is present by default.

I added the “reservedhigh” variable, but changing the “first” variable works as well. Furthermore, changing the value to “0” removes the reservation of all ports below 1024, but you could actually put 79 if you want to keep everything below 80 reserved.

(442 if only using reverse proxy for HTTPS or 80/443 when changing the “first” variable instead of adding “reservedhigh”).

Once that’s done, don’t forget to restart the Squid daemon (go to Services-Squid Proxy Server and restart squid – restart icon on the top right) and go back to the General tab of your Squid Reverse Proxy Settings.

For HTTP reverse proxy the settings are quite straight forward, just enable the service and add port 80 (or any custom port your clients are connecting to for HTTP).

HTTPS involves a bit more work, as obviously we’ll need a SSL cert for HTTPS to work. This would bring me again a little too far in this post, but, long story short I used the ACME functionality in pfSense to generate a wildcard SSL cert with the Let’s Encrypt Certificate authority.

“Using ACME in pfSense” is on my draft list for upcoming blogposts, so stay tuned for more! However, if you want to use reverse proxy with SSL, you can either import an existing SSL cert in pfSense, or have a look at Let’s Encrypt to learn more. Once you are familiar with how Let’s Encrypt works, have a look at the ACME package you can install in pfSense. The ACME feature in pfSense is really straight forward. It’s even able to use the API of your domain registrar to automatically handle the DNS Challenge to verify ownership of your domain name. Really cool stuff, I promise you!

Once you have your SSL cert ready, you can enable Squid Reverse Proxy over HTTPS.

Next, Squid needs some backend servers, or at least one (Otherwise there is nothing to proxy 🙂 ), and for that we go to the Web Servers tab.

For the purpose of this exercise I installed a Jamf Pro server on a VM (internal side of the pfSense), and just for the fun of it changed the port to 443. Handy when using it for testing… less typing in the URL 🙂

Finally, we need to add some mappings. This will catch and evaluate the URL the client is connecting to, compare it to a list of criteria and link the user to the correct backend web server or peer. In my case here my on-prem Jamf Pro server.

Give your mapping a name and description and select the relevant peer this  mapping should be linked to.

Note: You can map to exact URL’s or use regex expression, where “^” and “$” are respectively the beginning and the end of the pattern it should detect in the URL.

Hit save and done!

Or actually, almost! Depending your pfSense firewall settings, you might have to add a Firewall rule to allow incoming traffic on the ports you configured for Reverse Proxy (80/443). 

That’s all folks! As always, if you like this post hit the like button, leave a comment, and tell your friends about this blog by using the sharing buttons down below.

Don’t hesitate to make any suggestions, comments or corrections!