Hi,
also bei mir zu Hause steht der Wechsel von pfSense zu OPNsense ins Haus sobald die IGMPv3 Switche da sind,
momentan habe ich es auf Cisco 2960L (nur IGMPv2) mit pfSense am laufen - war ein Horror das zum Laufen zu bringen.
Da ich nur kommendes Wochenende Zeit hab will ich vorbereitet sein das möglichst samt neuer Switche alles zum Laufen zu bringen und da wollte ich mal Nachfragen ob erstens das Problem mit dem TFTP Proxy der ja zwingend von MagentaTV gebraucht wird gelöst ist auf OPNsense und zweitens gibt es schon ein HowTo dafür ?
Viele Grüße
JBBERLIN
Hi,
würde mich auch interessieren. Gibt es eine Quelle um welches Problem es sich genau handelt? Bei mir läuft das Update nicht bzw. der Download für das Update bricht mit "Fehler" ab.
Grüße
Sven
Anscheinend nicht... :(
Ich hab's schon alles hinbekommen, samt IGMP Proxy (aus dem pf Forum) bis auf den TFTP Boot, auf der pf gibt es dafür im GUI einen Schalter.
Jetzt bin ich auf einer Doppelten NAT Lösung (Draytek 165 als Router der per VLAN das Enteritan Netz versorgt vor der OPNsense) gelandet, die diese Wochenende umgesetz wird weil meine Versuche mit Firewallregeln das auf der OPNsense umzusetzen die letzten Nächte gescheitert sind.
Good news: Ich habe es hinbekommen:
1.:/usr/local/etc/inc/plugins.inc.d/tftpproxy.inc mit diesem inhalt anlegen:
<?php function tftpproxy_enabled(){ return true;} function tftpproxy_firewall($fw){ if (!tftpproxy_enabled()) { return; } $fw->registerAnchor('tftp-proxy/*', 'nat'); $fw->registerAnchor('tftp-proxy/*', 'rdr'); $fw->registerAnchor('tftp-proxy/*', 'fw');}
2.: Firewallregeln neu laden
3.: Prüfen ob die "anchors" nun der Firewall bekannt sind
root@OPNsense01:~ # pfctl -sr | grep anchor
anchor "tftp-proxy/*" all
root@OPNsense01:~ # pfctl -sn | grep anchor
nat-anchor "tftp-proxy/*" all
rdr-anchor "tftp-proxy/*" all
4.: /etc/inetd.conf um diese Zeile ergänzen:
acmsoda dgram udp wait root /usr/libexec/tftp-proxy tftp-proxy -v5.:Tftp-proxy von hand starten (habe mich noch nicht mit dem automatischen start beschäftigt):
/etc/rc.d/inetd onestart[/li][/list]
6.: anschließend Prüfen, ob Port 6969 vom inetd tftp-proxyverwendet wird:
root@OPNsense01:~ # sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root inetd 90139 5 udp4 *:6969 *:*
6.: Die "Port Forward" NAT Regel "Rule1" (siehe Bild) erstellen
7.: Die "Outbound" NAT Regel "Rule2" (siehe Bild) ganz oben in der Liste erstellen (die Reihenfolge ist wichtig!!!)
Ich hoffe, ich habe nichts vergessen (und, dass das nächste Update nicht wieder alles zerstört...)
Sorry für die katastrophale formatierung - wenn ich lust habe, erstelle ich noch eine schönere Anleitung.
Viel Erfolg,
BlaCKJaCK
Echt stark. Ich hatte selbst mal versucht analog zur FTP-proxy Anleitung das für TFTP umzusetzen, aber hat nicht getan, wie es sollte. Werde es gleich mal ausprobieren und Rückmeldung geben, ob es gemäß der Anleitung so klappt.
Update: Sehe gerade anhand der vorhandenen .inc Datei, das ich schon mal soweit war. Anker sind auch vorhanden, TFTP-Proxy Port offen, Anfrage geht an den TFTP-Server aber es kommt nix zurück. :-/ Mal schauen wo es da klemmt. Arbeite mit öffentlichen IPs, da wird kein NAT benötigt, aber durch den Proxy kommt doch eh nur die Interface-IP am TFTP-Server an. Wozu genau das NoNAT? Viell. ist das die Crux.
Scheinbar funktioniert das mit Proxy bei mir nicht. Er macht den Port nicht auf, deswegen kommt ICMP unreachable zurück, statt das die Datei transferiert wird.
08:42:16.952494 IP opnsense.57115 > tftp-server.tftp: 30 RRQ "pub.key" octet blksize 1416
08:42:16.953305 IP tftp-server.53052 > opnsense.57115: UDP, length 15
08:42:16.955524 IP opnsense > tftp-server: ICMP opnsense udp port 57115 unreachable, length 36
syslog on opnsense:
Apr 23 08:42:16 fw01 tftp-proxy[9483]: tftpclient:5542 -> 127.0.0.1:6969/proxyIP:57115 -> TFTP-Server:69 "RRQ pub.key"
Apr 23 08:42:17 fw01 kernel: pfr_update_stats: assertion failed.
Hi hbc.
Wenn du innen wie außen mit Public IPs arbeitest und garnicht NATen musst, verstehe ich nicht, warum du nicht einfach (auch wenn es nicht super sicher ist) einfach UDP zwischen dem Telekom TFTP Server und deinem receiver freischaltest. Dann hättest du das "stateful" problem ja umgangen.
Ich habe noch einen globalen Haken gesetzt (eigentlich aus einem anderen Grund) der vielleicht eine auswirkung haben könnte - aber einen logischen zusammenhang sehe ich zu deinem Problem auf die Schnelle nicht:
Firewall: Settings: Advanced
--> Disable reply-to: aktiviert
Naja, Fakt ist, das es nix mit Telekom zu tun hat. Es ist ein Management-Netzwerk für Switche und ein Server im Servernetz. Ich hätte gerne einen Public-Key auf die Switche geladen und das geht nur per TFTP oder USB. Dummerweise hat der eine Switch kein USB.
Klar kann ich riesige Löcher in die Firewall klopfen und global UDP freigeben. Ich hätte eben gerne einen Proxy als dauerhafte Lösung elleganter gefunden. Jetzt hab ich halt eine Wand (Firewall), die ich bei Bedarf eintrete (Allow all Regel aktvieren) oder wieder zumauer (Allow all deaktivieren).
Nicht, was ich als schön empfinde und sicherlich nichts dauerhaftes. Da stelle ich dann lieber extra einen Server ins Managementnetz, um diesen einen Public-Key zu hosten.
Quote from: BlaCKJaCK on April 22, 2020, 10:53:51 PM
Good news: Ich habe es hinbekommen:
....
3.: Prüfen ob die "anchors" nun der Firewall bekannt sind
root@OPNsense01:~ # pfctl -sr | grep anchor
anchor "tftp-proxy/*" all
root@OPNsense01:~ # pfctl -sn | grep anchor
nat-anchor "tftp-proxy/*" all
rdr-anchor "tftp-proxy/*" all
...
BlaCKJaCK
Hi,
sorry, wenn ich den alten Thread ausgrabe, aber da ich grade am OPNSsense debuggen bin (MagentaTV hat seit gestern regelmässige Aussetzer...), dachte ich mir ich kann mal eben den tftp-proxy integrieren laut deiner Anleitung.
Mal eben :)
Ich habe alles so konfiguriert wie beschrieben, allerdings zeigt er mir die Anker nicht an.
Wodran kann das liegen?
Für jeden Tip dankbar.
Christian
Hi Christian,
hast du anschließend die Firewallregeln neu geladen? Mehr war bei mir nicht notwendig.
Allerdings haben die Aussetzer bei deinem Receiver wahrscheinlich nichts mit dem TFTP Proxy zu tun. Den braucht man (meines Erachtens nach) nur um einen "Jungfräulichen" Receiver (ohne Firmware, nur mit Bootloader) mit einer neuen Firmware zu beglücken. Wenn deiner Bootet solltest du keine Probleme haben.
Die Aussetzer (wenige Sekunden nach dem Senderwechsel?!) würde ich mal auf die IGMP Problemchen mit opnsense und dem nicht ganz aktuellen IGMPProxy zurückführen. Mit dem aktuell verfügbaren igmp-proxy Plugin werden nach innen keine IGMPv3 Nachrichten verschickt was der Receiver nicht witzig findet.
Anscheinend steht hier im letzten commit (https://github.com/pali/igmpproxy) eine gefixte Version zu verfügung - aber ich habe keine Ahnung, wie man sie kompiliert und für einen Test in die Firewall rein bringt (und schon garnicht, wie ich jemand dazu bringen könnte das Plugin zu aktualisieren).
Möge derjenige Vortreten, der das igmpproxy Problem lösen kann.
Gruß BlaCKJaCK
Würde die Anleitung für TV7 nicht auch auf MagentaTV zutreffen? Ich hab's selbst noch nicht getestet...
https://forum.opnsense.org/index.php?topic=17865.msg81028#msg81028
HI Lumpy,
MagentaTV ist nicht so einfach - braucht IGMPv3 zwischen Router und Receiver und das wurde wohl erst vor wenigen Wochen implementiert.
Hier gibts ein paar hintergründe:
https://forum.opnsense.org/index.php?topic=12780.msg60031#msg60031
(https://forum.opnsense.org/index.php?topic=12780.msg60031#msg60031)
Gruß BlaCKJaCK