Unable to Complete Setup

fefekrzr · January 20, 2025, 8:42am

If you’ve set up port forwarding, there’s generally no need to enable DMZ for your FreedomBox. Port forwarding is typically the preferred approach as it allows for more precise control over which ports are open. However, if you’re unsure about the specific ports to forward or encounter issues, using the DMZ option can serve as a fallback since it forwards all traffic to your FreedomBox. Just keep in mind that DMZ is probably less secure than targeted port forwarding.

Could you share the Diagnostics results for these services? Please make sure to redact any sensitive or identifying details (e.g., your domain name) before posting.

Shifthappens · January 20, 2025, 3:50pm

Hello @fefekrzr,

Thank you. During the initial setup, FB’s directions suggested enabling DMS. My ISP suggested using port forwarding instead for security reasons, but given the challenge with the first setup attempt I decided to enable DMZ. Later when I completed the port forwarding, per FB’s instructions, I didn’t see anything that said whether or not DMZ should still remain enabled. Hence, my question.

Sadly, no. I’m only able to go by memory at this time. Once again, I’m no longer able to access my FB either from the domain URL, FB’s IP, or direct connection (to monitor, keyboard, and mouse).

fefekrzr · January 24, 2025, 11:16pm

Any updates on this? Did you manage to regain access?

Shifthappens · January 25, 2025, 2:41am

Hi fefekrzr,

Thank you for following up.

I’ve re-flashed the SD card, and started all over from the beginning. Here’s where things stand.

Good News

My FB is now associated with my domain, and I’ve got the Let’s Encrypt certificate again. If anyone has trouble getting a certificate, I found the Let’s Debug page from Certbot’s website to be extremely helpful in pinpointing DNS problems.

Remaining Challenges

