I have updated my web server domain in pihole.toml to a new one, however, when trying to go to it using the new domain, I get the error ERR_TOO_MANY_REDIRECTS.
This may be a simple browser caching issue. Clearing redirects from clients is really hard and typically involves cleaning browsing history (please consult Google for your particular OS + browser combination). I'd first try using a browser on a device that has not used Pi-hole before. A private browser window may work as well.
Hi. I tried a browser that has not accessed it in the past, and the same error occurs.
Please set debug.api and debug.webserver to true and check out both FTL.log and webserver.log in /var/loh/pihole when this happens.
Please see web log here: Pastebin.com - Locked Paste
FTL Log: Pastebin.com - Locked Paste
I have messaged you the pw
Okay, this is going to be a long one. Even when you provided only minimal details, I found out a lot about your internal at home network. First, I do not see any redirecting going on in these logs but this makes sense when you reach the end of this post. Instead, many requests seem to work perfectly fine, e.g.,
https://xxx.yyy.ddns.net/admin/taillog?file=webserver
(xxx and yyy are removed by myself)
What is more concerning is that I am able to reach your Pi-hole myself over the plain Internet. Please don't do this and shut this down immediately. Pi-hole's web server - while being carefully tested - is by no means meant to be reachable from the outside. It should not be considered "production-ready" in the sense of being resistant against large-scale DDoS, etc. attacks.
Please don't assume your Pi-hole will not be found because hide it behind a domain - internet scanners scan the entirety of the IPv4 address space every few few days and put their finding publicly accessible on Shodan and similar services. I sent you a screenshot via DM that shows what they already know about your internal network, e.g. that you are also offering webmin, unifi and have a few ports (80, 443, 8443, 10000) open to the public.
You should instead immediately install a proper VPN solution. The Pi-hole documentation makes setting up a strong Wireguard server very easy. It can be used right-away with all kinds of clients (Linux, Windows, Android, Apple, ...) and comes with no noticeable overhead. It is just sooo much better than OpenVPN we used in the old days. Furthermore, it is actually only some one-time work and you will gain a lot by this. Not only that your services won't be accessible by anyone any longer, they also ensure that your entire traffic is always securely encrypted. I know, it is already encrypted to your Pi-hole when accessing via 443 but there is currently nothing that prevents anyone from MITMing you with your Pi-hole. Self-signed certificates are only a compromise.
Sorry, back to the real issue: I think this may be a cloudflare misconfiguration in your new URL. I say this because we see a certain pattern here:
When I try to access https://xxx.yyy.ddns.net I immediately get to your Pi-hole, when I repeat this over plain HTTP (http://xxx.yyy.ddns.net), your Pi-hole sends you to a different domain (let's call it https://dashboard.zzz.co.uk). So far, so good. You did not say this, but I guess this is the domain you set in pihole.toml. Anyway, when I try to access this domain, I do get another 308 redirection to the very same domain. However, what is interesting is the headers we are seeing: The redirection is over HTTP/2 (Pi-hole uses the much simpler HTTP1.1 protocol for redirections) and we also see a header server: cloudflare).
If the redirections are triggered by cloudflare, there is a misconfiguration somewhere over there. If they are indeed happening by your Pi-hole somewhere "behind" cloudflare, then your Pi-hole may not be receiving the URL correctly and - hence - thinks it needs to redirect. Such a configuration could be that cloudflare does all the HTTPS encryption work for you and then accesses you Pi-hole over plain HTTP, causing your Pi-hole to say "this is not okay, let's upgrade to encrypted" resulting in an endless loop with your current configuration.
There is a certain configuration to allow exactly this setup but as
- cloudflare is on the public internet, and
- your connection between cloudflare and your Pi-hole is unencrypted, and
- your Pi-hole shouldn't be reachable over the public Internet anyway,
I don't think this is what you will need.
Everything should be easily solvable by instead deploying a proper VPN solution and using this instead.
P.S.: Sorry if I got anything wrong here but my entire analysis above was done solely on knowing http://xxx.yyy.ddns.net and nothing more about your network. Everything else was obtained by querying your network and configuration as much as this is possible without authentication (which is, frankly, quite a lot). I will send you a few more findings non-obfuscated via DM.
1 Like
In case I did not make it clear in my mostly technical post above:
Please shut down your open DNS resolver immediately
An open resolver is a DNS server that's configured to accept queries from the internet. While it might seem like a useful feature, it can pose serious security risks.
The main reason why an open DNS resolver is problematic is that it can be exploited for DNS Amplification Attacks. This is a type of Distributed Denial of Service (DDoS) attack in which an attacker sends a small query to your DNS server, which then responds with a much larger packet of information. The attacker can use this to overwhelm and disrupt services on another network by directing a massive amount of traffic it can't handle.
Setting up a DNS server open to the public is indeed a significant undertaking - one that commands considerable resources at companies like Google, OpenDNS and others. Maintaining security and efficiency while ensuring that the server is not abused for malicious activities like DDoS attacks is not a trivial task. And there is a myriad of further potential threats.
The process is far more complex than simply implementing rate limiting. While rate limiting can help mitigate some types of attacks, it's not a comprehensive solution due to the nature of DNS traffic, which utilizes UDP packets.
Remember UDP is a connectionless protocol, meaning it doesn't require a handshake to set up a connection. This makes it fast and efficient for DNS queries, but it also makes it easy for attackers to use IP spoofing. IP spoofing is a technique where an attacker sends packets with a forged source IP address. This means that even with rate limiting in place, an attacker could potentially flood your server with requests that appear to be coming from many different IP addresses, bypassing the rate limits.
Moreover, these teams have to ensure the servers are compliant with various privacy and data protection regulations across different regions, adding another layer of complexity to the task. This can involve considerable fines on your personally, regardless that you are not running a business on this.
Not only can these attacks harm others, but they can also exhaust your bandwidth and system resources, affecting your server's performance. This will also quickly lead to your IP being blacklisted by networks and ISPs, preventing your legitimate traffic from being delivered and probably serious trouble with your own ISP. We have seen this quite a few times in the past years, IIRC think one users even got their contract terminated by their ISP because of "heavy misbehavior" against the allowed use of their cable connection. They had trouble getting a new contract because their ISP (I think it was Virgin Media) even informed other ISPs about this user. I think we have never seen him again....
If you need assistance or guidance in setting up a Wireguard VPN, please don't hesitate to ask. We're here to provide the support that you need to ensure your network remains safe and secure.
Thank you for your understanding and prompt cooperation.
Thank you for the really detailed reply, I appreciate it.
I have reverted the change and made it so the domain used in pihole.toml is now the old one ddns.net.
I have removed ports 80, 8443, 8581, 443 from port forwarding.
I already have the WireGuard VPN set up.
What I am finding now, I can still access pi-hole on my laptop, but when trying to connect on my iPhone, on 5G using the VPN, I am not able to connect?
Did you forward the Wireguard port in your router? Does the Wireguard app on your iPhone show data flowing in and out of the VPN during connection?
I do not have an iPhone myself but in the Android app it looks like this (my phone is set to German):
Yes. I can access other sites whilst using VPN just not my pihole
Have you tried also via the IP? If so, where does your Wireguard server run? On the same machine as the Pi-hole? This sounds more like a firewall issue,
I had some trouble getting Wireguard running, so I made some proposed edits to the guide. Maybe they'll help your firewall settings.