Squid reverse proxy authentication

[keyser]

Hi forum

I have a pfsense with squid reverse proxy installed that publishes 10 http/https sites just fine.

However, I have one regular website that I would like to restrict to external users that can authenticate via username/password. Normally I would configure the website (internal webserver) to require authentication, but i would really like NOT to have to authenticate when I'm on the internal network. Can i have Squid reverse authenticate users before it reverses requests to the internal server?

• Keyser

[keyser]

Anyone?

[keyser]

Well, I assume that means it's impossible to have squid3 reverse authenticate users…

Pity, that's one of the really wonderfull things about Microsofts TMG 2010

[louis-m]

it's something i've always wanted also but as far as i know (or have tried), it's generally down to the web server itself.

[keyser]

Yeah, and the really weird part is that squid is pretty good and flexible when it comes to authenticating users on the squid forward proxy. I would think the required code is pretty much the same, or?

[sokolum]

@keyser:

Yeah, and the really weird part is that squid is pretty good and flexible when it comes to authenticating users on the squid forward proxy. I would think the required code is pretty much the same, or?

Did you managed to find out if this is possible? I also want to authenticate User on my Proxy instead doing the authentication on my Web server itself.

First i was thinking to  miss use a load balancer on my Pfsense for this, but then only placing 1 web servers, for using the load balancer functions (at least, on work i am using F5 LTM and APM, that will do the job) and to redirect web connections.

Well, if any one knows the answer.

[dig1234]

I stumbled across this guy's solution for the issue of authentication in reverse proxy mode:
http://www.mikealeonetti.com/wiki/index.php?title=Squid_Arms_and_Tentacles:_Authentication

Would take a bit of work to implement on pfsense but thought I'd mention it since I haven't seen many responses to this issue..

[wilixje]

@dig1234:

I stumbled across this guy's solution for the issue of authentication in reverse proxy mode:
http://www.mikealeonetti.com/wiki/index.php?title=Squid_Arms_and_Tentacles:_Authentication

Would take a bit of work to implement on pfsense but thought I'd mention it since I haven't seen many responses to this issue..

dig1234, Do you already have a working solution for your issue, or is the above guide working for reverse proxy authentication. I have the same question as you, and would like to know how to implement the reverse proxy authentication.

[dig1234]

Actually if you install the Squid3-devl package under authentication there is an option for Captive Portal which I was able to test and seems to work nicely. Unfortunately it only ties to IP address but that's the limitation of transparent proxy. (they could add MAC for clients on same lan)

[wilixje]

I installed the Squid-Dev package. I enabled the authentication in the Proxy server:
Proxy server: Authentication - Authentication method to Captive Portal

When I browse to my URL, I get the following error message:
The connection was reset The connection to the server was reset while the page was loading.

Can you provide me your settings of the proxy server, captive portal and reverse proxy? So I can find out what's going wrong.

My configuration:
Captive Portal:
Captive portal: home:

• Enable captive portal (checked)
• Interfaces: WAN
• Idle timeout: 30 minutes
• Authentication: Local (and  "Allow only users/groups with 'Captive portal login' privilege set" unchecked)

Proxy server: General settings

• Proxy interface(s): WAN
• Proxy port: 3128
• Allow users on interface: Checked
• Patch captive portal: Checked
• Transparent HTTP proxy: Unchecked
• HTTPS/SSL interception: Unchecked
  Proxy server: Authentication:
• Authentication method: Captive Portal
• Authentication TTL: 86400

Reverse Proxy server: General

• Reverse Proxy interface: WAN
• Enable HTTP reverse mode: Checked
  And my subdomains be configured at the other tabs of the reverse proxy. If I disable the authentication within the Proxy Server, the Reverse Proxy is fully functional and working.

[dig1234]

A few points:
-why are you setting up on WAN interface this would usually be a LAN side function, are you trying to do something WAN side?
-ASFAIK you do need to mess with or enable the reverse proxy settings you just set transparent mode for that interface on the proxy server page
-there are some things you need to do to get the squid3-devel package working, don't have it off hand but it's in the forums, basically download some libs

@wilixje:

I installed the Squid-Dev package. I enabled the authentication in the Proxy server:
Proxy server: Authentication - Authentication method to Captive Portal

When I browse to my URL, I get the following error message:
The connection was reset The connection to the server was reset while the page was loading.

Can you provide me your settings of the proxy server, captive portal and reverse proxy? So I can find out what's going wrong.

My configuration:
Captive Portal:
Captive portal: home:

• Enable captive portal (checked)
• Interfaces: WAN
• Idle timeout: 30 minutes
• Authentication: Local (and  "Allow only users/groups with 'Captive portal login' privilege set" unchecked)

Proxy server: General settings

• Proxy interface(s): WAN
• Proxy port: 3128
• Allow users on interface: Checked
• Patch captive portal: Checked
• Transparent HTTP proxy: Unchecked
• HTTPS/SSL interception: Unchecked
  Proxy server: Authentication:
• Authentication method: Captive Portal
• Authentication TTL: 86400

Reverse Proxy server: General

• Reverse Proxy interface: WAN
• Enable HTTP reverse mode: Checked
  And my subdomains be configured at the other tabs of the reverse proxy. If I disable the authentication within the Proxy Server, the Reverse Proxy is fully functional and working.

[wilixje]

Currently I have a working reverse proxy setup, but without the authentication part.

My domain name is pointed to my public WAN IP address. And the reverse proxy is used to forward, domain based, traffic to the correct server/port:
subdomain1.domain.com:80 -> WAN IP -> Reverse proxy -> Internal server 1 port 80
subdomain2.domain.com:80 -> WAN IP -> Reverse proxy -> Internal server 1 port 8080
subdomain3.domain.com:80 -> WAN IP -> Reverse proxy -> Internal server 2 port 32400

The scenario above, is working fine. But the actual issue is that everyone is be able to access those internal pages. To solve this I would like to implement a authentication within PFSense to provide a logon form before someone is be able to enter my proxy. I don't need a proxy for the LAN -> WAN traffic. The NAT Reflection mode for port forwards is set to NAT + Proxy, so I'm be able to get access to the internal server trough the domain name.

It's correct that you need to install/download some lib files (http://e-sac.siteseguro.ws/pfsense/8/All/ldd/) before squid3-dev is be able to start.

[dig1234]

ah this is a different scenario than I am dealing with.
Captive portal on the WAN side is interesting, I don't think it was designed to work that way, but I could be wrong. It creates ipfw rules on the interface so you may have to play with those in order not to mess up the rest of your WAN traffic. Just a thought you might be better off enabling it on a different interface (eg a fake VLAN) then creating rules manually to forward the traffic there. Sorry I haven't experimented with this situation but it seems do-able.

[Tired2]

Not exactly a solution to the problem via pfSense, but I've done this with authentication on NGINX.  Theoretically, you could put an NGINX reverse proxy with auth setup on your internal server (I use auth_basic, but LDAP or other methods would work).  Then, if you hit https://nginx/myservice, you get the auth page.  Apache should work too.

I need to use something similar at work to "secure" a closed source timesheet server that is pretty poorly done, but I'm stuck with it.  I feel better using modern auth to protect the web interface to prevent threats on the poorly designed second level of auth provided by the timesheet server.