Squid3 reverse https proxy
-
Hi Team,
I have 2 sites that requires https and needs to be published to the world, one is exchange and the other is a site.
i installed squid3 reverse proxy and here is my config
Under General
Reverse proxy interface : WAN
external FDNQ : firewall.local
Reset TCP connection if request is unauthorised : checkedEnable HTTPS reverse proxy : checked
reverse HTTPS port : 443
reverse SSL certificate : webConfigurator default
Ignore internal Certificate Validation : checkedEnable OWA reverse proxy : checked
OWA frontend ip addredd : X.X.X.X ( IP of exchange server as there is 1 box only )
Enable ActiveSync : Checked
Enable Outlook Anywhere : Checked
Enable Exchange Webservices : Checked
Enable AutoDiscover : CheckedUnder Web servers:
Enable this peer : Checked
Peer Alias : Cloud
Peer ip : X.X.X.X ( IP of the server called cloud )
Peer port : 443
Peer Protocal : HTTPSUnder mappings :
Enable this URI : Checked
Group Name : Cloud
Peers : (Selected Cloud)
URIs : https://full address of website on this serverNow either exchange nor that site works.
I have also created a rule on the firewall forTCP * * WAN address 443 (HTTPS) * none
webaddress to port 443
Can anyone assist and where I am going wrong pls.
Cheers,
Raj
-
If you use NAT and Reverse Proxy, you should not do that.
Everything in your conf is fine except:
Squid must listen on the loopback
don't create Peer Alias to Cloud
don't create mapping to cloudYou habe in nat to add 2 things:
WAN TCP * * WANIP 80 (HTTP) 127.0.0.1 80 (HTTP)
WAN TCP * * WANIP 443 (HTTPS) 127.0.0.1 443 (HTTPS)This is my conf … working like a charm and NAT still usable
-
Hiya,
When I change the the 443 to 127.0.0.1, i can not access my exchange from outsite anymore :-(
-
Hi Raj
2 things:
1: Squid GUI uses the entered External FQDN as the domainname in the reverse proxy accessrules to identify what URL's goes towards your exchange. So you should enter your desired external hostname for your exchange (ie: mail.domain.com)
that should make your exchange work.2: Your second site is probably not working because you did not enter a proper URI for that. At the very least you need the trailing forwardslash (http://host.domain.com/). But you should enter a real regex such as: ^http://host.domain.com/.*$
Hope this helps
-
And I think you should ignore stanthewizards post. I'm quite sure his configuration is different from what you are trying to achive.
Btw. You are aware you will have certificate warnings when using the default non signed certificate right?
If you continue to experience problems then uncheck the reset connection ticker if users are unauthorized.
-
Hiya,
I change the settings as recommanded but for the website I keep getting
TCP_MISS/503
Any ideas to what this could be pls?
Cheers,
Raj
-
Hi Raj
So exchange works as expected?
If the "cloud" website doesnt work, It must be the URI thats wrong.
We agree that to access it externally you write something like: "https://externalhost.externaldomain.com" right?Your URI in the mapping should the read: ^https://externalhost.externaldomain.com/.*$
Its important you dont write any internal name that website might be known as.
-keyser
-
OK ;D
When you have the pfsense in front with squid and MSE on an other computer; the solution I give works flawlessly !
If you want to keep NAT you HAVE to listen on loopback and reroute port (many post on this subject)
-
Stan, I'm sorry to say you are not correct. I have a pfsense firewall with one public IP and it is doing NAT for my internal network where I also have several webservers.
In my setup squid is not listening on the loopback adapter, its listening on my WAN address, and my reverse proxy works flawlessly to all the internal webservers. So either your config somehow works by accident, or your setup is just different.Raj, I'm not sure why it doesn't work for your cloud service. Are you sure it runs as a HTTPS site on the Cloud server itself (you have stated so in the WEBSERVERS dialog)?
When sitting on the inside network (same subnet) as the cloudserver, can you reach it by using https://internalname.internaldomain.xxx? (whatever name it has on the inside). -
Ok managed to get exchange the my website working.
Now would this also work if there are different domain, let say https://mydoamin.com and https://mystuff.co.uk
Cheers,
Raj
-
Hi Raj
I'm not quite sure I understand your question, but I think you are asking if you can reach your exchange server with other domainnames than just the first one (entered in the external FQDN).
If that's the question, then yes, that can be configured. Basically you also need to create your Exchange Server as a WEBSERVER, and then you need to create a new mapping using the Exchange Server as peer. On this mapping you can enter the new URI's ( ^https//mydomain.com/.$ and ^https//mystuff.co.uk/.$)
-Keyser
-
Hi Keyser,
Thanks for the assistance first of all. I will host a few domains on https and I have only one wan ip.
I have been able to achieve the same type of setup with http by using varnish3.
So currently for my own domain, with an exchage server and another https website with the same domain, and your help I got that working.
Now the question is can I add different domains to point to their own sites ( https) basically varnish for https.
Cheers,
Raj
-
Keyser … this is the best course of action from MARCELLOC himself and one of the senior member.
Reverse proxy on the wan WITH NAT lead to issues !
-
So is there a way for me to achieve what i am looking to do with pfsense pls?
-
Well Stan you might be right as I have only done what seems logical and intuitive - which i might add is where pfsense is one of the best firewalls I have seen.
But I have not had any issues with my reverse proxy listening on the WAN interface. In terms of networking that is also by far and away the most "clean" looking and intuitive solution.So i guess you are suggesting to make a NAT portforward of 80/443 to the loopback adapter and have squid listen on that interface instead? That seems really cumbersome.
What are the potential issues with having squid listen on WAN directly?-Keyser
-
Raj
Yes, you should definately be able to run several different HTTPS based services (with different domain names) on just one public IP. I know I do ;-)
The trick is - if you dont want certificate warnings - that you need a SAN (Subject Alternate Name) Certificate on your pfsense as the certificate used in the squid reverse proxy config. This certificate has all of the different domain names you wish to publish, and from then on, you can simply make as many internal WEBSERVERS as needed, and as many mappings as needed. One mapping rule can easily hold several different URI's (to point several different domains/sites) to the same backend webserver.-Keyser
-
Raj
Yes, you should definately be able to run several different HTTPS based services (with different domain names) on just one public IP. I know I do ;-)
The trick is - if you dont want certificate warnings - that you need a SAN (Subject Alternate Name) Certificate on your pfsense as the certificate used in the squid reverse proxy config. This certificate has all of the different domain names you wish to publish, and from then on, you can simply make as many internal WEBSERVERS as needed, and as many mappings as needed. One mapping rule can easily hold several different URI's (to point several different domains/sites) to the same backend webserver.-Keyser
Hi Keyser,
This would be for two different domains…ex domainA.com and domainB.com?
If it is the same domain, a wild card cert should be fine....correct?
so something.domainA.com and otherthing.domainA.com will both work with a wildcard using reverse proxy. -
Yes, a SAN certificate is for different domain named services (ex: https://www.domain1.com and https://www.domain2.com). That works well with squid3 reverse proxy like i wrote to raj.
A wildcard certificate also works just fine on squid3 reverse (i have tried that too). But like you said that can only be used for different services with the same domainname (ex: https://site1.domain1.com and https://site2.domain1.com). The wildcard certificate in this example would have a common name like this: *.domain1.com
-
Yes exactly
Listen on loopback
2 NAT : 80 to loopback on squid IP
443 to loopback on squid IPWorks like a charm
With this course of action, you can keep NAT AND ! Squid reverse proxy
-
Stan
What are the issues with having squid listening on WAN directly? I haven't seen any yet, and I do NAT outbound.
I'm running a fairly new snapshot of 2.1 x64
