After entering GUI credentials and clicking sign in, it just goes back to a blank username and password field

kevindd992002

So, last weekend I changed the webGUI access protocol of two pfsense boxes from HTTPS to HTTP because I had to install Squid on both and serving the WPAD file to my clients needed the webGUI HTTP configuration. These two boxes are located in two different networks that are connected via an OpenVPN tunnel. Let's call them pfsense A (in network A) and pfsense B (in network B). Here's the exact behavior I'm experiencing:

From a client in network A, using Firefox:
a. Accessing either the pfsense A/pfsense B webGui using local FQDN -> no issues.
b. Accessing either the pfsense A/pfsense B webGui using local private IP -> after inputting the correct credentials and clicking Sign In, the boxes beep (normal) and then it just brings me back to the sign in page without the credentials. This looks to me like a cookies issue but I checked everything in Firefox and I'm not seeing anything blocked.
From a client in network A, using Chrome:
a. Accessing either the pfsense A/pfsense B webGui using local FQDN -> no issues.
b. Accessing pfsense A using local private IP -> no issues.
c. Accessing pfsense B using local private IP -> same issue as above.
From a client in network A, using IE/Edge:
a. Accessing either the pfsense A/pfsense B webGui using local FQDN -> no issues.
b. Accessing either the pfsense A/pfsense B webGui using local private IP -> no issues.

So you see, I only have issues when I use either Firefox or Chrome and I'm not seeing any pattern. I don't see it being an issue with the proxy either. Private IP destination addresses are all excluded from routing through the proxy and besides everything is working properly when using the crappy MS browsers.

Any ideas here? Thanks.

jimp

Downgrading to HTTP is probably to blame, and that's an awful reason to do it. Find literally any other box on your network to serve the WPAD file with HTTP rather than severely weakening your security.

Your browser is probably caching HSTS or similar, refusing to send data over HTTP.

kevindd992002

@jimp

Hmm, ok. Oh well, I guess I'll have to think of a creative way to server the WPAD file. Thanks!