Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Marcel_75

#31
Hi,

if I run a health check on my OPNsense (latest version 22.7.4) I get the following warning messages:

py37-markupsafe has a missing dependency: python37
py37-markupsafe has a missing dependency: py37-setuptools
py37-markupsafe is missing a required shared library: libpython3.7m.so.1.0


Wondering how to fix this? Do I have to SSH into the machine and manually delete this 'py37-markupsafe'?

Don't remember to install this in the past, but this OPNsense was upgraded since some years now, so it might be a peace of code from some older OPNsense versions?

Thanks for clarification & all the best,
Marcel
#32
Oh yes, great idea – this would be a very nice feature.
#33
Hallo zusammen,

eine Frage hätte ich dann doch noch einmal zu meinem "Konstrukt":

Unter System: Settings: General habe ich ja gar keine "DNS servers" hinterlegt, auch die "DNS server options" sind dort komplett deaktiviert.

Nun frage ich mich gerade, ob ich nicht auch "nur BIND" nutzen könnte, ohne im Unbound DNS erst noch darauf umzuleiten?

Oder ist mein "Konstrukt" (siehe erstes Posting in diesem Thread) schon ok so und anders geht das gar nicht?
#34
Ah ok, jetzt hab ich's kapiert.  :)

Danke!

Na dann warte ich mal noch den 21.7.1 release ab und dann wage ich das Upgrade.
#35
Ah ok – d.h., ich lege im Ordner /usr/local/etc/unbound.opnsense.d eine Datei custom-options.conf an, in der dann

forward-zone:
name: ,,."
forward-addr: 10.5.5.1@53530


steht und das war es schon?

Muss ich dann noch irgend welche chmod/chown Besonderheiten für /usr/local/etc/unbound.opnsense.d/custom-options.conf beachten?

Denn es gab ja den Hinweis, dass diese 'custom options' bei Unbound DNS entfallen, weil die als 'unsicher' gelten – deshalb will ich da auf Nummer sicher gehen, dass auch die Zugriffsrechte korrekt sind.

Danke für weitere Erläuterung.
#36
Hallo zusammen,

vllt. habt ihr ja einen Tipp für mich, wie ich mit folgender Situation umgehen soll – und zwar habe ich folgende Herausforderung:

In Services: Unbound DNS: General habe ich im Bereich "Custom options" folgende Einträge:

forward-zone:
name: ,,."
forward-addr: 10.5.5.1@53530


Auf diesem Port 53530 'lauscht' BIND, d.h. unter Services: BIND: Configuration ist der Listen Port auf 53530 gesetzt. Und natürlich gibt es eine entsprechende Firewall-Regel.

Der Hintergrund war, dass es ursprünglich keine Blacklist/Blocklist für Unbound sondern nur für BIND gab, wenn ich mich recht entsinne ...

Als DNS Forwarders ist im BIND dann noch mein Pi-Hole eingetragen.

Da mit dem neuen OPNsense 21.7 "Noble Nightingale" release ja nun die "Custom options" bei Unbound DNS endgültig entfallen, frage ich mich, ob mein Konstrukt dann so überhaupt noch arbeiten würde?

In der Update-Beschreibung gibt es noch den folgenden Hinweis:

Local override directory /usr/local/etc/unbound.opnsense.d exists.

Heißt das, in diesen Ordner soll ich eine Datei legen, die dann meine "Custom options" für Unbound DNS beinhalten? Und falls ja, wie genau muss diese Datei dann heißen, damit das funktioniert? Und 'überlebt' das dann auch Updates auf 21.7.1, 21.7.2 usw., oder muss ich das dann jedes mal neu anlegen?

Danke im voraus für Eure Unterstützung.
#37
Hallo zusammen,

erst einmal vielen Dank an alle für die zahlreichen Empfehlungen.

Habe es jetzt am WE auch gewagt, das ganze per "Terminal" upzugraden und es lief alles gut. Zur Sicherheit habe ich danach trotzdem auch noch mal die von 20.7.8 exportierte Config in 21.1 importiert.

