Local DNS Records on different subnet
-
You need clients in the ISP router LAN to use the correct DNS server. So either passed by DHCP or set manually if you can't set a DNS server in the ISP router DHCP settings.
-
@stephenw10 So I can't pass it through then?
-
Can't pass what through?
You need clients to use the pi-hole or pfSense for DNS in order be able to resolve anything stored there.
Right now they are probably using the ISP router for DNS because it is running DHCP for that subnet?
-
Hello,
So my pi hole is connected to isp router then pfsense dns is connected to pi hole and pi hole is then pointing to an ip that runs traefik in my pfsense subnet, hope that makes sense -
Ok. And the issue is that client in the same segment as the pihole are not using it for DNS?
The problem is that they are probably being set to use the ISP router for DNS by the ISP router if it's still running as a DHCP server.
-
@stephenw10 so basically pi hole runs on 192.18.. pfsense which is also 192.168.. is pointing to that in DNS settings then the :LAN side of the pfsense is 10.84.. which is where my traefik is located, the problem I have is how do i get my laptop which is on for example 192.168.. to use my local cname records even though I have manually set the pihole as the laptops dns server. Because traefik is on my pfsense subnet it wont resolve to a webpage set on CNAME on pihole.
-
What does it resolve to? If the client is statically configured to use the pihole for DNS it should resolve it the same as anything else.
However it may not be able to reach whatever that resolves to. That's a different problem.
-
@stephenw10 here some screenshots:
-
There's no need to obscure private IP addresses like 192.168.X.X or 10.X.X.X. Those are only defined inside your network.
So what does the client resolve the traefik server to?
It looks like you have a domain override pointing to a server behind pfSense. Does the pihole have a route to that subnet?
Can you connect to the traefik server from a client using it's IP address directly?
The client will also need a route to that subnet via pfSense which it won't have by default.It seems like you may have both a routing issue and DNS problems here. And that is typical of running clients on the WAN side of pfSense where asymmetry is highly likely.
-
@stephenw10 see the DNS CNAME records resolve if I'm on pfsense's subnet but not isp subnet, pihole runs via isp subnet but it does work when I set the pfsense to that pihole via ISP
-
Does it actually not resolve or just not connect?
The screenshot above looks like a connection issue not a DNS problem.
If it does resolve what is it resolving to at the client?
-
@stephenw10 so I am on my pfsense subnet right now,
where as it doesn't do that if I'm on my isp router
-
@jhmc93 that browser error is not a dns not resolving, browser not resolving something would look like
Your machine resolved that to something, is it the right thing - who knows from that picture - but it did resolve it.
If your using firefox go to about:networking#dns it will show you what you resolved something too
-
not showing anything
-
@johnpoz
guessin this is it can't be sure though -
On the client just try to resolve it at the command line so you can see what it resolves to.
If it resolves to something in the 10.84.x.x subnet (pfSense LAN) then you will need a route to it via pfSense.
If you just put all your clients on a subnet behind pfSense this would work without issue.
-
@stephenw10 by client do u mean my machine I work on, the traefik machine or the pihole server??
-
I mean a desktop/laptop in the 192.168.8.X subnet (pfSense WAN side).
-
@jhmc93 how would you think that is it - that name ocsp.digicert.com is not the fqdn you were trying to go to.. Come on Man!!
The fqdn in your proxmox shows pve.local.something - does that look anything even remotely close? That is the oscp check for a digicert cert..
https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
I thought it was pretty obvious - I highlighted 2 names that are local on my network, nas and sg4860.home.arpa - that resolve to local rfc1918 IPs
-
@johnpoz
I'm thick sorry