Hello everyone,
First of all, if you’re willing to read through this, I thank you profusely. What I’m attempting seems like quite a complicated configuration.
Here’s my problem: I cannot seem to reach my Pi through any external ip or DDNS service, and therefore cannot configure Let’s Encrypt for any service. Here’s all the relevant information I can muster:
For some reason, my ISP (or my router?) seems to assign the same static IP to all devices. This might be key to solving my problem, but I haven’t figured out how to make it assign different IP addresses to different devices. My computer, my phone and my Pi all return the same address.
My router is running OpenWRT, has assigned a static local IP address to my Pi and SHOULD be correctly configured to port forward port 80 and port 443 on the Pi. However, when I port-check them, the connection is unreachable on my (shared?) ip address.
On the router, I set the Pi’s local IP address to act as DNS server, as it is required to make Pi-Hole work.
I configured Pi-Hole to act as DHCP server and it seems to be working without trouble. Might this be the cause of some problems? Should I somehow port-forward here too?..
I configured a No-IP account, and pointed it to my (again, shared?) static ip. I then set it up on the Pi through dietpi-config. Everything seems to be in order here, as “noip2 -S” returns correct information.
Trying to connect to any service on the ddns address (e. g. *.ddns.net/admin for pi-hole, or *.ddns.net/nextcloud for nextcloud) does not work. The browser starts to connect but then stalls.
What am I doing wrong? Is there something wrong with the port forwarding? is this possible at all or are some of these services incompatible with one another?
For some reason, my ISP (or my router?) seems to assign the same static IP to all devices.
You have a router, right? The ISP usually only gives you one public IP that reaches the router in the first place. The router can then forward requests to local network devices.
The router is responsible for local IPs addressed to the local network devices. The router should apply individual IPs for each device. Please assure that it’s DHCP functionality is enabled and all devices connect to the network via DHCP. All devices with same IP MUST fail, since how should anyone know where the requests should be sent to, if more than one device has this IP. The network is practically down in this case. So please fix this first, so that every device has it’s own IP.
On the router, I set the Pi’s local IP address to act as DNS server, as it is required to make Pi-Hole work.
Note that the Pi in this case (respectively Pi-hole) requires an external public DNS server to send requests to. Did you configure Pi-hole accordingly and is possible from the Pi and any other local device to resolve hosts, e.g. ping dietpi.com?
configured Pi-Hole to act as DHCP server and it seems to be working without trouble. Might this be the cause of some problems? Should I somehow port-forward here too?..
Indeed there must be only one DHCP server in the network, either Pi-hole or the router. Since the Pi has most properly other things to do, I generally would leave this task to the router. Port forwarding and DHCP has nothing to do with each other. Port forwarding needs to be done in+from the router to the Pi (80 => 80 on Pi + 443 => 443 on Pi) while the Pi can independently from that act as DHCP server.
So yeah I would:
- Disable DHCP server in Pi-hole
- Verify a public DNS server is configured there. Usually I would use the one that was pre-configured in your router, since this is most likely a local one provided by your ISP that is close to your home (thus fast).
- Enable DHCP server in router
- Make your Pi (and all other devices) connect via DHCP client.
- Verify that all devices get individual IPs. Your router should have a network overview that shows connected devices and their IPs.
- On the Pi, verify that ping dietpi.com (thus name resolving) works as well as pinging the router and/or any other local network device.
- Then you in router set Pi local IP as DNS server and verify that ports 80 and 443 are forwarded to the Pi as well.
Thank you very much for your reply! I’ll go through it step by step.
Of course. The Pi correctly pings dietpi.com, as internet connectivity is indeed working on all devices.
Indeed there must be only one DHCP server in the network, either Pi-hole or the router. Since the Pi has most properly other things to do, I generally would leave this task to the router. Port forwarding and DHCP has nothing to do with each other. Port forwarding needs to be done in+from the router to the Pi (80 => 80 on Pi + 443 => 443 on Pi) while the Pi can independently from that act as DHCP server.
I configured the Pi-Hole to act as DHCP server while disabling the router’s DHCP server. I’ve been told to do so in a guide in order to enable Pi-Hole’s ad blocking functionality, but you’re making me doubt the need to do such a thing. In any case, only one server is active, and internet connectivity works, with the Pi doing the job of assigning the various local IPs. Nevertheless, I decided to heed your advice and disable the Pi-Hole’s DHCP server, re-enabling the router’s. so:
- Disable DHCP server in Pi-hole
- Verify a public DNS server is configured there. Usually I would use the one that was pre-configured in your router, since this is most likely a local one provided by your ISP that is close to your home (thus fast).
- Enable DHCP server in router
- Make your Pi (and all other devices) connect via DHCP client.
- Verify that all devices get individual IPs. Your router should have a network overview that shows connected devices and their IPs.
- On the Pi, verify that > ping dietpi.com > (thus name resolving) works as well as pinging the router and/or any other local network device.
- Then you in router set Pi local IP as DNS server and verify that ports 80 and 443 are forwarded to the Pi as well.
Done. The router still points to the Pi-Hole’s local IP address as DNS server, which in turn has configured 2 external servers (OpenDNS and Mullvad). I am now using the router’s DHCP.
The “same IP” problem is still there. When I say that I get the same IP on all devices, I really mean the external IP. As in, when I use “curl ifconfig.co” on the Pi and when I go to whatsmyip.org on my phone or computer, the exact same address is returned. I can still reach different machines using the LOCAL ip addresses (192.168.1.X), but not the external addresses (79.x.x.x) or the DDNS service. Checking the port with this configuration still fails.
Here’s something else that I thought might be relevant: I might not be the “primary” router. My router is connected through a LAN port in the wall (it’s a TP-Link TL-WR841ND). The place I live in has a fiber “business” infrastructure, with other machines doing some more routing in the background. That might explain the shared IP addresses, as well as the difficulty in port forwarding: might there be ulterior firewalls?
TheCheshireMan
Ah okay, it is exactly intended that you just have one external IP. This is the idea behind a NAT:
- Request from within your local network are send out to the www as requests from the router itself. So remote hosts only see your router (and its one external IP) and never any individual local network device. So this then has kind of a firewall functionality since external hosts can never access local devices directly.
- For this reason the port forwarding is required. If an external host wants to access a local server, you need to tell the router that if it receives a request on a specific port, that it should forward it to the desired local server.
- So as all devices have an individual local IP, everything is as desired.
Here’s something else that I thought might be relevant: I might not be the “primary” router. My router is connected through a LAN port in the wall (it’s a TP-Link TL-WR841ND). The place I live in has a fiber “business” infrastructure, with other machines doing some more routing in the background. That might explain the shared IP addresses, as well as the difficulty in port forwarding: might there be ulterior firewalls?
Indeed that sounds like the source of the issue. It depends now how this 1st layer network is build up, if the IP address you see (79.x.x.x) is actually a shared one for the whole 1st layer network or at least this directly points to your local router. And yeah then the question is if incoming requests on port 80/443 are blocked by a firewall in the 1st layer gateway.
You could check your routers external IP in the router GUI and compare this to the IP that you see when asking e.g. whatsmyip.org, to verify that at least your router is directly accessible from www.