Month: April 2024

pfSense HTTP_REFERER error

I’m just sharing this so my spent frustration can possibly help someone else.    If you’re setting up pfSense in a VM container, or otherwise can’t access pfSense via a local LAN IP for initial setup, then this information might save you some headache.    Every time the devs were asked about this, or to make it easier on people in this situation, their answer was to set up a machine on the local LAN.   Not overly helpful.

The error that this will help with, will be similar to:

An HTTP_REFERER was detected other than what is defined in System -> Advanced (http://192.168.0.1:8080/). You can disable this check if needed in System -> Advanced -> Admin.

So, as long as you have console access to pfSense (or access via SSH) then we can work around this error.    Since the error message suggests changing a setting in the Webconfigurator, which obviously you can’t access, it’s not very helpful either.

So, this is pretty straightforward.   From the pfSense console, enter 8 (or the option for Shell).

Then, type the below, pressing ENTER after each double-backslash that you see below, and then enter at the very end.

sed -i -e '/<webgui>/a\\
<nodnsrebindcheck>yes</nodnsrebindcheck>\\
<nohttpreferercheck>yes</nohttpreferercheck>\\
' /conf/config.xml

There should be no feedback after this is done.    Then, type exit, hit enter and use the option to reboot.

The only other command you might need, is only applicable if you can’t get the login screen to appear.    Be forewarned, that if you use this command below that you should get your configuration done and restart as soon as possible.   This command disables the firewall completely.   Type the below after using option 8 (for Shell) from the pfSense main menu:

pfctl -d

 

Well, I hope this helps someone.  Whenever I waste time on something like this, I like to try to save someone else some time!

Shoot me a comment if this helped you out!

–Josh

UniFi Dream Machine (UDM, UDM Pro, UDM Pro SE) admin lockout

I’ve emailed Ubiquiti support about this, created a forum post, included screenshots and verbose SSH client logs.   I’m writing this as I sit without access to a clients firewall because of this bonus feature in these products.

The result of my diving into the packets and testing thoroughly is that, whenever there is a failed SSH login attempt it causes the firewall to go into a “block any attempts” mode.   This is unlike any other server out there, which might rate-limit the offending connection or blacklist after so many failed attempts.    Ubiquiti products prevent any login, even legit connections.    The connection establishes just fine, but it just seems to drop.    So if you’re experiencing this — where any attempts to SSH into a firewall just end with a dropped connection, you may well be dealing with this yourself.

The only solution is to go to the firewall’s settings and modify the rule that you have for SSH forwarding.   You’ll have to lock it down to whatever IP address you’re coming from at this time, and then wait 5-10 minutes for the server to become accessible again.    Then going forward, if you don’t want to have to deal with this you’ll have to go into the settings each time and modify that IP to whatever your source is.   

Here’s hoping that they fix it sometime soon.   It always gets me at the most inopportune times, last time I did not have any UI access due to the internal web server failing to communicate.   Also, the firewall was showing “offline” on the UniFi management portal.  So I was left to repeatedly click to attempt the connection until finally I was able to get a connection in.

If it’s not clear, the reason this happens is because there is some random port-scanner that is trying to use JimBob to log in.   Result: everyone locked out for a period of time.     Could be a bad scenario if this begins to be used intentionally as a type of DoS tool.  

Oh, and the screenshot I included is another fun variant of its’ behavior.   It will finally connect after 150 tries, only to hang on the login banner.   Sending a Break here causes the session to terminate (unlike Break at a shell prompt).    So yeah, pretty neat all around!

–Josh