Messages

siehe hier (inkl. Lösung):

https://forum.opnsense.org/index.php?topic=14646.0

@banym: Klar, ich werde gern berichten, falls sich tatsächlich eine Lösung finden sollte. Bin gespannt.

[Jetzt habe ich jedoch die neue Herausforderung, dass ich gern auch bestimmte Wildcard-Domains whitelisten möchte.]

Hallo zusammen,

Dank einer eigenen whitelist für bestimmte IPs bzw. IP-Bereiche (auf Basis von URL Table (IPs) Aliases) bin ich wirklich happy über die Möglichkeiten meiner OPNsense – das klappt bisher super.

Da ich u.a. die FireHOL-Level-3 als blocklist nutze, hilft mir eine solche eigene whitelist nun schon sehr.

Jetzt habe ich jedoch die neue Herausforderung, dass ich gern auch bestimmte Wildcard-Domains whitelisten möchte.

Um genau zu sein, geht es mir um folgende IPs/IP-Bereiche und URLs:

https://support.zuludesk.com/hc/en-us/articles/115002303094-Required-firewall-ports-and-IP-Ranges

Und bevor ich jetzt völlig planlos rumprobiere, dachte ich mir, ich frage doch lieber mal hier die Profis, was dafür die richtige Lösung wäre? Denn als Alias kann man Wildcard-Domains wahrscheinlich nicht definieren?

Den IP-Bereich 17.0.0.0/8 habe ich mit meiner whitelist z.B. komplett erlaubt.

Nun muss ich aber zusätzlich auch noch Domains wie

swcdn.apple.com
swdist.apple.com
swdownload.apple.com

aufnehmen.

Das ginge ja wahrscheinlich auch noch mit Aliases, einfach mehrere dieser Domains im Bereich "Content" hinzufügen.

Aber was ist z.B. mit:

*.push.apple.com
*.itunes.apple.com
*.apps.apple.com
* albert.apple.com
* gs.apple.com

usw.

Wie kann ich diese als "immer erlauben" in der OPNsense definieren?

Vielen Dank wie immer für Eure tolle Unterstützung & beste Grüße.

Can also confirm, the patch is working as expected.

Thank you very much. *thumbs up*  :)

Yes, have exactly the same problem with newly created Alias Content in 19.7.5.

It worked with 19.7.4 without any problem (two days ago I've used it to add my own blocklist with a special link inside "Content").

But now with 19.7.5 it doesn't accept to add new "Content" in newly created Aliases.

Seems to be a bug in 19.7.5?

PS: Oh I see, the bug is already known. Hope for a fix with a special 19.7.5.1 or so ...

Because I don't know how to add this fix by myself:

https://github.com/opnsense/core/commit/7a5a2712cdb8dc5cb4e2b7fae46430bd8849799f

[Danke für Eure Geduld und Unterstützung.]

Ja, denke ich auch mittlerweile, werde da mal eher in meinen Mac-Foren recherchieren.

Danke für Eure Geduld und Unterstützung.  :)

scutil --dns ist übrigens noch eine Alternative zum networksetup -getdnsservers Wi-Fi

Da sieht das Ergebnis aber bei beiden Ausgaben identisch aus auf den ersten Blick (also beim Test per fester IP und Test mit per DHCP bezogener IP).

Mit einem beherzten networksetup -setdnsservers Wi-Fi 192.168.1.1 kann man übrigens erreichen, dass dann auch bei DHCP-IP die 192.168.1.1 statt There aren't any DNS Servers set on Wi-Fi zurück kommt bei der networksetup -getdnsservers Wi-Fi Abfrage.

Hilft nur leider nicht ...

Wenn ich eine Lösung finden sollte, poste ich diese gerne hier.

Regeln hatte ich deaktiviert, das hilft leider nicht. Auch ein 'allow any' für die entsprechende IP ändert das nicht.

