Messages

[und]

1. Deine Outbound NAT Regel müsste UDP und TCP umfassen (SIP kann über beide Protokolle gehen und das tut es bei der Telekom auch). TCP fehlt bei Dir.

2. Du benötigst die Outbound NAT Regel und die Port-Forwarding-Regel(n). Die erste sorgt dafür, dass der SIP-Server des ISP den richtigen Absende-Port sieht (wenn er nicht "static" wäre, wäre das ein zufälliger Port). Die zweite erlaubt eingehende SIP und RTP-Verbindungen.

3. Die Telefonie-Ports der Fritzbox sind (standardmäßig): 5060 für TCP und UDP (SIP) und 7077:7109 UDP (RTP/RTCP). Man findet sie in den Diagnose- und Sicherheitseinstellungen der Fritzbox und auch in den gespeicherten Enstellungen. Der Rest ist Mumpitz. Man kann diese Einstellungen aber auch ändern und ich würde nicht ausschließen, dass sie sich nach den Telefonie-Provider-Einstellungen richten - durch Modifikation der Konfigurationsdatei lassen sie sich auf jeden Fall ändern.
Es gibt in der Konfigurationsdatei beispielsweise noch zwei Angaben: "random_sip_port_enabled = no" und "random_sip_port_range = "20000-30000", bei mir waren die aber immer inaktiv.

4. Viele ISPs machen VoIP auch über IPv6 (Beispiel: M-Net). Wenn das aktiv ist, wird es immer bevorzugt verwendet. Daher helfen dann die IPv4-Einstellungen gar nichts. In diesem Fall muss man entsprechende Firewall-Regeln für den eingehenden SIP- und RTP-Verkehr für IPv6 anlegen. Dazu benötigt man die EUI-64 der Fritzbox und muss einen "Dynamic IPv6 Host"-Alias als Ziel-Host nutzen. Ausgehender IPv6-Traffic ist hoffentlich sowieso erlaubt und es braucht dort auch kein NAT. Das aber nur am Rande, weil es nicht Dein Problem ist.

5. Ich würde anfangs komplett darauf verzichten, die VoIP-Server des ISP als Einschränkung zu verwenden und zunächst "any" als Quelle zuzulassen. Wenn alles funktioniert, kann man das ggf. nachrüsten. Einer der Gründe ist, dass Deine Subnetze in beiden Richtungen nicht stimmen:

a. 217.0.7.0/24 ist in 217.0.0.0/13 vollständig enthalten und daher überflüssig, wie ein Subnetzrechner Dir sagen wird.
b. Bei mir ergibt "nslookup -query=srv _sip._udp.tel.t-online.de":

Code Select Expand

_sip._udp.tel.t-online.de       service = 20 0 5060 nes008-f01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._udp.tel.t-online.de       service = 10 0 5060 kln000-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._udp.tel.t-online.de       service = 30 0 5060 hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.

Beispielsweise: "nslookup nes008-f01-mav-pc-rt-001.edns.t-ipnet.de." ergibt 217.0.147.5, was wiederum außerhalb der von Dir zugelassenen Bereiche liegt. Übrigens: _sip._tcp.tel.t-online.de gibt es auch, wie bereits erwähnt!

Wenn man überhaupt so etwas macht, dann über einen ASN-Alias der Telekom. Das lässt dann zwar auch alle Kunden der Telekom zu, stellt aber sicher, dass es immer funktioniert. Bei anderen ISPs kann das nach hinten losgehen, weil die teilweise Dienstleister für VoIP nutzen, die andere Netzbereiche verwenden, dann muss man deren ASN verwenden.

If your ISP uses dynamic IPv6 prefixes (many do), then you can create a "dynamic IPv6 host" alias using the EUI-64 and the interface it is on.

Of course, with dynamic prefixes, you also need a dynamic DNS service that allows you to use an IPv6 address that is using a predefined EUI-64 part. If it can only register the outbound IPv6, it will only see OpnSense's WAN IPv6, so you must be able to mix in the lower 64 bits if the target IP is not OpnSense itself.

Another way to do this is using a reverse proxy like Caddy, HAproxy or NGinx on OpnSense, in which case the dynamic DNS update gets easier, because OpnSense itself is the target, then. When you use that, you do not even have to use IPv6 for your internal web service, plus you do not need a specific firewall rule.

...or else they'll fix that problem! ;-)

Is that possible with a transparent bridge setup? I frankly do not know...

And BTW: Does Home Network Guy not specifically cover that basic question, which should come up all the time with such setups, I imagine?
Oh, yes, he does. By creating a MGMT interface and bridging that to WAN. How elegant and intuitive.

I still do not get how people think that a transparent bridge would be easier than a routed setup.

Mainly, none of the RFC authors ever considered that with the abundance of IPv6 addresses, any ISP would ever even think of using dynamic prefixes. Alas, that is the reality for most consumer setups now.

And frankly speaking, the videos I saw from that guy are mostly outdated, unspecific and in some cases, beside "usual" approaches. As Patrick noted, transparent filtering bridges might look like a good idea to beginners (obviously, also to Home Network Guy), while in reality, they make most things harder.

Maybe that is due to the TCP congestion algorithms used. You can change it with Windows, I think under Win10, it was BBR2, but that had some problems, so they reverted back to CUBIC for Win11.

With Linux, you can easily change it via sysctl. These are the values I use:

Code Select Expand

net.core.rmem_default = 2048000
net.core.wmem_default = 2048000
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 1024000 33554432
net.ipv4.tcp_wmem = 4096 1024000 33554432

# don't cache ssthresh from previous connection
#net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_adv_win_scale = 5
# recommended to increase this for 1000 BT or higher
net.core.netdev_max_backlog = 30000
# for 10 GigE, use this
# net.core.netdev_max_backlog = 30000
net.ipv4.tcp_syncookies = 1
# Enable BBR for Kernel >= 4.9
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr


Reminds me of https://forum.opnsense.org/index.php?topic=47099.0. In there, is a subnet calculator, too.

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.