Local DNS Records on different subnet
-
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 -
@jhmc93 that doesn't show any iP it was resolved too - unless you cut it out columns are different order?
not sure why it would even show that?? If it didn't resolve to something, and you would get a different error if had no ip to talk to, like I posted above.
Can we see the top of that output, see where it shows suffix and doh and trr mode.
Also that seems like a really odd isolation key for going to some local domain.. jhncmedia.com
-
-
@jhmc93 so your search suffix is a public domain? Yeah your most likely going to have weird stuff happen.
because you look, for something like pve.local.whatever its going to end up looking for pve.local.whatever.cable.otherthing.net
-
@johnpoz even though pihole is set as my dns on pfsense and on the laptop on my isp side so don't know what is going on
-
@stephenw10
your answer -
Ok great so it does resolve to the internal IP in the pfSense LAN subnet as expected.
This it is almost certainly failing because the client has no route to reach that subnet. It would not have one by default. It would have to have been added as a static route via the pfSense WAN. And pfSense would need rules on WAN to pass it.
-
@stephenw10 how would I go about that? without exposing it to public internet because I wanna keep it in my ISP subnet and Pfsense Subnet
-
Well really what you should do is move all clients to a subnet behind pfSense to avoid this issue. It's almost certainly going to cause other problems having clients in the pfSense WAN subnet.
But I understand you might have physical restrictions for example preventing that.
So you need a firewall rule on the pfSense WAN to allow traffic from the wan subnet to whatever the target IP is on the LAN.
And you need to add a static route to the pfSense LAN subnet via the pfSense WAN IP on the client directly.
That doesn't expose anything to the public internet.
-
@stephenw10 so do I create that rule in the lan or wan firewall rule or is it a nat rule
-
It's a firewall rule on the WAN interface. The client is trying to open connections from the WAN subnet to servers in LAN.
-
@stephenw10 so what would be my source and destination ip
-
Assuming you've added the route on the client.
The firewall rule should be source: the pfSense WAN subnet and destination: the server in the LAN. Or you set the destination to the full LAN subnet as a test.
-
@stephenw10 so on pfsense add it under the WAN firewall rules? or the LAN?
-
The rule has to be on the WAN.
It needs to pass traffic from the client in the WAN subnet to the server in the LAN subnet.
But this is the wrong way to do this. You should instead move all clients to subnets behind pfSense. You will almost certainly see other issues trying to have clients in the pfSense WAN.
-
@stephenw10 so I won’t be able to access dns cname records off isp side because of security issue with routing traffic from ISP to pfsense LAN
