Hi,
I wanted to test my DNSSEC and it doesn’t not work (Turris 3.9.6 here). I flashed fresh OS not so long time ago with medkit and i didn;t check it since then. Now I see it doesn’t work.
On DNS page in Foris config page I do get this:
Can someone help me debug/fix this?
So, all the three checkboxes are unchecked, test is stuck in “loading” stage, but otherwise DNS does work with that settings?
There are many other external superficial checks for DNSSEC validation, e.g. directly on https://nic.cz
@vcunat nic.cz says it works:
Your Internet connection
Protected by DNSSEC
Not connected using IPv6
Not in a project FENIX network
Here is log: https://pastebin.com/raw/SWPJtwZ0
EDIT:
I also checked with that addon:
And it also says it works.
Hi @AreYouLoco,
Did you access Foris through https? I had the same problem as you, just use plain http and the tests will work.
I have a the same problem with the latest firefox. There was a problem with websocket traffic (port 9000 if i remember correctly) which was blocked. Try connect to router via https and this port and confirm security exception (there is a self signed cert) and recheck dns check page again.
For me the same behauviour, even for http, even I confirming the certificate before. But I am on 3.9.1 Turris OS, and 443 redirected to 8443 if that matters. Fortunatelly, you can run check_connection through SSH. I remember, that Foris GUI works before, so that comes with the new Foris stuff…
I have the same problem, works over HTTP, does not work over HTTPS. Turris OS 3.9.6.
Did you try port 443 or 9000? Because you must confirm security exception also for the port 9000.
i just checked via CLI:
root@turris:~# check_connection
Pinging $OTHER_IP_FROM_MY_ISP_HERE$ … FAILED
IPv4 Gateway: FAILED
IPv4: FAILED
IPv6 Gateway: FAILED
IPv6: FAILED
DNS: FAILED
DNSSEC: FAILED
It’s weird cuz I can ping manually all of the IPv4 addresses in the check_connection script and I do get response.
When I tried again in foris webinterface (HTTP) I do get error now instead of being stuck on loading:
Obviously, since I can reply to that topic, my internet connection works just fine.
@sid how do I do that? I thought that you make a exception in browser for a certificate not for the port.
Hey guys,
I have discovered some bug in that test as well some weeks ago. Feel free to join me in this issue I raised on Gitblab.
Even though I have to provide you with small note: I found similiar problem, not the same. But it is the same backend, so you could output your experience and needs there.
Don’t know if the same problem exists for another browsers but for firefox it seems that this bugreport is relevant https://bugzilla.mozilla.org/show_bug.cgi?id=1187666
@sid I deleted the exception rule, tried to connect using workaround described in that bug report (mentioned by fresheneesz) and I cannot connect on port 9000 I do not get prompt to add security exception. So it might be related to that bug. could someone not using firefox elaborate?
I had this problem when I had to factory-reset my Turris 1.0 after I completely botched its config and wiping it seemed easier than fixing it. The problem was identified by the NIC.CZ helpdesk to originate in expired certificates in the freshly wiped router, and it corrected itself after it self-updated a few hours later. Until then I just used the assigned DNS servers from my ISP, after update I switched back to NIC.CZ’s DNSSEC servers and had no problem since.
Could you do a
cat /etc/resolv.confIf it is 127.0.0.1, change it to for example 8.8.8.8 8.8.4.4
Then test it again, if the resolv.conf is 127.0.0.1, then PROBABLY that may be the problem.
Hi @Big_boss thanks for the idea, I had my resolv.conf pointing to 127.0.0.1 (I think it’s turrisOS default) but still:
cat /etc/resolv.conf
search lan
nameserver 127.0.0.1
I have change it then to:
search lan
nameserver 208.67.222.222 208.67.220.220
(I don’t like to use google)
Still same error via http and stuck at loading via https.
Oke, to be very sure. Just for this test, change it to that of Google, then DIRECTLY after changing it, give a
ping www.microsft.comIf it does not work, do a
cat /etc/resolv.confBecause it just might be, that you just changed it, and it automatically changed back to 127.0.0.1 again. Let me how it went.
I found next one strange think:
Under http there you should test the DNS and DNSSEC sucessfully just once in approx. 5 seconds. If you perform test faster, the result will be ERROR. I am able to get one sucessfull test answer followed by two DNS/DNSSEC errors. I did tried that many times.
I confirm also the HTTPS will break the functionality.
For those who doubt whether their settings or the “web app” is at fault, you may try the corresponding check_connection command over ssh. No case of “stuck at Loading…” I’ve heard of so far was confirmed to be a real DNS problem.
Hello,
I’m kind surprised that here we’re mixing up things together.
If you’re using the latest version, which is 3.9.6 and you’re using https then as you an added exception for https (443) you need to add the exception for WebSocket (9443) as well.
This is not new and it is even written in Errata and the post, where it is explained is currently in Czech, but I tried to use translator and it’s not so bad and you will understand it.
If it shows Loading… on http then my experience with this issue is that you’re trying to connect to your router from outside (I don’t mean VPN) and you don’t have enabled port for WebSocket as well.
If it shows Error then I recommend using check_connection, which doesn’t work as @AreYouLoco said and I wonder why there is $OTHER_IP_FROM_MY_ISP_HERE$, so it seems that this could be culprit why it doesn’t work. Can you tell me what did you change?
In Turris version 3.10, which is currently in RC the WebSockets listen on the same ports as http/https.