Wenn ich den Rechner per DHCP eine IP nehmen lasse (durch einen extra zum Test frisch definierten DHCP-Bereich), mit der ich wenige Minuten vorher problemlos auf Netflix zugreifen konnte (hier als Beispiel die 192.168.1.7), klappt es nicht ...

Denn folgendes Phänomen tritt ja auf:

Bei fest zugewiesenen Netzwerk-Einstellungen klappt alles mit dem MacBook, auch die Abfrage networksetup -getdnsservers Wi-Fi gibt dann wie gewünscht 192.168.1.1 aus.

Sobald ich das MacBook aber auf DHCP umstelle, bekomme ich bei der Abfrage networksetup -getdnsservers Wi-Fi eben nicht mehr die 192.168.1.1 als Antwort, sondern ein There aren't any DNS Servers set on Wi-Fi.

Und das ist ja offensichtlich das Problem ...

Witzigerweise sieht man im Bereich Systemeinstellungen / Netzwerk / WLAN bei aktiver DHCP-Netzwerkumgebung trotzdem alle (grau dargestellten, also automatisch bezogenen) korrekten Werte: DNS 192.168.1.1 usw.

Und alle anderen Seiten funzen ja, außer eben Netflix.

Das ist doch echt verrückt!  :o

Anbei auch noch einmal wie gewünscht die aktuellen LAN-Regeln.

Da ja alle anderen Geräte hier im Netzwerk machen was sie sollen, also auch auf Netflix kommen (und das MacBook mit fest zugewiesener IP ja auch mittlerweile), können wir die Regeln aber sehr wahrscheinlich wirklich ausklammern als Ursache.

Muss ich eventuell doch weitere Einträge im DHCP-Server machen?

Das iPad z.B. hat ja kein Problem und bezieht seine IP, die DNS-Einstellungen etc. ebenfalls per DHCP.

Habe den Bereich jetzt mal auf .181-.189 geändert, anbei ein Screenshot.

Wahrscheinlich sollte ich dann DNS-Server und Gateway mal fest eintragen beim DHCP-Server anstatt das frei zu lassen?

@banym: Würde das Problem jetzt eher auf den DHCP-Server eingrenzen (da bekommt das MacBook die 192.168.1.179), und dann funktioniert auch Netflix nicht.

Nutze ich eine feste IP (hab am MacBook dafür eine zusätzliche Netzwerkumgebung neben der automatischen angelegt, in der es fest auf die 192.168.1.7 eingestellt ist), funktioniert Netflix problemlos.

Ok, jetzt habe ich mein MacBook noch einmal per "sicherem Systemstart" neu gestartet (Shift gedrückt halten beim Starten) – und Netflix funktioniert!

Beim "sicherem Systemstart" von macOS werden sämtliche nicht zum System gehörenden Bestandteile deaktiviert.

Allerdings funktioniert es auch nur mit fester IP, nicht per DHCP!

Und auch nur bei fester IP bekomme ich die Antwort 192.168.1.1 bei der DNS-Abfrage, bei DHCP sagt er nach wie vor "There aren't any DNS Servers set on Wi-Fi".

Mmh, also Dank Euch sind wir dem Problem nun glaube ich schon einen großen Schritt näher:

Denn am iMac bekomme ich bei der Abfrage per

Code Select Expand

networksetup -getdnsservers Ethernet die eigentlich zu erwartende Antwort:

Code Select Expand

192.168.1.1

Ich werde jetzt mal von DHCP auf eine feste IP im Wi-Fi umstellen am MacBook, wahrscheinlich funktioniert es dann ...

Nee, zu früh gefreut – mit fester IP etc. wird dann zwar korrekt 192.168.1.1 per "networksetup -getdnsservers Wi-Fi"-Abfrage angezeigt, aber Netflix klappt trotzdem nicht ...

@banym:

Also im capture der IP des MacBook (192.168.1.179) taucht tatsächlich keine der Netflix-IPs auf.

D.h., schon bei der Anfrage in Richtung LAN stimmt da irgend etwas nicht ... nur was?

