Multiple Reverse Proxy rules
Is it possible to add more than 1 reverse proxy rule? I want to reverse proxy multiple ssl protected sites. I am hosting for instance MS CRM, MS Exchange and MS ADFS, which I am currently reverse proxying with MS TMG (which I obviously and sadly need to leave). Any ideas what is the best approach?
And can I use SNI on the pfSense appliance (do I need haproxy on the appliance as well? This is now separated and I like to keep it that way).
Hope to find some answers here =)
afaik pfSense base system (portforward rules/loadbalancer) cannot utilize SNI to forward traffic to a specific server.
HAProxy would be a possible solution for that. If you want to run haproxy 'on' pfSense or on a separate server behind it is ofcourse your choice ;) , also depends on what features/requirements you want/need.. a feature like 'transparent-client-ip' needs haproxy to be the return path of traffic between webserver and client IPs..
Thanks for replying.
Well, I am am kinda hesitated to put all services (FW, LB and proxy) on one set of boxes. Also new to pfsense, so don;t know about the stability of you run all these things together. Currently I have TMG exposing my services, which is also a all-in-one solution, but it gives my headaches using it as a forward proxy. So that part is already been taken over by a pair of Squid boxes.
That being said, my requirements are not that complicated. I have a set of HA web services (Exchange, CRM, SharePoint, ADFS), that I need to expose to the outside world. Internally SSL is also required and configured. So now I am trying to figure out the best way forward. TMG is a dead end anyway.
The base system does not have SNI, you need to have HAProxy and/or Squid for that. And that is where I cant make a decision upon. I can't make up what should first be hit by the clients, HAProxy or rev proxy (squid). HAProxy has nice health checks for individual web services. Squid has caching of static content finer grained ACLs.
And of course I'd like to have a future proof and versatile setup, so I can tie everything up into this platform. SNI would be nice, but is at this point not a real necessity, but I figured this is needed, coz you can only create one rev proxy rule in the squid package for pfsense was my 1st idea working my way through the pfsense GUI.
Any ideas what would be the best choice here?
personally i'm running haproxy on the pfSense box and it runs fine.. (for my small workload) (p.s. i maintain the haproxy package on pfSense..)
If your going to balance a large amount of traffic it might be beneficial to put it on a separate box, or just for peace of mind that the firewall itself wont be compromised when for some reason haproxy is.. also if a update to a openssl vulnerability is disclosed it wont be available until a new pfSense release is made which can sometimes take a little while.. would you be patching native freebsd/linux machines directly after such event.?.
But having it on pfSense is easy and convenient as it can distribute traffic directly to the correct network as pfSense is connected to all of them (in my case anyhow..). And it has a imho decent webgui which can be nice.. (but can always be done better)..
As a 'best practice' separate tasks should probably stay on separated machines.. but for smaller environments i don't see harm in running haproxy on the same box as pfSense..
So with regard to 'best choice' the isn't one truly universal good answer to that..
My load is ever growing, so I need a stable grow path, preferably horizontally, by adding more servers, not changing the concept. So I prefer splitting up services over boxes (or containers).
There is no real same truth for every case, that I agree.
Would you say adding Squid to the mix is benificial and how would the route be if all on one box? Client -> FW -> LB -> rev proxy -> Web Service.
Grtz and thanks for sharing.
Ronald, also NL =)
Use squid for what its made for.. a forward proxy.. other than that it isnt really good as a reverse proxy afaik…
If your going for separate machines, a combination regularly seen on the web is haproxy+varnish.. Also the latest 1.8.x haproxy version has a new feature with a 'small object cache' in memory..
So yes probably something like client>pfsense>haproxy>varnish>webserver should work good. Though some also switch varnish and haproxy around..
Probably better if someone with a bigger environment than me shares their experience.. even though it ain't really a pfSense related subject anymore ;)
Yep, its getting kinda broader here, but I think it's a good topic. Can also do PMs if that's more appropriate.
Squid is used as reverse proxy, because of its ACL possibilities. Still wonder why pfsense can only have 1 general rev proxy rule configured, while you can have multiple of 'em, as much of you have external IPs. Should be fixed in GUI I guess. And also my other question concerning the cipher suites used in this squid package, there are some weak ones in there, there should be carved out. But when I edit the squid.conf file locally on the pfsense boxes, it is reset on reboot, so its not persistent. I think that should be part of the GUI as well.
I usually do load balancing before reverse proxy (latter if needed at all).
Had a short look at Varnish, but can't find a lot of information about it. But some are even doing squid rev proxy -> varnish cache -> web service. But I cannot see the benefit in that. Maybe finer grained ACLs or something? Is varnish just a transparent cache?
I do see a lot of items about nginx on the net though. Think I give that a shot.
Thanks for sharing again =)
Nah keeping it in the topic is fine. pm's take more work if someone else has the same question they might find the answer here, or participate in the discussion :). pm's cant have that effect.. and there is no sensitive information discussed currently..
Regarding squid ciphers there is an "Compatibility mode" option for modern/intermediate .. or maybe this still works i dunno: https://forum.pfsense.org/index.php?topic=63262.msg524828#msg524828
As for caching, ive got no real experience with it.. my gut feeling is that squid is primarily meant as a forward-proxy, and should probably stick to that.. and varnish is mentioned several times on haproxy's site "Basically, HAProxy and Varnish completes very well" https://www.haproxy.com/blog/haproxy-and-varnish-comparison/
Perhaps indeed nginx might work, or apache.. both seem more purposed at the task for handling incomming client requests for 1 website..
As for acl abilities, haproxy can do some acl's / stickiness / ssl offloading and or sni.. and does those very well imho.