Split 443 traffic to two websites behind one WAN Interface

frank.ralston

Hi there,

First time user so apologies if post is redundant.

I have a firewall currently with one WAN Interface which has one public advertised website pointing to it.
It takes in HTTPS and SMTP Traffic and I am about to add another website to point to the same WAN Interface.
(2 WEBS, 1 PORT!)
Both Web Servers must used Port 443 and I'm aware that changing my NAT rules for this isn't going to happen.

Currently all SSL/HTTPS Traffic is going to the 192.168.20.55.

What would be a reasonable solution to differentiating between traffic from the web. FQDN and the apps. FDQN?
Is it possible to use the Squid package on pfSense for this?
Is there even a valid solution for this with pfSense? Perhaps the .55 can redirect to .74 based on looking up the FQDN?

Attached and below is a diagram of the current NAT Translation and the proposed setup.

Any comments would be much appreciated.

webTraffic.png_thumb

GruensFroeschli

Do you need to run the two webservers on two different machines?

In the base pfsense it's not possible to distinguish based on the url. Not sure if some package could do it.

Most webservers support "virtual" domains, aka. Different page dependant on the requested url.

frank.ralston

@GruensFroeschli:

Do you need to run the two webservers on two different machines?

In the base pfsense it's not possible to distinguish based on the url. Not sure if some package could do it.

Most webservers support "virtual" domains, aka. Different page dependant on the requested url.

I'm not authoritative to the LAN and I would agree with you that pfSense couldn't distinguish based on URL but port no.
If it were my set up, I would have my Web services on the same server as it simplifies my current port forwarding rule for 443.

To elaborate, they have 2 SSL certificates for both web and email. I'll query them regarding your suggestion for "virtual" domain - perhaps a pointer to the .74 from the .55.

frank.ralston

Temporary resolution agreed with LAN Administrator.
Short term solution to use a unique port number with NAT Translation of 443 to the .74 address.

A long term solution would be for all HTTPS and traffic types to point to a internal proxy Server.
For IIS 7, this is done using the method described in this link using AAR and URL Rewrite:

http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing

A more efficient choice may be with using a linux distro such as Apache.

kathampy

This won't work for HTTPS unless the client browser supports SNI.

jimp

pfSense 2.1+HAproxy-devel + Browser SNI support will let you distinguish based on the hostname, but that's probably as close as you'll get.

PiBa

With HAproxy-devel, for those browsers that dont support SNI, you could also let HAproxy do the decryption (ssl-offloading) of the ssl traffic and check the host in the http request, then forward it to the proper backend(possible to use a new ssl connection if needed). Its advised to use a wildcard certificate for the offloading, as because the browser didnt send SNI information haproxy wont be able to pick a 'proper' certificate when multiple certificates/websites are configured..

frank.ralston

@jimp:

pfSense 2.1+HAproxy-devel + Browser SNI support will let you distinguish based on the hostname, but that's probably as close as you'll get.

Thanks for the replies, guys. Also, the information regarding SNI.

The NAT rule along with a Firewall rule permitting this is currently working for external users. But I will definitely look into HAproxy and its features as an option for the future.