Mittlerweile scheint auch das Problem mit dem "Warnhinweis" nach dem Neustart verschwunden zu sein, die ersten zwei, drei male tauchte er noch auf, jetzt nach dem letzten Reboot aber nicht mehr.
#38
Hallo zusammen,

wahrscheinlich ist dieser Weg empfehlenswert?

1) Aktuelle Config der 20.7.8 exportieren.
2) Den Router von einem 21.1-Stick booten und in das "Live"-System gehen.
3) Die 20.7.8-Config importieren.

Schauen, ob soweit alles funktioniert.  :)

Ich frage sicherheitshalber vorher aus verschiedenen Gründen.

Zum einen hatte ich bei meiner 20.7-Installation diverse male nach einem Neustart den Hinweis, dass da "etwas nicht in Ordnung" sei bei mir inkl. der Option, einen 'bug report' zu senden etc.

Das hatte ich dann auch gemacht inkl. Kontakt-E-Mail für Rückfragen usw., da kam aber leider nie eine Reaktion darauf ... (was ja auch nicht weiter "schlimm" ist). Aber natürlich bin ich mir jetzt etwas unsicher, ob ich die neue 21.1 nicht lieber 1x komplett frisch installieren sollte?

Außerdem nutze ich z.B. die 'custom options' bei "Unbound DNS":

forward-zone:
name: ,,."
forward-addr: 10.5.5.1@53530


Das zwingt die DNS-Anfragen rüber zu BIND (der lauscht auf Port 53530).

Mit 21.7 sollen diese 'custom options' ja rausfliegen bei "Unbound DNS" (bei "Dnsmasq DNS" sind sie ja nun sogar schon ab der 21.1 raus).

Und ich frage mich, was ich diesbezüglich im Vorfeld beachten / bedenken sollte.

Danke für Praxis-Tipps.

Beste Grüße,
Marcel
#39
Hallo,

sowohl der Bridge Mode als auch Exposed Host sind leider keine Option, ich möchte das ganze schon weiterhin als Double-NAT betreiben (also vorn die Fritzbox Cable mit Ihrem 10.89.89.0/24 Netz, dahinter meine OPNsense mit dem 10.5.5.0/24 Netz).

Dieser heise-Artikel hier führte mich schon mal grundsätzlich auf die richtige Spur:

https://www.heise.de/ct/artikel/MagentaTV-auf-pfSense-Co-4698826.html

Nur habe ich es hier bei mir ja nicht mit einem Telekom-Anschluss und Magenta TV zu tun, sondern es ist ein Kabel-Anschluss von PYUR und die Fritzbox empfängt ja schon erfolgreich die DVB-C Signale und die aus der Fritzbox exportierte Programmliste lässt sich im 10.89.89.0/24 Netz auch absolut problemlos per VLC ansehen.

Vllt. als Beispiel mal ARD HD aus der .m3u Liste, da steht folgendes:

#EXTINF:0,Das Erste HD
#EXTVLCOPT:network-caching=1000
rtsp://10.89.89.1:554/?avm=1&freq=314&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=1&pids=0,16,17,18,20,5100,5101,1170,1176,2171,5102,5103,5104,5105,5106,5108,5172

Im Gegensatz dazu wird bei Magenta TV ja immer von so etwas hier geredet:

rtp://87.141.215.251@232.0.20.85:10000

Vllt. liege ich damit ja auch völlig falsch, aber könnte es nicht sein, dass ich bei mir eigentlich nur den rtsp Stream auf Port 554 der Fritzbox (IP 10.89.89.1) an OPNsense-WAN (IP 10.89.89.2) und dann OPNsense-LAN (IP 10.5.5.1) "durchschleifen" muss?

Aber wahrscheinlich sind auch diese Frequenzangaben etc. wichtig? (siehe oben im Beispiel von Das Erste HD)?

