Messages

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.

Oder auch nicht, weil die billigen Switche LACP maximal anhand der MACs machen. Wenn die ungünstig ausfallen, kann der Traffic zufällig auch immer nur über den selben Port laufen. Das mittelt sich statistisch erst heraus, wenn sehr viele Clients gleichzeitig Traffic verursachen - im Heimnetz eher unwahrscheinlich.

Deswegen mache ich das meist über 2.5 Gbps-Ports und verteile die VLANs gescheit, z.B. LAN auf einen Port und alle anderen VLANs auf den anderen. Meistens läuft der Inter-VLAN Traffic ja zwischen LAN und einem der VLANs, dann ist garantiert, dass zwei Ports dafür genutzt werden.

LAGG würde ich eher für Failover-Konstellationen nutzen.

Trotzdem benötigt man dafür einen managed Switch - der wird dann aber auch mit zwei Ports an die OpnSense angeschlossen.

...which by default allow any to any for any IP protocols on LAN? ;-)