Messages

You don't.

I assume that your domains are protected by HTTPS and that the Nginx Proxy Manager terminates the TLS traffic. Thus, the internal sites will most probably be HTTP without TLS. You would have to use HTTP for the IP-based local access, which many browsers refuse to do these days.

Even if this was possible, many websites create internal links with a full URL, so knowing they are xxx.mydomain.com, they will generate such links as well when you use them as http://192.168.x.x, leading to problems on the first click and also for references to stylesheets and other ressources.

And if you created a DNS alias to point xxx.mydomain.com to 192.168.x.x when you access that site from your LAN, then you would connect directly to the web service, without the reverse proxy, so you would not get presented the (correct) certificate, if the real web service can talk HTTPS at all.

As you can see, NPM is not even involved once you directly contact the web service at 192.168.x.x.

It would not work either, if you instead used the IP of the NPM manager instead, because it would have to present a valid TLS certificate for 192.168.x.x - which would have to be created using an internal CA and imported to the browser's trust store. Even if it did, the problem of internal links may persist.

What some people do is to create a DNS alias for xxx.mydomain.com for the internal IP of the NPM manager in order to avoid having do to NAT hairpinning to access the WAN IP. That of course works.

Depends on what the machine can do. For example, if it can scan/fax, it needs the time, which is also needed for logging. If that is the case, it could use an NTP server. Of course, it could get the NTP sever IP via DHCP, but as it turns out, there are plenty of devices which use arbitrary cloud NTP servers - like AppleTVs, e.g.

Also, some devices look for firmware updates, can order consumables in advance a.s.o., let alone collect statistics and push that to the manufacturer without anyone knowing.

There are good reasons to put "smart" devices into a separate VLAN.

In that case you are losing potential speed on many modern websites.

Take a look at this - maybe you do not want / need "internal" IPv6 at all after reading it.

You are correct: While you can create a dynamic IPv6 firewall alias, you cannot create the same for (internal) DNS. However, you can use the link-local address that is derived from the EUI-64. That is, iff you use SLAAC and not DHCPv6 for IP assigments (which you should).

You can, of course, use dynamic DNS to update by an interface IPv6 prefix and an EUI-64 suffix. Some DDNS service providers allow to keep the suffix, such that OpnSense can update the prefix only.

Looking at the list, I am not so sure. When you use an IP list, it might be safe to do so - with a wildcard list, I am unsure.

Take cubedns.com (or ptentially, any DoH service that uses only one dot in their name): they have their website on the same URL (and IP). Then again, by blocking port 443 - which you must, it will not work, anyway. At least, you could send them an E-Mail, I guess ;-)

Cloudflare was savvy enough to use a separate domain for DNS.

It is interesting what you can find when you block these things:

- I found HomeAssistant OS using Cloudflare despite being told to use my internal DNS (there is a trick to disable that: https://kcore.org/2022/08/12/hass-disable-fallback-dns/).
- Also, I caught some of my IoT devices using external NTP services - this included Apple TVs. By redirecting to the local NTP, I could make that go away.

On the other hand, I never trusted those anyway, hence why they are on a separate VLAN.

I would use TCP and UDP because of HTTP/3 (QUIC). The list includes IPv6 and also lists mozilla.cloudflare-dns.com.

So, now I got a current list: https://github.com/dibdot/DoH-IP-blocklists

You can use it like so to block DoH requests going outside:

1. Create two "URL table in JSON format (IP)" type aliases with a refresh time of ~ one day and ".[]" as the JSON path expression:

   DoH_IPv4 with content "https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv4.json"
   DoH_IPv6 with content "https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv6.json"

plus a "Ports" type alias - because some DoH services are offered on alternate ports as well:

   DoH_Ports with content "53 80 443 453 853 8053".

2. Create one inbound block floating rule for IPv4 on your LAN interfaces using DoH_IPv4 and one for IPv6 using DoH_IPv6, both with the target port alias DoH_Ports and for TCP/UDP. These rules should apply to whatever interface(s) you want to block DoH on.

You can check effectiveness by using DoH in your browser, which should fail after a timeout.

The mask in the Download queue should be (none). Also, you should define the Upstream side of things as well.

You cannot fix that on your end. It might be that your ISP inherited an IP netblock that once was located in Canada.

Different geolocation services may yield different results, so depending on which are used by the sites you visit, some may think you are in Canada and some may already know the correct location. You can check your WAN IP against some publicly available services like ipinfo.io (https://ipinfo.io/) or Maxmind (https://www.maxmind.com/en/geoip-demo). Note, however, that there are other services as well.

Probably, you can ask your ISP to ask those service suppliers to correct their data. The only other way of fixing it would be to use a VPN service that can put you in the USA when you select an appropriate exit node.

This has nothing to do with how OpnSense does the geolocation - it does not matter to external sites. BTW: You can choose between Maxmind (https://docs.opnsense.org/manual/how-tos/maxmind_geo_ip.html) and IPinfo (https://docs.opnsense.org/manual/how-tos/ipinfo_geo_ip.html) there, with IPinfo usually being more accurate - but it does not fix the problem on the sites you visit.

Not a single IPv6 in that list (as the comment already suggests) - but worse, the IPv4 ones used by Mozilla are not in that list, either:

Code Select Expand

Name:   mozilla.cloudflare-dns.com
Address: 172.64.41.4
Name:   mozilla.cloudflare-dns.com
Address: 162.159.61.4
Name:   mozilla.cloudflare-dns.com
Address: 2a06:98c1:52::4
Name:   mozilla.cloudflare-dns.com
Address: 2803:f800:53::4


The RPZ-type lists could be used in Unbound, but there is no automation in OpnSense.

O.K., so you need AG Home on top. The column "Should be used for" for the lists suggests Unbound and OpnSense, but I fail to see how that works.

And that may also be circumvented by using the IP on itself, since AG Home is never asked.

P.S.: There is a "near-native" approach in Unbound's blocklists, but it uses the wildcard domains only. You do not even have to know the URL. The blocklist type has to be set to  "[hagezi] DoH/VPN/TOR/Proxy Bypass", see https://github.com/opnsense/core/issues/8224 - however, it is not the RPZ type list that is being used, just the wildcard domains.

Mit einem vServer wird das wohl eher schwierig... Virtualisierung per Proxmox auf einem Virtualisierungshost? Ich meinte schon einen echten Root-Server.

Maybe I am just too dumb, but how can one use that with OpnSense to block DoH servers?

I know I can use hostname-based lists with the "URL Table (IPs)" alias type (which sound counter-intuitive), however, this obviously does not work with lists that contain, like *.domain.xyz.

Since not all names are contained in the list without wildcards, it does not even work when I use that and set Mozilla to use DoH, because "mozilla.cloudflare-dns.com" ist not contained in the list and does not resolve to the same IPs as cloudflare-dns.com. Thus, it is not blocked.

Using the wildcard hostname lists in an Unbound DNS blocklist seems unintuitive, because one could use the hard-coded IP to circumvent it and it would also block other services that might be within the affected domains.

I think what you really want here is a list of IPs to block for port 443?

Richtig gut wäre ja l4...

Dazu muss ich nicht weit schauen: Unifi erlaubt z.B. überhaupt nicht, den Hash-Type einzustellen (sie haben aber zumindest l3). Under the hood hängt es bei denen vom verbauten Chipsatz ab, nur kann man die Einstellungen dort nicht wirklich persistieren.

Siehe auch: https://forum.opnsense.org/index.php?topic=45429.0

Dabei ist Unifi alles andere als "billig"... Ich hatte schon andere Billig-Switche, die zwar VLANs können, aber kein LAGG, ist aber schon ein Weilchen her.

HTTP referer protection can prevent other websites from sending sensitive data over a link that was unprotected, say "https://.../xyz?login-secret=abc".

Usually, you can avoid the problem by using <a href="https://..." rel="noreferrer">" in your link.