How to Configure pfSense to Allow HTTPS Traffic through to Virtual Machine behind HA Proxy to Handle SSL?
-
Setup simplified;
- Physical pfSense hardware
-
- HA Proxy pfSense plugin
-
-
- Shared front end (one.example.com, two.example.com, etc.), configured to allow port 80 traffic
-
-
-
- Backend - one.example.com
-
-
-
- Backend - two.example.com
-
-
- WAN Interface firewall rule to allow inbound to WAN to access 'This Firewall'
- Physical Server
- VM 1
-
- httpd installed
-
- Let's Encrypt Certbot installed
- VM 2
-
- as above
What I'm having trouble with is configuring pfSense to allow 443 traffic through to VM 1 and VM 2 so that they can handle the SSL handshake. I've managed to get Let's Encrypt to generate the certificate and install it successfully via Certbot, but it's this last step I can't quite figure out the correct combination of things to configure within pfSense to get this to work. Seems that a lot of the content I've found online don't really cater for this and tend to focus down the ACME plugin on pfSense, but I'd prefer not to do that since pfSense shouldn't need to care about if VM 1 is using http or https, it should just pass the traffic on so that the VM can decide what to do about it.
-
@michaelcropper
If I hot you right, you want to Bypass Port 443 to the Web Server directly, but let haproxy handle Port 80 (Form whatever reason).
If so, simply forward Port 443 to the server.
But Döring so you cannot User both web servers Witz SSL -
@viragomann Not quite. What I'm ultimately wanting is to allow the VMs to decide what they do with any traffic, not the pfSense firewall.
The use case here is for hosting web applications, which are often require a bunch of different ports opening up and multiple ports to be handled, i.e. 80, 443, 25, 587, 21, 22 etc.
So to keep things self contained, i.e. at the VM level, I want the VMs to be doing the heavy lifting, so that pfSense ultimately just routes one.example.com through to VM 1, and then VM 1 OS firewall can decide what to do with things.
I want to keep pfSense as dumb as possible in this regard.
So in the specific use case originally described, the requirement is to essentially setup a HelloWorld web application running on Port 80, then setup Let's Encrypt on the VM to upgrade this to Port 443 for SSL traffic, but ultimately both 80 and 443 should direct traffic from WAN to VM 1.
Hope that explains a little more.
-
@michaelcropper said in How to Configure pfSense to Allow HTTPS Traffic through to Virtual Machine behind HA Proxy to Handle SSL?:
so that pfSense ultimately just routes one.example.com through to VM 1
pfSense itself cannot determine a host name. If can only Route IPs and ports.
But I assume that you have only a single public IP, but multiple public host names. pfSense laborats on layer 3, but the host name is only known at the application layer 7.HAproxy can determine the host names in http traffic, but Form https it needs to handle SSL as well for doing so.
-
Thanks for the info @viragomann
Correct, only a single public IP (at present, options to purchase more in future but I'd like to get an initial setup working with just one public IP as a starting point).
Could you help me understand this point better as I'm not sure I fully understand "HAproxy can determine the host names in http traffic, but Form https it needs to handle SSL as well for doing so."
In my mind, this is how it 'should' be working (but i've not managed to configure it to work like this yet...)
https://one.example.com --> pfSense --> haProxy --> virtual machine (ssl handshake + load website)
https://two.example.com --> pfSense --> haProxy --> virtual machine (ssl handshake + load website)
I would have thought haProxy could read the hostname of SSL traffic, without having to manage the SSL certificates via the pfSense ACME plugin?
-
@michaelcropper
So you're talking about SNI. I didn't ever realize this with TCP Mode. But read that forwarding traffic to different hosts depending on SNI should work.Maybe this describes how to:
https://serverfault.com/questions/995473/how-to-get-haproxy-to-route-tcp-based-on-sni-using-openssl-s-client-to-test -
Thanks @viragomann that's helpful info re. SNI. This is where the boundaries in my knowledge lie, aka. SNI = Hostname.
Coming from a cloud native web application background, everything ultimately "works" from the hostname. Everything around the network layer 'just works' between the hostname and virtual machine layer, it's this gap that I'm trying to understand with pfSense + HAProxy + ACME/Let's Encrypt etc.
For others reading this topic too. If anyone else has found a way to route one.example.com and two.example.com to a single DNS A Record / public IP address of 1.2.3.4 through to pfSense and/or HA Proxy to then forward this request (any port) through the the VM that handles that hostname, please do comment with thoughts/suggestions.
Seems that pfSense is more designed as a perimeter firewall rather than a zero-trust firewall such as cloud native platforms. Interesting. But I'm sure it's capable of edge cases to help with this without purely relying on a dedicated Public IP for Service X etc. to route traffic through to VM X etc.? Perhaps this is where my lack of knowledge in the networking layer is lacking, perhaps I'm expecting significantly more than what is technically capable at the specific layer of the stack.
The more I've been playing around with pfSense + HA Proxy against a single Public IP Address, the more I'm thinking that the only 'real' solution is to get multiple Public IP Addresses and then use pfSense as a true Layer 3 routing device, aka. IP 1.2.3.4, aka. don't care not my problem, fire it over to VM X, and 1.2.3.5, aka. don't care not my problem, fire it over to VM Y, etc.
-
Hmm, I expect to be able to do that (at least until encrypted SNI is more widespread) using pass-through SSL. Though it's not something I've ever tried myself in pfSense, HAProxy appears to be able to do it. Old example.
Steve