Debug upload port may be undesirable for some

I was looking into the problem with the debug upload. found the following in my firewall logs:


and many more…

pihole (192.168.2.57 and 2a02:1810:4d01:1902:4e0a:8fe6:95b0:e91a) tries to connect to bothouse.pi-hole.net, port 9998.
Evidently, this fails, my firewall doesn’t allow this. Is this a requirement for uploading the debug log?
NOT very happy, if it is a requirement, see here.

Could you not add a rule that allows that port for that domain only?

I could consider that, however before I do such a thing, I need to know what it is I’m connecting to and why the service (which service) is running on that port.

I could just as well ask you why you don’t run the service on a different, more common port. This would probably eliminate the problem for multiple users, as opposed to having every one add a firewall rule (if they even can ).

edit
just to find out if this the problem, I created a rule to allow this on my pfsense and tried to generate and upload a debug log.

[✓] Your debug token is: https://tricorder.pi-hole.net/s632j9vpgb

@DL6ER: you can use this log to check problems with the new core tweak/gravity_performance version.

This is probably the reason why many uploads fail. I strongly advise to change that port into something more common, to eliminate the need for all users to add such a rule.

You should consider to move the last 3 entries into a different post, ‘debug upload failed’.
/edit

Why does the port matter? Why does the service matter? If you don’t trust us, then you don’t trust us.

I looked over the volume of logs going in to tricorder, and the number of people stating they had issues with log uploads. So far in the few years that we’ve been using it, you are the first to mention the port.

Plus its TCP 9998 for crypted and 9999 for uncrypted outgoing.
Do you block all outgoing traffic except the ones you trust ?

In my personal opinion there is no need to change or fix anything here - especially not for home users.

Users with firewalls just have to open

tricorder.pi-hole.net, TCP/9998 (for encrypted debug log upload)
tricorder.pi-hole.net, TCP/9999 (for unencrypted debug log upload)

I don’t see anything strange, unusual or malicious.

On the pfsense forum (netgate), you can find a guide to setup a secure firewall. The basic idea is to block everything, than open only what you need. I only have 13 outgoing ports opened, no incoming ports.
This setup has been running for over two years, I’m very satisfied with it.
This of course implies you sometimes run into connection failures, every time this happens, a pro/con evaluation needs to be made. Sometimes it is possible/necessary to create a rule to allow specific source IP / destination IP / destination port.
I’m really not that interested in uploading debug logs, so the con side is winning -> no rule.
I only wanted to point out the port (9998) is probably the reason why some users have problems uploading a log, changing the port into something common would eliminate these failures, personally, I know what the problem is, that’s enough…

That would mean that every time you install software that needs to address a dpt port not on your trusted list will fail and you would have to open up every time.
So why not make an exception for Pi-hole too ?

Yep, correct assessment.
only pihole is allowed to use port 53
to download lists, port 80 and 443 are in the general allowed outgoing range.
I (and pihole) don’t really want/need anything else for daily operations.

port 443 in the general list is unfortunately unavoidable, pain in the as (DOH)

Well you’ve got the place pretty locked up tight.
Not what Joe Average got running :wink:

The reason the port are where the are:

tricorder:443 is the way developers access the site via https://github.com/pusher/oauth2_proxy and https://github.com/caddyserver/caddy. I can’t use that port for log ingestion, https://github.com/pi-hole/tricorder needs to sit on it’s own port.

2 Likes