Messages

I've been out of luck to use this amazing UDP Broadcast Relay for WS-Discovery across VLANS...

It works well for mDNS with my chromecasts

But for WS-Discovery, no matter what source IP I use, "empty", "1.1.1.1" or "1.1.1.2" it just does not manage to let WS-Discovery work from one vlan/subnet to another.

In fact, with "empty", it almost works : probe requests reached the other subnet, that answsers with a probe-match. But Windows has the good idea to see the probe-match packet, but since the source IP is outside it's subnet, it doesn't try to resolve it...

I would like/need this UDP to act like a proxy for WS-discovery, and replace do something similar to NAT, which I thought could be the 1.1.1.1 or 1.1.1.2 source, but in fact sadly no...

Would you be willing to look at the ws-discovery protocol and implement some other mechanism to be able to act as a ws-discovery proxy (lots of documentation show this is allowed by the protocol but I could find no implementation of this anywhere).

Thanks in advance for your reading.

Hello, is there any solution to this issue? I confirm that with UDP Broadcast relay on Port 3702 and Broadcast Address 239.255.255.250 Windows does receive the packets, but for whathever reasons they are disregarded - indeed probably they originate from the wrong subnet...

Thanks!

Today I experienced the same problem again, different domain. After setting 8.8.8.8 as DNS in Adguard, everything worked fine. Unbound didn't throw any errors, so, no Idea how to track the issue.

Any ideas here?

That goes exactly into the direction we were recently discussing on the German board of this forum: https://forum.opnsense.org/index.php?topic=43283.15

I also had the problem, that some domains were not correctly resolved by unbound. Only after adding an excemption to e.g. office.com with lookup via 8.8.8.8 I was able to correctly access the webpages. User "abulafia" confirmed that he/she also had this issue.

The problem is that the issue only occurs occationally. That makes it difficult to track the problem.

Wie bist du denn im WAN drin? Über eine Fritzbox oder so? Was wird dort unter Internet->Online-Monitor->IPv6 Präfix angezeigt? Ein /64 kann man im Übrigen nicht weiter aufteilen . Ein Subnetz ist ein /64, also bleibt man bei einem Subnetz hängen.

Vermuttlich liegen deine unzufriedenstellende Ergebnisse eher darin, das du an der Unbound Konfig rumgespielt hat.
Unbound aktivieren, 3 Haken setzen fertig - funktioniert

Danke mir zu unterstellen, ich wäre zu doof um Unbound aufzusetzen  >:( Der Vollständigkeit halber hier meine Settings [tick]:

• Enable unbound
• Register ISC DHCP4 Leases
• Register DHCP Static Mappings
• Hide Identity
• Hide Version
• Prefetch DNS Key Support
• Harden DNSSEC Data
• Agressive NSEC
• Serve Expire Responses
• Reset Expired Record TTL
• Prefetch Support

Auch das ist für mich nicht nachvollziehbar. DNS ist so designed, dass man einen rekursiven DNS-Server oder "Resolver" einfach nur irgendwo ans Internet hängen muss, und dann kann der alle Namen, die im globalen DNS existieren, korrekt und performant auflösen. Isso. Ich betreibe seit 30 bald Jahren Rechenzentren und DNS-Server ...

Das ist auch mein Verständnis. Aber die Logik hört bei mir irgendwann auf, wenn aus welchen Gründen auch immer am Montagmorgen eine Domain nicht mehr erreicht werden kann was bis dahin jahrelang funktioniert hat und *plötzlich* nach einem manuellen setzen von [/domainname.com/]8.8.8.8 in Adguard wieder alles tut. In den Adguard Logs habe ich gesehen, dass die DNS Anfragen problemlos an Unbound rausgingen, aber im Endeffekt tat es dann eben ohne die Ausnahme mit Google-DNS für diese Domain nicht. Keine Ahnung.  ::) Ist hinterher auch schwer, das Gegenteil zu beweisen, da die IP dann irgendwo (im Zweifel im abfragenden Gerät) selbst ge-cached ist und Deaktivieren der Ausnahme insofern nichts bringt...

Dass Adguard und Unbound auf der Opnsense problemlos laufen und relativ einfach einzurichten sind, steht außer Frage. Für die Auflösung der lokalen Hostnamen ist Unbound auch hilfreich (Adguard: Private inverse DNS-Server --> unbound). Ob dann aber die Komplexität mit der Abfrage der Root-Server (die eben aus eigener Erfahrung manchmal unzufriedenstellende Ergebnisse liefert, siehe erster Post) notwendig ist, das ist für mich die Frage.

Entscheidender ist, dass du nicht *einem* Server deinen kompletten Request gibst.

