[SOLVED] webConfigurator do not answer IPv6 requests
-
Hi guys,
webConfigurator do not answer IPv6 requests. I can connect by IPv4 only, but my tunnel config has IPv6 addresses only. Please add a webConfigurator option to allow lighttpd to answer IPv6 calls on all chosen interfaces (i.e. WAN, LAN and GIF).
-
It answers IPv6 just fine. Using it all the time. You need to create proper firewall rules to allow access to 80/443 on your tunnel iface.
-
I can't even connect webConfigurator directly on LAN by IPv6. LAN has a rule to pass all IPv6 traffic. I can connect other services on pfSense box via IPv6 as SSH.
-
You are clearly doing something wrong…
$ sockstat -6 -l | grep lighttpd root lighttpd 31281 11 tcp6 *:443 *:* -
What do you suppose it is that he might possibly be doing wrong? haha
-
What do you suppose it is that he might possibly be doing wrong? haha
Considering the huge amount of information provided… I guess
-
If the rest of his IPV6 stuff is working, one might think he didn't select IPV6 in the firewall rules when he was allowing access to the GUI - Although, as you say, its all guessing.
Does the "Allow IPV6" button in the advanced > networking kill IPV6 everywhere if checked or just that IPV6 flowing through the WAN?
-
Thanks for the quick reply guys…
yes, My IPv6 setup is almost complete. Yes, "allow IPv6" is checked. Yes, running
sockstat -6 -l | grep lighttpdreturns wich lighttpd is listenning on tcp6, and yes, I receive a https response, but it gives me a blank page (sorry for not telling you this before…) ;D
webConfigurator was adjusted to answer only to https requests... and thanks to your quickly responses, I was urged to use a bit more of brain and matched the bug: it only happens when webConfigurator is setted up to https only and one tries to connect https via IPv6... it can be a Firefox bug, but I cannot test with other browsers right now.
-
Are you using it from within a VPN or SSH or something distantly or did you just forward open those ports on your WAN?
You mention a tunnel? Like a IPV6 tunnel broker like HE?
-
Just now I am accessing from inside LAN. When I chose HTTPS with default webConfigurator certificate, FF appears to get a blank page (or not get the page at all). I am trying to open the address
https://[myInternalUniqueGlobalAlreadyWorkingIP]:myport ```(a valid IPv6 address:port of course) But FF refuses to display the login page. It works as expected on my local https://192.168.xxx.yyy:pppp IPv4 address. -
Hmmm - No idea in that case.
-
Yeah, I'm surprised, IT IS A FIREFOX 23.0 bug. I could sucessfully open the webConfigurator page using Konqueror…
I'm scared... ???
-
Update: If you want to test your Firefox, try to open the address below (Google):
https://[2607:f8b0:4008:803::1015]
If you try http://[2607:f8b0:4008:803::1015]:443 Firefox says url is incorrect.
This behavior do not happen if you open IPv6 page by name (using DNS). Other browsers can open both addresses without trouble. Tested until Firefox ver 23.0
-
You sure? Cuz I love guessing wrong what might be wrong…
-
You sure?
Yes. This bug has only been known for 2,5 years, with the guys doing zilch about; looks like it actually got worse meanwhile and not displaying any error message at all. SSL cannot set exceptions on IPv6 addresses
Also, other stupid regression, causing this to fail altogether, not just with untrusted SSL cert: - Firefox nightly doesn't connect to IPv6 literal
The development is going pretty much downhill, with useless crap such as the new social API and buttons, instead of focusing in something useful.
-
Update: This issue was reported upstream:
https://bugzilla.mozilla.org/show_bug.cgi?id=903853
Crossing fingers to Firefox team to fix it as soon as possible. IPv6 deployment in my country is getting huge attention, as IPv4 blocks here are giving last signals of life… ;)
-
Hmmmm. Hopefully we can all go IPV6 soon, dump IPV4 before IPV9 comes out and then maybe Firefox would notice all the broken browsers.
-
Hmmmm. Hopefully we can all go IPV6 soon, dump IPV4 before IPV9 comes out and then maybe Firefox would notice all the broken browsers.
The guys are just "amazing". The bug's been there for ages, just regressing badly recently, making it much worse (previously you'd just get the usual self-signed cert nagscreen, but you could not add an exception for IPv6 literal. Now you get a blank page…) Instead of fixing the darned thing, the guys discuss that they "intend to discourage certificates that include IP addresses." Apparently realizing that the user is not in a position to do anything about whatever certificate that the admin decided to use is way above the guys' heads. Clearly, browsers are not there to browse websites any more, they are there to nag users with stupid warnings (self-signed certs are baaad, mkay... CNNIC one's rock though, that's what Mozilla trusts.) And this idiocy is not limited to Mozilla, e.g. Chrome won't let you browse local XML files, since XSL stylesheets are extremely "dangerous". They are much safer when downloaded from web, mkay, riiight!
-
I doubt its a bug. More likely its something designed to generate revenue by making people run out and grab "Good signed certs" that make pretty green banner colors when you browse to a site. Exploiting stupidity is a time honoured tradition. We all know that certs are so much more trustworthy when they were generated and signed by some yahoo you don't even know.
-
I agree with you both. Here government sites .gov.br are signed by a centralized government entity called "ICP Brasil". This entity is trusted, but browsers refuse to add it to your root cert list by unknown reasons. There are plenty of bug requests asking to add the ICP's root cert, but it seems it will never be done…