Some sort of reverse proxy could do that, based off of hostname/url in some way. I know Varnish and HAproxy can do it, just setup your own internal/fake domain (or a real one, if you want) and then access the various things via hostnames you create, and let the proxy sort out how best to route the request.

@McFuzz:

Hi all,

I recently started experiencing a weird issue pertaining to logging in to the UI from a WAN connection (i.e. hitting the external address of the firewall). When I try to, browsers indicate that a secure connection could not be made - specifically, this is what Chrome (amongst others) spits out:

Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

A reboot of pfSense appears to fix the issue, but only temporarily. Restarting the webUI does not resolve it. For what its worth - I can access it just fine from within the LAN.

Any ideas?

I'm running 2.0.1 if it matters…

Thanks!

I too am encountering this issue and it's making me crazy.  Reading forums trying to find a clue.  I can access all of my pfsense functionality but ONLY from my LAN behind the PF box.  In fact, it is even allowing me to RDP from the internet into one of my PCs behind the box to access PF webGUI.  How strange is that?

If it works, feel free to fork, edit, and submit a pull request in github.

https://github.com/bsdperimeter/pfsense/

EasyRule automatically does a filter reload when called.

thanks for the github link that makes my life a little bit easier ;)

@knotbeerdan:

Im running version Version 2.0.1

the command I am running to apply the patch is

patch -p0 -i Widget.Firewall_Logs_Widget_Filtering.patch

And I receive the following output.

Hmm...  Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- /usr/local/www/widgets/widgets/log.widget.php      2011-09-13 13:02:36.000000000 -0700 |+++ /usr/local/www/widgets/widgets/log.widget.php.Firewall_Logs_Widget_Filtering.Patched       2012-06-21 21:42:05.000000000 -0700 -------------------------- Patching file /usr/local/www/widgets/widgets/log.widget.php using Plan A... Hunk #1 failed at 41. Hunk #2 failed at 73. Hunk #3 failed at 112. Hunk #4 failed at 138. 4 out of 4 hunks failed--saving rejects to /usr/local/www/widgets/widgets/log.widget.php.rej

I havent customized anything outside of the GUI, though I did change my theme to the_wall, would that make a difference?

No changing the theme shouldn't make a difference.  However logging in as root, so you have full permissions would.

Not sure what causes the problem but changing the GUI from http to https did the trick for me. When I first changed the IP from 192.168.0.1/24 to 192.168.0.5/20 with the GUI set for http and ran a tcpdump on the inside interface, I noticed that when I tried browsing to http://192.168.0.5 I wouldn't get any packets other than replies from 192.168.0.1 on https so i'm not sure what was up with that. This was a replacement for a production firewall though so I didn't have time to play but i'll see about recreating it on a fresh install sometime this week hopefully.

To answer the question though. No, changing the IP and doing a reboot didn't solve the problem.

Mark

Under the "<webgui>" section in the config.xml, I changed the "<protocol>" from http to https and was able to access the test box GUI.

I changed the protocol back to "http" in the GUI, and did not experience the issue again.

I have no clue as to why that happened.</protocol></webgui>

Ok thank you for your help.

Cheers!

Try limiter associated with firewall rules on lan

Hi, guys I got this fixed. On internet explorer click Tools - Developer Tools - Click on Script - Click Start debugging. After debug is complete, restart internet explorer and try visiting your webpage again. Good Luck.
;)

Thanks for the info!

Ah …  :-
I use both upcoming releases in the lab and I should have mentioned that 2.1 did not have the problem.

@jimp:

No, you're just lucky that helped at all.

Your CF is about to give out entirely, buy a new one, don't keep reflashing one that's already worn out. It is going to fail on you very, very soon.

Thanks for your advice - I bought a new one and reinstall everything on it - working fine - but have not tried the OpenVPN yet.

@podilarius:

Not entirely sure, but I would start with the system logs looking for any errors.

Thanks, It ended up being a package not loading correctly i had to reinstall it then all was fine.  Thanks again.

hmm.  I remember a bounty a created for this several years ago. :-)  A paid device will most likely mean full support for it.  That will be nice.