Telekom MagentaTV - Ist eigentlich schon das TFTP Proxy Problem gelöst ?

[JBBERLIN]

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

[Gortosch]

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

[JBBERLIN]

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.

[BlaCKJaCK]

Good news: Ich habe es hinbekommen:


1.:/usr/local/etc/inc/plugins.inc.d/tftpproxy.inc mit diesem inhalt anlegen:

Code: [Select]

<?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

Code: [Select]

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:

Code: [Select]

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):

Code: [Select]

/etc/rc.d/inetd onestart[/li][/list]
6.: anschließend Prüfen, ob Port 6969 vom inetd tftp-proxyverwendet wird:

Code: [Select]

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

[hbc]

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.

Code: [Select]

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:

Code: [Select]

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.


[BlaCKJaCK]

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

[hbc]

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.

[torcolato]

Good news: Ich habe es hinbekommen:


....
3.: Prüfen ob die "anchors" nun der Firewall bekannt sind

Code: [Select]

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

[BlaCKJaCK]

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

[Lumpy]

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

[BlaCKJaCK]

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


Gruß BlaCKJaCK