Das ist die eine Sichtweise, die andere wäre, die Requests auf viele zuverlässige DNS-Server zu verteilen. Google weiß bei mir ohnehin was ich tue, ebenso Microsoft (Windows, Android und Google-Suchen lassen grüßen).

Hallo,

ich verwende seit Ewigkeiten erfolgreich die Kombination von AdGuard und Unbound. Wobei Unbound die Root-Server abfrägt zur DNS-Auflösung. Nun habe ich festgestellt, dass es vereinzelt DNS-Anfragen gibt, welche durch diese Kombination nicht zufriedenstellende Antworten liefern. Beispielsweise musste ich für Microsoft und für WatchGuard Ausnahmen in AdGuard eintragen, dass hierfür direkt eine Abfrage der DNS-Server von Google erfolgen darf. Warum das so ist, weiß ich nicht, aber nur so funktioniert es. Nun stelle ich mir zwischenzeitlich die Frage, ob die Komplexität mit der Verwendung von Unbound und der Abfrage der Root-Server überhaupt für übliche Familienhaushalte notwendig ist, wenn man nicht ein besonders hohes  Bedürfnis an die Privatsphäre hat. Ich könnte mir durchaus vorstellen, dass eine Verteilung der Abfragen direkt in AdGuard auf 5-10 unterschiedliche DNS-Server ein ausreichend hohes Maß an Privatsphäre gewährleisten sollte, zumal ich mir nicht vorstellen kann, dass hier einer der kommerziellen DNS-Server darauf erpicht ist, speziell meine Privatsphäre zu erkunden und für irgendwelche Zwecke zu nutzen. Wie seht ihr das?

As mentioned in another post (to which I received no answer), I have the same problem. IPv6 prefix delegation working for years. After upgrade to 24.7 the delgation only works for WAN and LAN, not for the further interfaces (all track WAN interface). Differently to imk82, I am using the default physical WAN interface, so it shouldn't be a WAN issue...

As I further mentioned in another post, I ticked "Allow manual adjustment of DHCPv6 and Router Advertisements" which before 24.7. allowed me to select a virtual Source Address for Router Advertisements. This option disappeared after the update and now only "automatic" is selectable.

UPDATE: It works, don't know why. After a while it worked again with 24.7.3_1. Further, as a change I had to modify my previously used CARP Address to fe80::192.168.2.1/64 reverting from fd00:: ... used previously. Now I can select the CARP interface for HA.

Hello,
after the update to 24.7.3_1 IPv6 adresses are not assigned to the interfaces via track interface correctly. Only WAN and the first interface obtain a respective prefix, while all other interfaces get the same prefix assigned shared over all interfaces. Ping6 from WAN interface works.

I use DHCPv6 on WAN. Track Interface on LAN, DMZ etc. Further, I use some HA setup for which I have ticked "Allow manual adjustment of DHCPv6 and Router Advertisements" on all interfaces - unfortunately in the RA section the previously avaible "source address" does not show anything else than "automatic". Previously, I was able to select a virtual IP...

Any solutions on that or shall I just wait for a new update?
Thx.

UPDATE:
It works, don't know why. After a while it worked again with 24.7.3_1. Further, as a change I had to modify my previously used CARP Address to fe80::192.168.2.1/64 reverting from fd00:: ... used previously. Now I can select the CARP interface for HA.

Hmm, bringt mich nur halb weiter. Ich würde bei Abfrage der Root-Server erwarten, dass irgend eine initale Query nach xx.root-servers.net rausgeht. Tut es aber nicht. Also mal ganz praktisch, DNS-Lookup auf eine bisher nicht aufgerufene Domain in einem weitegehend unbekannten Land auf der Erde sollte doch irgendwie die root-Server ins Spiel bringen. Und das müsste man im Log sehen? Oder habe ich einen Denkfehler?

Hi Monviech,
danke, aber die Frage ist, was tut unbound tatsächlich? Lässt sich das mit irgendwelchen Tools nachvollziehen? Auf der Firewall sehe ich Anfragen vom WAN Interface an eine Vielzahl unterschiedlicher Server auf Port 53. azure-dns.com, edgecastdns.net usw.

Also, nach dem Reboot scheint alles zu laufen, keine Fehlermeldung im Log. Mehr kann ich nicht sagen.

Andere Frage, wie finde ich denn heraus, ob unbound die Root-Server rekursiv abfrägt bzw. wo lege ich das fest? Wie bereits oben geschrieben ist alles leer bei DoT, QueryForwarding, Blocklist, Accesslists.

Zumindest die Fehlermeldung ist weg nach einem Reboot.

Unbound restart tut nicht. Hängt nach dem Patch und reagiert nicht. Ich probiere später mal einen Reboot.