@micneu:

moin, ich möchte noch wissen, so wie du geschrieben hast am wlan, wie sieht es denn am ethernet aus, hast du da den gleichen fehler?

Ja, hab's vorhin auch mal per Ethernet probiert mit dem MacBook, verhält sich da auch so.

könntest du bitte mal mir die ausgabe dafür posten:

Code Select Expand


networksetup -listallnetworkservices
networksetup -getdnsservers Wi-Fi

von deinem mac.

Hatte ja gestern wie gesagt schon /Library/Preferences/SystemConfiguration 'bereinigt', dabei werden sämtliche Netzwerkschnittstellen komplett zurückgesetzt.

Aber anbei die Ausgabe für networksetup -listallnetworkservices:

Code Select Expand

An asterisk (*) denotes that a network service is disabled.
USB 10/100/1000 LAN
Wi-Fi
Bluetooth PAN

Und für networksetup -getdnsservers Wi-Fi

Code Select Expand

There aren't any DNS Servers set on Wi-Fi.

Ups? Das MacBook bezieht seine Netzwerk-Einstellungen ja per DHCP und zeigt beim WiFi für DNS-Server auch die 192.168.1.1 korrekt an (per Systemeinstellungen).

Und ein dig netflix.com gibt ja auch zurück, dass bei 192.168.1.1 angefragt wird:

Code Select Expand

; <<>> DiG 9.10.6 <<>> netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15245
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;netflix.com. IN A

;; ANSWER SECTION:
netflix.com. 48 IN A 52.18.15.9
netflix.com. 48 IN A 52.208.135.54
netflix.com. 48 IN A 52.17.219.77
netflix.com. 48 IN A 34.252.179.162
netflix.com. 48 IN A 54.77.143.196
netflix.com. 48 IN A 54.171.187.60
netflix.com. 48 IN A 52.17.227.174
netflix.com. 48 IN A 52.209.79.186

;; Query time: 33 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Oct 11 14:23:13 CEST 2019
;; MSG SIZE  rcvd: 168

Ich mache derweil mal den capture vom MacBook wie von @banym empfohlen ...

@banym: So, habe es jetzt erst einmal "zum üben" am iMac (IP 192.168.1.199) probiert:

Netflix ist am iMac wie gesagt i.O. (Auszug aus dem Capture):

Code Select Expand

igb0 14:04:43.716602 IP 192.168.1.199.50696 > 34.250.41.147.443: tcp 0
LAN
igb0 14:04:43.755557 IP 34.250.41.147.443 > 192.168.1.199.50696: tcp 0
LAN
igb0 14:04:43.756072 IP 192.168.1.199.50696 > 34.250.41.147.443: tcp 0
LAN
igb0 14:04:43.765364 IP 192.168.1.199.50696 > 34.250.41.147.443: tcp 517
LAN
igb0 14:04:43.805204 IP 34.250.41.147.443 > 192.168.1.199.50696: tcp 0
LAN
igb0 14:04:43.806800 IP 34.250.41.147.443 > 192.168.1.199.50696: tcp 1440
LAN
igb0 14:04:43.806822 IP 34.250.41.147.443 > 192.168.1.199.50696: tcp 1440
LAN
igb0 14:04:43.806840 IP 34.250.41.147.443 > 192.168.1.199.50696: tcp 755

Ein

Code Select Expand

host netflix.com ergibt am iMac folgendes (IPv6- und Mail-Einträge mal ausgeklammert).

Code Select Expand


netflix.com has address 54.77.108.2
netflix.com has address 52.31.182.100
netflix.com has address 52.19.40.147
netflix.com has address 54.72.216.241
netflix.com has address 52.209.235.141
netflix.com has address 34.250.41.147
netflix.com has address 54.171.116.69
netflix.com has address 52.31.145.183

War in dem Fall also nur die 34.250.41.147 die am iMac für Netflix genutzt wurde.

Jetzt werde ich es gleich noch einmal mit dem MacBook testen.