Oder aber sind gar die "externen IPs" wichtig, die ich dank der heise-Anleitung zwar von Magenta TV der Telekom kenne, aber leider nicht von PYUR (ehemals Tele Columbus)?


PS: Und wie ich gerade mitbekomme, kommt dann später auch noch eine zusätzliche Herausforderung auf mich zu, nämlich die Konfiguration meiner Unifi-Switche, die aber hier sehr gut erklärt ist (wenn auch leider wieder nur für Magenta TV): https://die25stestunde.de/telekom-magenta-tv-mit-unifi-hardware/#3-3-igmp-proxy-mittels-config-gateway-json-aktivieren
#40
Hallo zusammen,

direkt an der Fritzbox angestöpselt funktioniert das schon wunderbar (u.a. per VLC-Player oder auch mit den AVM Apps auf dem Mobiltelefon).

Da ich die Fritzbox aber nur für Festnetz-Telefonie und "als Modem" nutzen möchte, ist mein Ziel, dass das auch hinter meiner "Double-NAT"-Konstruktion klappt.

Aktuell funktioniert das in meinem "richtigen Netz" (also hinter meiner OPNsense) nämlich noch nicht ...

Ich kann da zwar schon die Senderliste doppelklicken im VLC (diese wurde als tvsd.m3u sowie tvhd.m3u aus der Fritzbox exportiert) und sehe auch (in der Fritzbox), dass der jeweils gewählte Sender tatsächlich auch abgespielt/gestreamt wird.

Allerdings kommt weder Bild noch Ton und nach 1-2 Minuten wird automatisch auf den nächsten Sender gewechselt.

Soweit ich das verstehe, ist das ganze Thema recht komplex?

Denn zum einen muss ich wohl die Ports 10000-10500 "erlauben" und dazu ist dann auch noch IGMPv3 (inkl. 'cascading') wichtig?

Ich habe mir den "IGMP Proxy" auch schon installiert, finde für dessen Einrichtung aber leider keine richtige Anleitung ...

Diese hier https://docs.opnsense.org/manual/how-tos/orange_fr_tvf.html bezieht sich ja eher auf Leute, die das ganze direkt in der OPNsense "anzapfen" wollen, also ohne Fritzbox.

Bei mir ist das IPTV-Signal dank der Fritzbox ja eigentlich schon da – ich weiß nur leider nicht, was genau ich einstellen muss, damit das dann z.B. auch auf einem Rechner hinter meiner OPNsense ankommt?

Danke vielmals für Hilfe!

PS: Und noch als Ergänzung – "Multicast" ist wohl ebenfalls wichtig, sonst klappt es nicht, siehe:

https://avm.de/service/fritzbox/fritzbox-7530/wissensdatenbank/publication/show/1422_Live-TV-Wiedergabe-startet-nicht/
#41
Ok, bin mittlerweile einen entscheidenden Schritt weiter ... aber leider immer noch nicht am Ziel.

Aber immerhin – externe DNS-Auflösungen funktionieren jetzt auch mit dem Eintrag meiner LAN IP (statt der 127.0.0.1) unter Services / Unbound DNS / General / Custom options

forward-zone:
name: ,,."
forward-addr: 10.5.5.1@53530


Entsprechende steht nun unter Services / BIND / Configuration / Listen IPs ebenfalls meine LAN IP (statt der 127.0.0.1)

10.5.5.1

Mein Fehler beim vorherigen Versuch war folgender: Ich hatte lediglich unter Firewall / Rules / Floating die Destination von 127.0.0.1 auf 10.5.5.1 für den Port 53530 angepasst.

Zusätzlich musste ich aber auch noch unter Firewall / NAT / Port Forward die Regel anpassen!

(siehe Screenshot Firewall-NAT-PortForwarding.png)

Das heißt also, die Notizen ganz am Ende dieser Dokumentation habe ich jetzt korrekt am laufen:

