And just about every other person that I've come across that has done that now has a huge hole in their network and are hosting an open resolver. Chances are you are too if you haven't set up a firewall. If you'd like, run a debug and post the token, you may find that you're not as secure as you believe.
Thanks, and I assume you have a firewall app or have tried an open resolver test against the GUA you've statically assigned to the Pi-hole? (Something that prevents remote access or remote DNS resolution.)
The router's firewall stops random outside requests for my IPv6 addresses by default. I did of course check that it was working as I have Unbound on the pi as well. The average person wouldn't know that but I doubt the average person would be running Pi-Hole/Unbound/etc.
The only open hole in my router is for Wireguard - that's the only way I remotely check my network.
Your configuration is very similar to mine, incluso tenemos el mismo proveedor de Internet. I am using Unbound in my Pi-hole too, BTW.
Are you using OpenWrt in your router by any chance, if so, I might be able to help you to solve this.
No, my router doesn't allow custom firmware. Funny thing is, I did buy a router the other day specifically to put dd-wrt on it, and I did, but it broke a number of things. The family was getting very annoyed so I had to revert back to my current setup. I might play around with it another time. Estas seguro que usamos el mismo proveedor? Donde vives?
Forget about dd-wrt, tends to be very unstable to my taste. What router is it? May I suggest that you try OpenWrt? As you might know it is installed in many devices from the factory and it is very stable and packed with features.
Y, sí, estoy seguro que AussieBB es nuestro proveedor, el prefijo IPv6 que publicaste en un mensaje anterior lo delata. Vivo en Melbourne.
1 Like
Cool! AussieBB FTW. I looked into OpenWRT but it doesn't support the router I bought. Que pena.
1 Like
I do not use Pi-hole as my DHCP server, I delegate AussieBB's /56 as ::1/64 to my local network from my EdgeRouter X. Internally I use a /48 ULA range. From my ERX DHCP's I sent to all my network clients it is new IPv4 and IPv6 DNS server, which is my Pi-hole. Only my ERX has access to Cloudflare DNS servers, I don't even use AussieBB's ones. I enable Conditional Forwarding in my Pi-hole and set my ERX local address, for reverse lookups and getting proper local names in Pi-hole's statistics page.
And to complete the whole picture I use NAT and NAT66 to hijack local DNS queries, so apps like Netflix and my Google devices —mainly— are forced to utilise my Pi-hole/Unbound's DNS resolver.
Unfortunately, I kept my network pretty basic until recently, so I am very limited in options unless I just buy more hardware.
So, Pi-Hole is now providing its IPv6 address to clients (as well as giving some clients an IPv6 address from its DHCPv6 server). I am just adding this as a solution. The only thing I did was edit my /etc/dhcpcd.conf file. I changed the "inform" line to a static address and I added a /64 to the static IPv6 line (I was trying to fix something else). I believe the "errors" in my dhcpcd.conf file came about from playing with the Network settings through Raspbian. If anyone reads this and knows why that worked, I would love to hear it.
So if what you did was add
interface eth0
static ip6_address=2403:5800:3101:f666::1/64
or similar you are effectively sitting your local network in your ISPs IPv6 range, but manually, and it should be fine as the Pi-hole will give IPs in this /64 range plus the fd00::/8, ideally this is the one to use, and prefix delegation should provide the public IP. But, hey, if it works you know what they say, do not touch it. It should not be a problem with routers assignment of IPv6 addresses as the clients can advertise themselves to avoid conflicts.
One question, though. I was checking my /etc/dhcpcd.conf files and I cannot find the "inform" line you are referring to. This is how mine looks
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
As you can see I use SLAAC to get the IPv6 address from my router.
Hi. The inform part is generated by Raspbian if you mess around with the Network settings and put your static IP there manually. I think that's what started all my problems.
From your /etc/dhcpcd.conf:
Your static IPv6 was missing a netmask, thus assuming a 128bit prefix length, not leaving room for any clients.