Start a new topic

CrushFTP behind proxy (Squid), web interface issue

tk_don @ Mon Sep 15 04:46:04 EEST 2014
Hello,

My setup is this:
In a corporate network we use a proxy server to access the internet. The proxy software is Squid 3.1. On a different PC (on our internal network) a PC is running CrushFTP7 on Kubuntu (192.168.0.27). I access the CrushFTP web interface within the local network by crushftp.domain.com at port 8080, and Squid is setup to handle the Crushftp as a virtual host and "redirect" it to the correct IP. The configuration is as follows:

[code]
http_port 80 accel defaultsite=crushftp.domain.com vhost
cache_peer 192.168.0.27 parent 8080 0 no-query originserver login=PASS name custaccess
acl loc_users dstdomain crushftp.domain.com
cache_peer_access custaccess allow loc_users
cache_peer_access custaccess deny all
http_access allow loc_users
http_access deny all
[/code]

I can login sucesfully using the local 192.168.0.27:8080 address.
When I enter crushftp.domain.com in my web browser I also get the web-interface, but upon pressing the Login button or "I forgot my password, email it to me", I am faced with a "Service Unavailable" message.

I have tried disabling all firewall rules on the proxy server, tried a different port number than 8080 (and coordingly modified it locally for CrushFTP).

Any hints other than to avoid Squid?
I'm aware this could be a Squid issue, but what does this "Service Unavailable" more specifically mean and what causes this error?

spinkb @ Mon Sep 15 06:52:35 EEST 2014
Make sure there is no "caching" going on by Squid...

Otherwise I see no reason why it should really matter. People use apache as a reverse proxy all the time.

Is this CrushFTP 7.1?

What is logged in CrushFTP?

Is squid passing through cookies and everything?

Thanks,
Ben
tk_don @ Mon Sep 22 03:59:20 EEST 2014
Hello Ben,

Firstly, thank you for the very prompt reply - and excellent suggestions. Had a lot of stuff to do last week, so didn't have much time for much experimentation.

Yes, this is CrushFTP 7.1 (123) - purchased last week.
CrushFTP is running on a server at 192.168.0.27, the Squid proxy is at 192.168.0.99. The PC that I'm using at the moment has an IP of 192.168.0.166.

The following is logged in CrushFTP (crushftp.log):
[code]09/22/2014 09:39:24 AM|[HTTP:4711:192.168.0.27:8080] Accepting connection from: 192.168.0.99:60363
09/22/2014 09:39:24 AM|[HTTP:4711::192.168.0.166] READ: *GET / HTTP/1.1*
09/22/2014 09:39:24 AM|[HTTP:4711::192.168.0.166] READ: *Host: crushftp.domain.com*
09/22/2014 09:39:24 AM|[HTTP:4711::192.168.0.166] READ: *DNT: 1*
09/22/2014 09:39:24 AM|[HTTP:4711::192.168.0.166] READ: *Via: 1.1 VM_proxy (squid/3.4.7)*
09/22/2014 09:39:24 AM|[HTTP:4711::192.168.0.166] READ: *X-Forwarded-For: 192.168.0.166*
09/22/2014 09:39:24 AM|[HTTP:4711::192.168.0.166] WROTE: *HTTP/1.0 302 Redirect*
09/22/2014 09:39:24 AM|[HTTP:4711::192.168.0.166] WROTE: *Pragma: no-cache*
09/22/2014 09:39:24 AM|[HTTP:4711::192.168.0.166] WROTE: *location: HTTP://crushftp.domain.com/WebInterface/login.html*[/code]
In my access.log for Squid, I'm seeing the following:
[code]
1411371168.493 237 192.168.0.166 TCP_MISS/302 204 GET http://crushftp.domain.com/ - FIRTUP_PARENT/192.168.0.27 -
1411371174.888 161 192.168.0.166 TCP_MISS/503 2777 POST http://crushftp.domain.com/WebInterface/function/ - HIER_NONE/- text/html[/code]

I have since upgraded Squid to 3.4.7, but am using the same configuration.
Squid is configured to allow all cookies, all caching disabled - did do some experimentation with this, it doesn't look like it affects anything. It seems to me that the last line of the squid log is the problem, but I'm at a loss of what causes this. Maybe I should ask at the Squid mailing list, since it seems as if Squid is the problem right now - or do you have any other suggestions?
spinkb @ Mon Sep 22 06:29:22 EEST 2014
I really think cookies are being lost.

Or...maybe your OS localization is not English? I've seen an issue there once too for Turkish...

A chrome debug session watching the network tab and looking at the calls for everything except css, js, and images would be helpful to. Email us directly and we can do a screen sharing session to debug.

Thanks,
Ben
tk_don @ Mon Oct 06 09:31:39 EEST 2014
Hi again

Just to follow up on this - the firewall/iptables for 192.168.0.27 was on purpose designed to not accept port 80 requests. When creating an input filter rule for port 80, everything works well after also telling CrushFTP to listen at port 80. I suppose this is by design?
Anyways, as I have lots of stuff to configure on the server, I'd have to be my solution for now. :)
spinkb @ Mon Oct 06 12:37:41 EEST 2014
CrushFTP doesn't care about ports...80 is the same to it as 54382. Its just a port and makes no difference what it is.

The issue I saw in what was going on with you is the auth cookie is being lost. Without that, CrushFTP sends you back to the login page.

Thanks,
Ben
Login to post a comment