https://docs.opnsense.org/manual/how-tos/bind.html

Und eigentlich sollten mit genau dieser Einstellung dann ja auch die Unbound DNS Overrides funktionieren, richtig?

Leider werden lokale Host-Namen bei mir aber immer noch nicht aufgelöst (da ist der Stand also immer noch wie zuvor beschrieben).  :-[

Woran liegt das? Danke für Ideen und Vorschläge!
#42
Vorweg: Wie schon erwähnt, externe Adressen werden sowohl per Pi-hole als auch per OPNsense wie gewünscht aufgelöst, das ist nicht das Problem.

Wenn ich an einem Rechner in meinem Netzwerk den Pi-hole nach dem iMac (also einer internen Maschine) frage, bekomme ich folgende Antwort (das klappt also):

dig @10.89.89.11 -p 53 imac.localdomain

; <<>> DiG 9.10.6 <<>> @10.89.89.11 -p 53 imac.localdomain
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41291
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
imac.localdomain. 2 IN A 10.5.5.199

;; Query time: 29 msec
;; SERVER: 10.89.89.11#53(10.89.89.11)
;; WHEN: Wed Aug 12 22:46:09 CEST 2020
;; MSG SIZE  rcvd: 61


Und auch die Rückwärstauflösung klappt (da kommt die Antwort jedoch definitiv nur vom Pi-hole, nicht von der OPNsense):

host 10.5.5.199     
199.5.5.10.in-addr.arpa domain name pointer imac.localdomain.


Wenn ich mich per SSH auf meiner OPNsense einlogge, kann ich auch dort den iMac erfolgreich abfragen:

dig @127.0.0.1 -p 53 imac.localdomain

; <<>> DiG 9.16.5 <<>> @127.0.0.1 -p 53 imac.localdomain
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58368
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
imac.localdomain. 3600 IN A 10.5.5.199

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 12 22:46:48 CEST 2020
;; MSG SIZE  rcvd: 61


Und auch direkt auf der OPNsense klappt die Rückwärtsauflösung:

host 10.5.5.199
199.5.5.10.in-addr.arpa domain name pointer imac.localdomain.


Was jedoch nach wie vor nicht klappt, ist die Abfrage von einem beliebigen Rechner im Netzwerk aus direkt auf der OPNsense:

dig @10.5.5.1 -p 53 imac.localdomain

; <<>> DiG 9.10.6 <<>> @10.5.5.1 -p 53 imac.localdomain
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42381
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
. 9563 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020081202 1800 900 604800 86400

;; Query time: 31 msec
;; SERVER: 10.5.5.1#53(10.5.5.1)
;; WHEN: Wed Aug 12 22:57:44 CEST 2020
;; MSG SIZE  rcvd: 120


:(
#43
Aber ich lasse das trotzdem mal auf TCP/UDP stehen, denn dazu habe ich das hier gefunden:

https://www.infoblox.com/dns-security-resource-center/dns-security-faq/is-dns-tcp-or-udp-port-53/

War also grundsätzlich ein guter Hinweis.

Bin trotzdem mal gespannt, wie das Problem letztlich zu lösen ist. Die erfahreneren Leute aus diesem Forum sind glaube ich aktuell alle noch in ihrem wohlverdienten Ulraub. Es sei ihnen natürlich gegönnt.  :)
#44
Das ändert leider nichts, auch wenn TCP/UDP auf Port 53 und 53530 erlaubt ist.

Es hätte mich ehrlich gesagt auch gewundert – denn grundsätzlich klappte DNS ja schon, wenn nur UDP auf Port 53 und 53530 erlaubt war.
#45
Quote from: hopper on August 12, 2020, 09:30:30 AM
Versuchs mal mit TCP an Stelle von UDP

Hallo Rainer,

an welcher Stelle genau meinst Du?

Muss jetzt leider erst mal los und kann mir das erst abends ansehen ...

Danke & beste Grüße,
Marcel