I've tried to install some applications. The only one "successful" so far is TiddlyWiki (TW). I say "successful" in quotes because I'm unable to create any wikis in FB when logged in as a sudo user. Here are error details:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/plinth/modules/tiddlywiki/views.py", line 53, in form_valid
    privileged.create_wiki(form.cleaned_data['name'])
  File "/usr/lib/python3/dist-packages/plinth/actions.py", line 73, in wrapper
    return _run_privileged_method_as_process(func, module_name,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/plinth/actions.py", line 134, in _run_privileged_method_as_process
    return _wait_for_return(*wait_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/plinth/actions.py", line 150, in _wait_for_return
    raise subprocess.CalledProcessError(proc.returncode, command)
subprocess.CalledProcessError: Command '['sudo', '--non-interactive', '--close-from', '21', '/usr/share/plinth/actions/actions', 'tiddlywiki', 'create_wiki', '--write-fd', '20']' returned non-zero exit status 10.

I’m currently using TW on my Debian desktop using node.js. So I may just use something like Syncthing for remote access to it instead. I just thought my other FB users might like to use TW too.

The 3 remaining app installation attempts have also failed — Postfix/Dovecot, Roundcube, and Syncthing. They all threw the same error below:

Error installing app: Apt command failed with return code: 100

Diagnostics just finished running, and is showing 2 errors:

Diagnostic Error 1

I don’t understand why it’s showing a domain resolution error. When I log into Cockpit, the Overview page suggests everything’s working fine and the “System is up to date.”

Question 1

If it can't resolve the deb.debain.org domain, wouldn't it be unable to update? 🤔

Diagnostic Error 2

Let's Debug Results

Let's Encrypt Status

Question 2

So why is Diagnostics saying it can’t access my domain, when I can via HTTPS, Let’s Debug found no issues, and I have the certificate?

Shifthappens · January 25, 2025, 7:52pm

Hello,

Update

I just tried installing another application, Nextcloud, and it too failed.

Additionally, today’s Diagnostics run resulted in the same two application errors mentioned above — Name Services and Let’s Encrypt.

fefekrzr · January 25, 2025, 8:53pm

Strange. If I’m not mistaken, that error code is from running Apt as an unpriviledged user. But if you were using an upriviledged user, you wouldn’t have access to installing apps.

Regarding the Name Services and Let’s Encrypt. There seems to be some problem with outbound traffic. The strangest thing is that the Pioneer at some point had access to the internet to obtain the certificate and install TiddlyWiki. Did you make any changes to your router after obtaining the certificate via the FreedomBox web interface and installing TiddlyWiki?

Shifthappens · January 25, 2025, 10:17pm

Hi fefekrzr,

Exactly! I’ve never even logged in to my FB as an unprivileged user.

No, I haven’t made any changes to the router after obtaining the certificate. I’m unsure that TiddlyWiki is completely installed. Like I said, I’m unable to create any wikis.

Update

After clicking on the (tiny) “Show verbose information” link on the Let’s Debug page results, I found this:

So I’m trying to enter the DNS record with my domain provider, but I’m unsure of how to correctly do so. I know how to enter DNS records, it’s the values I should put that I’m unclear on. In the Let’s Encrypt DNS-01 Challenge Types article indicates using a CNAME record is best for security, but fails to explain exactly how.

I understand that to mean I should enter another CNAME record that delegates answering the _acme-challenge subdomain to a validation-specific server or zone, but what value(s) should I give it? This is what I’m currently trying, with my domain as the value:

fefekrzr · January 26, 2025, 11:27am

Personally, I handle DNS for my FreedomBox using the included DynamicDNS client.

As fan as I understand, a canonical name record is used to map an alias to a canonical domain. I’m not sure that is what you need. Also, to me, this doesn’t sound like a problem with name servers pointing at your domain incorrectly, as I understood that you are accessing your FreedomBox using your external domain.

However, it does seem like your FreedomBox can’t complete outbound requests for some reason. We need to find out what happened that the FreedomBox lost access to the internet, as I understood you managed to obtain a certificate using the FreedomBox web interface’s Let’s Encrypt module.

Also, do you mind sharing the port forwarding rules you applied? That said, I would strongly recommend removing them for the time being and relying on the DMZ host option to see if the FreedomBox regains complete internet access.

Shifthappens · January 27, 2025, 3:29am

Hi fefekrzr,

Yes, I’m accessing my FB using my external domain. After more research, I’ve concluded the Let’s Encrypt verbose information indicates the certificate can’t automatically renew with the way it’s configured now.

I originally enabled DMZ. Then I made the FB’s IP address static, and applied port forwarding to my FB using ports 80 and 443. Then I disabled DMZ per your recommendation after I asked about still needing it when there’s port forwarding (earlier on this thread).

FB vs. Desktop Ping Results

Steps

Enabled DMZ.
Removed FB’s port forwarding.
Logged into Cockpit and attempted ping.
Opened terminal on my Debian desktop, which is connected to the same router as FB, and attempted ping.

Results from FB Cockpit

shift@doogle:~$ ping -c10 deb.debian.org
ping: deb.debian.org: Name or service not known

Results from Desktop

shift@debian:~$ ping -c10 deb.debian.org
PING debian.map.fastlydns.net (146.75.126.132) 56(84) bytes of data.
64 bytes from 146.75.126.132 (146.75.126.132): icmp_seq=1 ttl=58 time=18.9 ms
64 bytes from 146.75.126.132 (146.75.126.132): icmp_seq=2 ttl=58 time=20.9 ms
64 bytes from 146.75.126.132 (146.75.126.132): icmp_seq=3 ttl=58 time=18.8 ms
64 bytes from 146.75.126.132 (146.75.126.132): icmp_seq=4 ttl=58 time=20.2 ms
64 bytes from 146.75.126.132 (146.75.126.132): icmp_seq=5 ttl=58 time=19.3 ms
64 bytes from 146.75.126.132 (146.75.126.132): icmp_seq=6 ttl=58 time=20.3 ms
64 bytes from 146.75.126.132 (146.75.126.132): icmp_seq=7 ttl=58 time=19.0 ms
64 bytes from 146.75.126.132 (146.75.126.132): icmp_seq=8 ttl=58 time=19.4 ms
64 bytes from 146.75.126.132 (146.75.126.132): icmp_seq=9 ttl=58 time=19.3 ms
64 bytes from 146.75.126.132 (146.75.126.132): icmp_seq=10 ttl=58 time=19.2 ms

--- debian.map.fastlydns.net ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 18.832/19.533/20.918/0.661 ms

Question

Could having both the desktop computer and FB connected via Ethernet to the router adversely affect FB's ability to complete outbound requests?

fefekrzr · January 27, 2025, 12:22pm

I think we can set aside the possibility of the router being the problem for now. It seems more likely that the issue is related to the networking configuration of your FreedomBox.

Regarding your question:

In my experience, this is unlikely. For example, I have my Pioneer FreedomBox and several other devices connected to my router via Ethernet without any issues.

That said, we may need to investigate further to pinpoint the cause.

One more thing: could you share some details from the Networks page of your FreedomBox? That is, the Networks page in the System module of the FreedomBox web interface. Not Cockpit.

Specifically, I’d like to confirm a few things about your “FreedomBox WAN” connection:

Is it in the “Internal” firewall zone?
Is it set as the “Primary Connection”?
Are DNS servers configured for both IPv4 and IPv6?

Please ensure you omit any personally identifiable information when sharing these details. Let’s see if this gives us more clues to work with.

Shifthappens · January 27, 2025, 5:25pm

Hi fefekrzr,

Got it. Thank you.

Absolutely!

1. Is it in the "Internal" firewall zone?

Yes.

2. Is it set at the "Primary Connection"?

Yes.

Are DNS servers configured for both IPv4 and IPv6?

Yes.

Please let me know if you need/want anymore information.

jvalleroy · January 28, 2025, 1:21am

Could you please try the following?

ping 146.75.10.132

(This is the IPv4 address that deb.debian.org resolves to for me at the moment.)

Shifthappens · January 28, 2025, 4:51am

Hi James,

I’ve lost the ability to log into my FB via web interface — either using my domain, or myFB’s IP address.

Luckily, I was able to ssh in and successfully perform the pings per your request:

shift@doogle:/home$ ping -c5 146.75.10.132
PING 146.75.10.132 (146.75.10.132) 56(84) bytes of data.
64 bytes from 146.75.10.132: icmp_seq=1 ttl=53 time=63.6 ms
64 bytes from 146.75.10.132: icmp_seq=2 ttl=53 time=65.7 ms
64 bytes from 146.75.10.132: icmp_seq=3 ttl=53 time=64.4 ms
64 bytes from 146.75.10.132: icmp_seq=4 ttl=53 time=61.5 ms
64 bytes from 146.75.10.132: icmp_seq=5 ttl=53 time=62.8 ms

--- 146.75.10.132 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4020ms
rtt min/avg/max/mdev = 61.456/63.598/65.722/1.447 ms

Question

Since pinging deb.debian.org from FB failed, but pinging their IPv4 address directly succeeded, does it mean it’s a DNS error?

Also, the results from the latest “deb.debian.org” ping test says the name resolution error is “Temporary.”

freeadmin@byegoogle:/home$ ping -c5 deb.debian.org
ping: deb.debian.org: Temporary failure in name resolution

Update

I also found this after exiting FB and using it's FB's IP. It explains why I can no longer access FB via web interface, but I don't know why ports 80 and 443 are now closed.

shift@debian:~$ nmap #.#.#.#
Starting Nmap 7.93 ( https://nmap.org ) at 2025-01-27 23:55 EST
Nmap scan report for #.#.#.#
Host is up (0.023s latency).
Not shown: 978 filtered tcp ports (no-response), 19 filtered tcp ports (host-unreach)
PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  closed http
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 13.46 seconds

jvalleroy · January 28, 2025, 12:26pm

Yes, it looks like a DNS error. You can confirm using the dig command:
dig deb.debian.org
This should also list the DNS server that is being used.

Shifthappens · January 29, 2025, 6:21pm

Hi James,

Here are the results:

shift@doogle:~$ dig deb.debian.org
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> deb.debian.org
;; global options: +cmd
;; no servers could be reached

jvalleroy · January 30, 2025, 10:58pm

It looks like your system is configured to use a local DNS resolver (probably systemd-resolved), but it is either not installed or not running.

Could you please share the results of the following commands?

cat /etc/resolv.conf

ls -al /etc/resolv.conf

apt policy systemd-resolved

systemctl status systemd-resolved

fefekrzr · January 31, 2025, 12:34am

I may be venturing a bit outside my expertise here, but based on what you’ve described, it seems like you might be dealing with two issues—which may or may not be related. Some ideas and steps you could try.

DNS Issue

It looks like dig is attempting to reach a local address, which appears to be related to systemd-resolved. This might be the root of the problem if systemd-resolved is inactive for some reason. Check the status of systemd-resolved using the following command (you may need to use sudo):

systemctl status systemd-resolved

Web Interface Issue

The problem with the web interface might be related to the Apache web server. To check if Apache is running properly, try the following command (again, using sudo if necessary):

systemctl status apache2

If the service isn’t active or running, that’s likely the cause of the web interface issue. You might need to inspect the logs for Apache to narrow down the problem further.

I hope some of the suggestions help you in narrowing down the problem. Also, if you could share the logs for those two services, we might find something to work with, hopefully with Apache, so that you regain access to the web interface.

fefekrzr · January 31, 2025, 12:36am

Oops. I had been trying to write my message for a few hours. But I have kids so, it’s very difficult. Sorry about the repeat of jvalleroy’s suggestion. I hadn’t refreshed. Check Apache though.

Shifthappens · January 31, 2025, 2:19am

Hello,

Update

After finding a similar problem described and solved on the Debian User Forums: DNS Unreachable, I ssh’d into my FB and found the following:

File Contents: /etc/resolv.conf

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search hsd1.fl.comcast.net

File Contents: /run/systemd/resolve/stub-resolv.conf

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search hsd1.fl.comcast.net

resolvectl status Results

shift@doogle:~$ resolvectl status
Global
          Protocols: +LLMNR +mDNS +DNSOverTLS DNSSEC=yes/supported
   resolv.conf mode: stub
Fallback DNS Servers 1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google 1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2001:4860:4860::8888#dns.google
                     2606:4700:4700::1001#cloudflare-dns.com 2001:4860:4860::8844#dns.google

Questions

Since the symlinks between /etc/resolv.conf and /run/systemd/resolve/stub-resolv.conf appear fine, should I change to a nameserver not run by my ISP (Comcast)?

If so, should I follow the steps as outlined in the aforementioned Debian User Forums: DNS Unreachable post — delete the /etc/resolve.conf file, and replace it with a new one I can edit to use a different namerserver?

Shifthappens · January 31, 2025, 2:29am

Hello James & fefekrzr,

I too have been working on this the last couple of hours, and didn’t see your replies until after I’d entered my post. We were thinking along the same lines though.

I’m running the commands suggested by James, and will reply with the results when it’s done. It keeps repeating what looks like the same message, so I may have to stop it manually.