WebGUI redirection with IPv6 tunnel? [SOLVED]
Ashansol last edited by
I'm not sure if this post belongs here or in the IPv6 board. But I think my issue relates to both.
So, prior to enabling a Hurricane Electric IPv6 tunnel, my pfSense box automatically redirected any web request to the webGUI. So if i directed my browser to "router.example.com" I would be redirected to "https://router.example.com:4430. After installing the IPv6 tunnel (working perfectly as far as i know), the webGUI no longer works. If I type router.example.com, it stalls. if i type router.example.com:4430 it tells me it's an error (unencrypted request). So now, to access the webGUI I have to specifically type "https://router.example.com:4430" to connect.
It's not a huge deal. probably more secure if the https port is unknown to outsiders. I'm just curious why it suddenly stopped working.
I have it set to accept any traffic (webGUI redirect option unchecked - description says unchecked allows access to webGUI regardless of port or protocol).
To reiterate, I can access my box, I'm just curious why it stopped redirecting requests to the proper port/protocol.
So I have a HE tunnel.. And I have my webgui listen on 8443…
Is your router.example.com some public name that could be resolving to your wan IP?
As to your unencrypted request that would have to do with the HTTP Strict Transport Security that would be sent unless you disabled that.. And issue with your browser. What browser are you using? But HE tunnel should have zero to do with this.. My guess is just coincidence as you had just brought up the tunnel when you noticed whatever issue your having..
My guess your issue has more to do with HTTP Strict and your browser remembering bad site.. And time out or error is because your going to pfsense IP via port nothing listening on, ie old 443, etc.. You would be able to clear bad strict cache here https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/
I see the same sort of problem if I go to just http://sg4860.local.lan - but notice when get the timeout on the page is because it tried to go to https:/sg4860.local.lan/ and not the :8443
See how when put in the name in browser lots of old sites come up, but even when I specifically put in http://sg4860.local.lan it wanted to just go to 443 and not 8443... This is most likely your same issue... Clear your HSTS setting in your browser and then try it..
edit: So I had to close my browser after clearing up the cache issues with my own site since I had recently changed to 8443 from default 443 and lots of other changes.. bring up HE, etc. etc. Since this is my new sg4860 box ;) Anyway... Now after cleared up the site history and hsts settings in firefox.. You can see now when I put in just name in browser it still lists sg4860 there with https and 8443 at the bottom... I thought I had said forget the whole site, and delected old sites with that name and IP, etc. Prob have to flush the whole thing if you still run into problems.. But now you can see after I did a bit of clean up on the browser caching for hsts it redirects correctly..
If you still have issues do the manual menthod of editing the sitesecurityfile in your profile.. See 3rd pic showing sg4860.local.lan in this file... Find your fqdn you are using and clear any that point to fqdn or IPs that you use to go to pfsense webgui
Ashansol last edited by
Thanks for the reply!
To get it working, I had to flush the firefox settings as you suggested, but I also had to toggle the HSTS setting in pfSense. Prior to doing that, I tried the following:
Change back to standard port (443): worked without changes.
Turned off IPv6 completely: worked without changes.
Changed back to 4430: failed until I turned off HSTS, cleared firefox, and re-enabled HSTS.
I suspect there is a hidden HSTS rule addressing the redirect that didn't get created for the HENETV6 tunnel (or perhaps the underlying GIF interface) when I first set it up. By turning HSTS off and back on, the rule was correctly created for the IPv6 tunnel interface.
Again, thanks for pointing me in the right direction!
Why would you think there is a rule for the tunnel interface? You would never hit that address.. You might hit the ipv6 address you put on your lan, but why would you ever be hitting the transit IP? That is in the tunnel??