Hello. I have a dynamicDNS service that provides me with a domain (xxx.xyz.com) that I can use to access my web server from the WAN. However, if I type "xxx.xyz.com" from within my local network, I get redirected on the router's login page and not on the piholes webserver which is hosted at local ip 192.168.1.199.
I understand that to solve this issue I need to enable nat hairpin, which my router doesn't support. So I added a DNS entry in pihole's page that redirects xxx.xyz.com to 192.168.1.199. This solves the problem from within the NAT, however I am no longer able to connect to my webserver from WAN since xxx.xyz.com redirects me to 192.... which obviously I can't access from WAN.
In short, I wanted to create a static DNS entry that only works when I am connecting from within 192.168.1.0/24 and 10.6.0.0/24 (the latter is my wireguard subnet).
My setup is as follows:
-The router has as only DNS the raspberry hosting pihole
-The pihole has unbound (127.0.0.1:5353) as upstream dns solver.
-The DDNS is set up and managed throught the router's native GUI.
A public DNS server wouldn't return a private IP address for a client connecting through public Internet. That private IP is only known by your Pi-hole.
Your local private IP could only be returned if that client would request resolution of your xxx.xyz.com domain via your Pi-hole.
If it is able to do so, it should be connected as a VPN client, and if that's the case, it should be able to access private address resources from within your network as well.
If it cannot, your VPN client may not be properly configured.
Right now I am connected via VPN. If I type 192.168.1.199 I can correctly see the apache2 welcome page, and if I type 192.168.1.199/admin I can successfully see the pihole web interface. However, if I type xxx.xyz.com (while still being in the VPN), I get the router's login page.
I would like to have a way of typing xxx.xyz.com (from within VPN/LAN) and be redirected to the pihole webpage instead of the router login page. I tried to solve the problem by creating a static DNS entry on pihole webpage but then the xxx.xyz.com site becomes unreachable from the WAN since it gets redirected to 192.168.1.199
Let me explain from the beginning:
My home ip address is 151.x.x.x and this ip is correctly linked to the dynDNS (if I ping xxx.xyz.com I get the 151... address).
Scenario 1: I am inside my home (or inside the VPN), I type 192.168.1.199 and I get the apache [i have migrated pihole from lighttpd to apache, but this is irrelevant] welcome page. I type xxx.xyz.com, I get the router page.
Scenario 2: I am outside my home, connecting from a public wifi. I type xxx.xyz.com and I get the apache welcome page.
Scenario 3: I have added a DNS rule (in the hosts file of the pihole machine) that resolves xxx.xyz.com to 192.168.1.199. From inside my home, typing xxx.xyz.com redirects me to 192.168.1.199 and this is fine. From outside my home, typing xxx.xyz.com gets me nowhere.
I would like to be able to always typ xxx.xyz.com, wherever I am, and always land on apache webserver which would also allow me to access pihole web panel.
The reason why I posted this issue here is that since pihole acts as a DNS resolver, I think that in order to achieve my goal I need to act on the DNS side.
I am not able to solve this issue with NAT loopbacking because my router doesn't support NAT loopback.
You already did what can be done on the DNS side by creating a local DNS record.
There is no redirection involved here.
A local client is requesting an A record for xxx.xyz.com, and your Pi-hole answers the A record you've defined for it, i.e. 192.168.1.199.
A machine on a network outside your home is asking a public DNS server to resolve an A record for xxx.xyz.com. Your DynDNS setup should ensure that this is answered with a public IP address of 151.x.x.x as configured by you.
If it doesn't, either your DynDNS configuration does not return the correct IP, or your client may be caching a previous result, or your description may yet not include some relevant configuration details.
Run from a client (preferably not a smartphone or tablet) that is having difficulties resolving xxx.xyz.com via a Scenario 3 WAN connection, what's the output of:
nslookup xxx.xyz.com
and
nslookup xxx.xyz.com 1.2.3.4
where 1.2.3.4 is a substitute for the DNS server's public IP address of your DynDNS provider.
I am terribly sorry: I forgot I had copied some apache2 VH config that was intended to redirect to the https version of the site and that was causing problems. Clients were successfully connecting to the apache server, which unfortunately was redirecting to the https://192.168.1.199 address and that's why I couln't figure out why external clients were going to https://192.168.1.199. I am terribly sorry for having wasted your time.
However, the NAT loopback problem persists: if I am within LAN/VPN and I try to go to https://xxx.xyz.com I get the router's login page.
It seems that the only solution would be to ask my ISP for a static IP address, which would solve entirely the problem, right? Or is there some way I could fix this with a router that is incapable of nat loopback?
I don't think that a static IP would change anything.
NAT-hairpinning would have been required for a local client communicating to another local machine in your local network via your router's public IP address (where your router would determine which local machine to forward traffic to by the port used for communication).
You've eliminated the need for hairpinning by configuring Pi-hole as your local DNS resolver to return the local private address directly - your router's NAT isn't involved here anymore.
You should try to find out what is causing your issue before considering to change contractual obligations with your ISP.
From your description, I'd think your setup should be fine as it is.
A possible remaining area of conflict:
Some routers may prevent a DNS reply containing a private IP address if received from a (public) upstream DNS server. This is a security measure against DNS Rebind attacks. DNS Rebind Protection may occur if you'd configured your router to use Pi-hole as its sole upstream DNS server (as opposed to distributing Pi-hole as local DNS resolver via DHCP).
That said, I don't think it's likely that happens in your case, as that usually wouldn't return the IP of your router (which would give you the login page via port 80), but just drop the reply.
Still, you could check whether you can define an exemption for your xxx.xyz.com / 192.168.1.199 host for your router's DNS Rebind Protection.
Well, just as a good morning now I am trying to connect to xxx.xyz.com/151.... from an outside network and the page gets stuck loading and I haven't done anything at since last night to the raspberry. The DynDNS is still pointing to the correct IP since I can enable the vpn which has xxx.xyz.com:51820 as endpoint. From within the vpn the apache server is perfectly reachable.
The whole reason I am considering getting a static IP, which I don't think would take any change of contract, is that I need to be able to share files to people outside my VPN network.
I am truly going crazy, and this whole setup is tree-days old since I already had this problem on a previous installation of pihole/unbound/wireguard. I have sent you a PM with the actual dyndns domain, and now i will post some configuration files (keep in mind I have been changing the config files often, and have tried virutally all options)
the DynDNS is set up at the router admin panel, so it is expected to always be working.
/etc/apache2/sites-enabled/000-default.conf
ServerName xxx.xyz.com
<VirtualHost *:80>
# Redirect "/" "https://192.168.1.199/"
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
Alias /admin /var/www/html/admin
<Directory "/var/www/html/admin">
AllowOverride None
Options None
Order deny,allow
#Allow from 192.168.0.0/24 localhost 127.0.0.1
Allow from all
</Directory>
</VirtualHost>
<VirtualHost *:443>
#ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLCertificateFile "/etc/ssl/certs/certificate.crt"
SSLCertificateKeyFile "/etc/ssl/private/private.key"
</VirtualHost>
/etc/unbound/unbound.conf.d/pi-hole.conf
server:
# If no logfile is specified, syslog is used
# logfile: "/var/log/unbound/unbound.log"
verbosity: 0
interface: 127.0.0.1
port: 5353
do-ip4: yes
do-udp: yes
do-tcp: yes
# May be set to yes if you have IPv6 connectivity
do-ip6: no
# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: no
# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
root-hints: "/var/lib/unbound/root.hints"
# Trust glue only if it is within the server's authority
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no
# Reduce EDNS reassembly buffer size.
# Suggested by the unbound man page to reduce fragmentation reassembly problems
edns-buffer-size: 1472
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 1m
# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10
I would like to add that i could theoretically solve the problem by leaving all my devices always connected to the VPN, and using the local ip (192...) in any situation. however I was wondering if my internet would be slowed down or hindered in any way if I use wireguard while alreasy being connected to my home network.
No. In the standard configuration, you'd only route traffic to said home devices through the Wireguard tunnel. All "normal" Internet traffic will not see the tunnel and go as usual.
Having said that, it's surely also possible to route your entire traffic (i.e., incl. external Internet access) through the Wireguard network. Whether or not you'll see a slowdown will depend on how fast your Internet connection is and how slow your Wireguard server is. If your Internet connection is, say, 100/50 MBit down/up and your Wireguard server is able to handle more than that, you will not see any slowdown internally. When accessing from outside the local network, the upstream connection will of course be somewhat limiting.
Right now I use wireguard as a VPN for when I'm outside home so that I always have the same IP address for geoblocking reasons. I have cofnigured my wireguard clients with AllowedIPs: 0.0.0.0/0 so that the entire internet traffic is forced through wireguard, the pi and then the internet.
If I use wireguard while being inside my home network since the endpoint is xxx.xyz.com:51820 packets "leave" my LAN, come back to go through the raspberry and then they go out again. Am I right? It seems very pointless and slow.
Where should they go? The IP address you configured is the IP address of the WAN interface of your router. As such, they will bounce at the router and never leave the house.
You can also do the following: Inside your home network, have a local DNS record that points your external domain xxx.xyz.com to the internal IP address of the Wireguard VPN. When outside the house, the devices will get the external address. When inside, they'll get the inside address. The only time when this can make is difference is DSLite (but then you wouldn't have an external port on the IPv4 to even begin with).