PfSense multiple WAN IP's - HTTPS issue
-
Hi all,
After messing around for two days and trying to solve this myself, i give up and admit: I NEED HELP!The setup:
Hardware:
-
pfSense server in a farm with multiple IP's (10.10.10.1)
-
-
Web Server (10.10.10.5)
-
Database Server(10.10.10.6)
-
pfSense server has the following IP's:
-
88.xxx.xxx.106 (assigned to pfSense as main IP)
-
88.xxx.xxx.248 (VIP)
-
88.xxx.xxx.80 (VIP)
-
88.xxx.xxx.81(VIP)
Rules: Port forward 80/443 WAN ADDRESS to 10.10.10.5
The web server (IIS) hosts all the websites (each IP should have a unique website)All the websites are accessible on HTTP and running.
The issue:
88.xxx.xxx.248 (bound to port 80 and 443) has a SSL certificate and offcourse runs as https://website1.com
88.xxx.xxx.80 (bound to port 80 only) https://website2.com responds with chrome error "This server could not prove that it is website2.com; its security certificate is from website1.com"
Choosing "Proceed" in Chrome, gets me to https://website1.comThe same goes for the all the other websites, they all respond on HTTPS with the warning message and then redirect.
Why is it happening? How can i fix this?
Please feel free to ask any questions that might help resolve this. -
-
No hero for the rescue?
-
You need a reverse proxy with SNI. Perhaps haproxy-devel supports something like this. Not CARP-related thing at all.
-
haproxy-1_5 supports SNI, and so does haproxy-devel..
However the question does not make much sense to me.?.
If nothing is listening on 88.xxx.xxx.80:443, then the browser should simply get a timeout or reject while trying to connect.. It wouldnt magically return certificate from website1..Or have you forwarded both 80 and 443 for all 4 ip's ?
Does the IIS server have multiple certificate binds configured for each website? Using either SNI / multiple ip's / multiple ports on the webserver.?
If you have enough public ip's then a reverse-proxy with sni should in my opinion not be required to make it work.. It could still be nice to have for other reasons.. (ssl offloading, queuing new connections, loadbalancing, providing a maintenance message while the server is down)
Its not carp related.. but the OP was probably thinking about the VIP's he/she is using when posted the question..
Anyway some more info would be needed to make sense of it..
-
However the question does not make much sense to me.?.
Well, my understanding is that this is some half-finished "testing" setup which breaks more b/c it's half-finished than anything else… If each VIP was forwarded to the respective IIS LAN IP, I guess it'd just work, assuming there is just ONE website per IP on the IIS.
-
I'm not sure VIP here means CARP or anything like this but rather additional IP allocated to unique interface. Not 100% clear to me :-[
-
haproxy-1_5 supports SNI, and so does haproxy-devel..
However the question does not make much sense to me.?.
If nothing is listening on 88.xxx.xxx.80:443, then the browser should simply get a timeout or reject while trying to connect.. It wouldnt magically return certificate from website1..Or have you forwarded both 80 and 443 for all 4 ip's ?
Does the IIS server have multiple certificate binds configured for each website? Using either SNI / multiple ip's / multiple ports on the webserver.?
If you have enough public ip's then a reverse-proxy with sni should in my opinion not be required to make it work.. It could still be nice to have for other reasons.. (ssl offloading, queuing new connections, loadbalancing, providing a maintenance message while the server is down)
Its not carp related.. but the OP was probably thinking about the VIP's he/she is using when posted the question..
Anyway some more info would be needed to make sense of it..
I agree that the browser should just timeout (since the other sites are not bound to port 443, but that is exactly the issue.
The IP's are Virtual IPs (Not CARP)
There is one port forward rule that forwards both port 80 and 443 of all the IP's to the SINGLE web server (Which is bound to 10.10.10.5)
I have read a little about SNI (as the first answer suggests), but IIS version on the server is 7.5 and therefor SNI is not supported.
@Doktornotor
There is only one LAN IP for the webserver, therefor i cant forward each Ext IP to its respected LAN IP.Guys, any information you need, just tell me what it is and i will be happy to provide it.
-
I might have something wrong with the setup (as suggested, but cannot see why)
I guess there are 3 ways to fix this:
1. on the Webserver, make it a VM server and run multiple VM's with IIS, each with unique LAN, and forward Ext IP to each LAN IP
(this solution looks like it is WAY to much for a setup that needs one web server that will run multiple sites)
2. a solution like haproxy (for SNI), which i never heard about until now and do not know how to setup.
3. upgrade the server (and IIS to ver 8) so it would support SNIOption 2 looks the most reasonable, but i have no idea how i can make that work.
-
Some questions:
-Do you want all 4 site's to be reachable using https? (if its only required for 1 site there is no need for SNI or any other extra stuff..(
-Are you testing access to website2 from 'outside' a client or 3/4g phone on the internet? As when testing from the LAN you might actually be accessing the pfSense webgui.?. Though that would still not explain the redirect to website1..
-Is it possible to visit website2 over https on the current IIS configuration? (ignoring the certificate error.?.)1- VMs seem like a rather big solution to a small problem (+licences)..
2- Haproxy would allow you to configure 4 different certificates one for each domain / ip.
You could even host all 4 sites on 1 external ip, in which case SNI is required to send the right server-certificate back to the client.
3- upgrade IIS of course technically possible, but might require a new windows version (+licence).
4- With the 'old' IIS version i think it might just be easiest to configure the webserver with 4 lan-ip's and change the portforwards to direct traffic to each of those ip's. Then also configure the 4 websites in IIS to bind to those lan-ip's. (you could also try with assigning different ports instead of 443 to the other https sites 1443 2443 3443, and forward traffic there, that would evade the multiple lan-ip requirement, but might lead the site to generate wrong url's containing the port.. something you would need to test.)I would probably prefer option 4 with multiple lan-ip's or ports, if that isn't possible option 2 or even the combination of both :).