Accessing local servers from within your own network & How to force using DNS-resolver for filtering

louis2

Hello,

Getting access to your locally hosted servers is not so trivial

The most common ways to archive this is via a local DNS-resolver pointing to the local address in front of the public DNS pointing to your public address.

However there are ^a few^ issues to consider and to solve:

dns query's are nowadays forwarded via 53 (classical) 853 (via tls) 443 (http)
we have IPV4 and IPV6
a bit more advanced network has multiple vlans / interfaces / rule-sets ....
applications using a ^build in^ DNS-address

How DNS works
In most the pfSense config has couple of IPV4 and IPV6 DNS-servers defined, which are used by the pfSense vlan-gateways to answer DNS-requests and instruct the local systems via DHCP (ipv4) / RA (ipv6) to use the gateway.
However a significant number of applications are using their own build in DNS-address, bypassing the intended DNS

A lot of issues to solve ......

Redirect rule(s)
First thing is that we have to assure that the DNS-querys are passing our resolver. We can do that using Firewall / NAT / Port Forward. However:

you have to define an (vlan) interface there, where you probably have many .....
=> I do not like to have a rule per interface, but I do not have a solution
you have to choose the address family
=> so you will have two rules (per vlan)
select the protocol
=> since DNS can use TCP and UDP you have to choose both
you have to define the destination address which triggers the rule ......
=> I think you can use a star here or something like "! 192.168.0.0/16" of "! <your ipv6-range>/48"
you have to define the destination port
=> as indicated above we have 53/853 and 443 ........ we van not filter 443 (https)
=> I did define an FW port alias DNS53_853 which contains those two addresses
Redirect target IP
=> tja .... most logical IMHO would be the vlan-gw address however, a) those addresses are within the excluded destination range and b) they belong to a certain vlan and are not system wide. c) Netgate is suggesting 127.0.0.1 in their example
=> tja the ipv6 equivalent of 127.0.0.1 ( ::1/128 ) is not accepted by the interface, so I had to choose the ipv6 gateway address

And dns over http !??
Tja partially ...... solvable via the netgate suggested
To prevent Firefox from using DNS over HTTPS, add the following to the DNS Resolver custom options:

server:
local-zone: "use-application-dns.net" always_nxdomain

Defining the DNS-overrides
Of course you have to define the local DNS-overrides in services/dns-resolver

It does not work / far from the perfect solution
I did try to solve the issues

access my local servers from within my own network
make sure that dens-queries are handled via the local resolver to ^allow^ filtering

However, I only partly managed to archive those goals
In fact:

accessing my local servers using my pc which use my gw-address as DNS works
(logical since a redirect is not required)
however it does not work when using a tablet or my mobile does not work
(so the redirect and/or other thing is not working)

Here links to the relevant Netgate documentation
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.html

Bottom line / I hope someone has improvements or has an alternative better solution

Sincerely,

Louis

viragomann

@louis2 said in Accessing local servers from within your own network & How to force using DNS-resolver for filtering:

dns query's are nowadays forwarded via 53 (classical) 853 (via tls) 443 (http)
applications using a ^build in^ DNS-address
However a significant number of applications are using their own build in DNS-address, bypassing the intended DNS

Since you have control over the firewall / router, you can permit only that one you want.

How DNS works
In most the pfSense config has couple of IPV4 and IPV6 DNS-servers defined, which are used by the pfSense vlan-gateways to answer DNS-requests and instruct the local systems via DHCP (ipv4) / RA (ipv6) to use the gateway.

The DNS Resolver use a set of root DNS server if it's not in forwarder mode.

you have to define an (vlan) interface there, where you probably have many .....
=> I do not like to have a rule per interface, but I do not have a solution

You can add an interface group including all your internal networks and put rules like that there.

select the protocol
=> since DNS can use TCP and UDP you have to choose both

pfSense also let you select TCP/UDP to cover both.

you have to define the destination port
=> as indicated above we have 53/853 and 443 ........ we van not filter 443 (https)

Simply redirect port 53 to your pfSense IP and block 853.
There should be rarely a need to have DNS encrypted inside your network.

Redirect target IP
=> tja .... most logical IMHO would be the vlan-gw address however, a) those addresses are within the excluded destination range and b) they belong to a certain vlan and are not system wide. c) Netgate is suggesting 127.0.0.1 in their example
=> tja the ipv6 equivalent of 127.0.0.1 ( ::1/128 ) is not accepted by the interface, so I had to choose the ipv6 gateway address

You can redirect all DNS traffic to a specific interface address in the interface group rule, assuming pfSense is your default gateway in all subnets.

And dns over http !??

Use pfBlockerNG to block access to DoH servers. If the devices are not able to access the configured DoH server they will fall back to simple DNS on port 53.
Yes, that's not absolutely bullet proof, but works well in most cases.

SteveITS

@viragomann said in Accessing local servers from within your own network & How to force using DNS-resolver for filtering:

If the devices are not able to access the configured DoH server they will fall back to simple DNS on port 53.
Yes, that's not absolutely bullet proof, but works well in most cases.

For anyone else reading this, one I've found is the Dish (satellite company) "on demand" channels...everything else on the Dish equipment and mobile app uses normal DNS but that channel (which loads an app to view the list of shows) uses DoH and if that is blocked the app doesn't work.

louis2

@viragomann

Thanks for your replay!

I am still thinking about this problem however, a first reaction

I was not aware of interface groups, and they really help !!
Note however, that I would love to have an option of defining groups of rules which I could apply to interfaces. This interface grouping function is a bit in that direction, but too limited in my opinion since:

it is only one group, where you probably would like to have multiple groups to use with multiple interfaces and
you can not define "where / the priority" in the rule stack it is positioned

Another point is your remark "There should be rarely a need to have DNS encrypted inside your network."

I completely disagree here! Problem are that

computers will not only access the local servers !
I would like to go the apposite route ..... to forward port 53 querys as 853 querys !!

viragomann

@louis2 said in Accessing local servers from within your own network & How to force using DNS-resolver for filtering:

it is only one group, where you probably would like to have multiple groups to use with multiple interfaces and
you can not define "where / the priority" in the rule stack it is positioned

I'm wondering, which granularity of rule processing order you're looking for.
According to your topic you're looking for a solution to force your internal devices to use the Resolver.
So for me for this aim one interface group is sufficient. But you may create also more if you need that.

You can also use floating rules, where you can choose the interface on a per-rule-basis.

In both cases you should be aware of the Rule Processing Order used in pfSense.

I completely disagree here! Problem are that
computers will not only access the local servers !

This is also conflicting with your topic.

I would like to go the apposite route ..... to forward port 53 querys as 853 querys !!

You can do this with the DNS Resolver: Enable DNS over TLS for Forwarded Queries

louis2

@viragomann

Yep, I do not disagree however note:

The interfacegroup function is probably sufficent for this issue. However in other situations I would love an option to define a group of rules which could be 'included' in a set of rules for a certain interface as 'one virtual rule'

Related to 853 query's, I agree that it is perhaps better to block them, assuming the resolver is also not capable to see the destination (I am not 100% sure about how that is implemented. If !???? the resolver can decode the SSL, then 853 should be allowed)

And yep since the resolver act as a DNS-proxy, I agree that telling the resolver that it should use 853 to query the upstream DNS.