7
VoIP Telefon bekommt TFTP Connection Refused
Hallo zusammen
Kurze Übersicht:
VMware Cloudlösung
1x pfSense 172.16.200.254
1x Telefonanlage 172.16.200.10
pfSense baut drei IPsec VPN zu drei unabhängigen Standorten auf.
Alle Standorte haben das gleiche Problem, daher gehe ich auf einen Standort ein!
Standort 1
Fortigate Firewall mit IPsec VPN zu VMware Cloudlösung
192.168.5.254
IP Telefon: 192.168.5.20-60
Problem:
IP Telefone müssen die Konfiguration via TFTP von der Telefonanlage 172.16.200.10 holen.
Telefone melden jedoch TFTP Connection Refused.
Ping, HTTP, SSH ect. funktionieren von beiden Seiten jeweils gegenseitig!
Direktes Routing, keine Umwege sondern direkt via den IPsec VPN.
Wireshark meldet folgendes:
Lokales Telefon: 192.168.5.28
Telefon versucht via TFTP einen „Read Request“ auf die PBX 172.16.200.10 zu machen.
PBX möchte die Konfig Datei zurückschicken, meldet aber „Port unreachable“
Wireshark Ausschnitt im Anhang.
Ebenso von einem IP Telefon aus dem 192.168.52.0/24 Netz.
Was könnte das Problem sein?
Ich hab nur auf die pfSense Zugriff, Fortigate wird nicht von mir gemanagt.
Auf der pfSense unter Advanced -> Firewall/NAT -> TFTP Proxy hab ich das LAN aktiviert und einmal neugestartet.
Keine Änderung.
Kurze Übersicht:
VMware Cloudlösung
1x pfSense 172.16.200.254
1x Telefonanlage 172.16.200.10
pfSense baut drei IPsec VPN zu drei unabhängigen Standorten auf.
Alle Standorte haben das gleiche Problem, daher gehe ich auf einen Standort ein!
Standort 1
Fortigate Firewall mit IPsec VPN zu VMware Cloudlösung
192.168.5.254
IP Telefon: 192.168.5.20-60
Problem:
IP Telefone müssen die Konfiguration via TFTP von der Telefonanlage 172.16.200.10 holen.
Telefone melden jedoch TFTP Connection Refused.
Ping, HTTP, SSH ect. funktionieren von beiden Seiten jeweils gegenseitig!
Direktes Routing, keine Umwege sondern direkt via den IPsec VPN.
Wireshark meldet folgendes:
Lokales Telefon: 192.168.5.28
Telefon versucht via TFTP einen „Read Request“ auf die PBX 172.16.200.10 zu machen.
PBX möchte die Konfig Datei zurückschicken, meldet aber „Port unreachable“
Wireshark Ausschnitt im Anhang.
Ebenso von einem IP Telefon aus dem 192.168.52.0/24 Netz.
Was könnte das Problem sein?
Ich hab nur auf die pfSense Zugriff, Fortigate wird nicht von mir gemanagt.
Auf der pfSense unter Advanced -> Firewall/NAT -> TFTP Proxy hab ich das LAN aktiviert und einmal neugestartet.
Keine Änderung.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 388285
Url: https://administrator.de/contentid/388285
Ausgedruckt am: 23.11.2024 um 13:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
findest du es Optimal, das um 22.15 anzugehen, wenn du den Partner, der wohl das elementare Problemgerät (Forti..) managed vermutlich auf keinen Fall erreichen kannst?
Das Konstrukt an sich ist aber auch schon relativ komisch...
was für eine TK ist es denn?
findest du es Optimal, das um 22.15 anzugehen, wenn du den Partner, der wohl das elementare Problemgerät (Forti..) managed vermutlich auf keinen Fall erreichen kannst?
Das Konstrukt an sich ist aber auch schon relativ komisch...
was für eine TK ist es denn?
Guten Abend.
Gruß,
Dani
Ping, HTTP, SSH ect. funktionieren von beiden Seiten jeweils gegenseitig!
schön gut, aber wenn Port 69/UDP nicht im jeweilige Regelwerk freigeben ist, hilft dir das nicht. Nochmals alle Regelwerke auf Korrektheit prüfen. Auf der pfSense unter Advanced -> Firewall/NAT -> TFTP Proxy hab ich das LAN aktiviert und einmal neugestartet.
Firewall/NAT trifft doch gar nicht zu. Du routest doch zwischen alle Netzen oder? Kannst meiner Meinung nach wieder deaktivieren.Gruß,
Dani
Laut Sniffer Trace sieht es ja so aus als ob der TFTP Read request auch am Ziel ankommt, denn der Server selber (172.16.200.10) schickt ja ein ICMP unreachable an den Client zurück.
Man kann in der Tat nur vermuten das dort eine lokale Firewall aktiv ist die einen TFTP Request aus fremden IP Netzen verhindert. Bei Windows ist das ja der Regelfall.
Man kann in der Tat nur vermuten das dort eine lokale Firewall aktiv ist die einen TFTP Request aus fremden IP Netzen verhindert. Bei Windows ist das ja der Regelfall.
Hallo,
O.K. - der TFTP Server nutzt wie üblich Port 69.
Welche Ports werden denn für den Datentransfer genutzt (steht in der Serverkonfiguration bzw. der Serverdoku) und hast Du die auch freigegeben?
Gruß,
Jörg
O.K. - der TFTP Server nutzt wie üblich Port 69.
Welche Ports werden denn für den Datentransfer genutzt (steht in der Serverkonfiguration bzw. der Serverdoku) und hast Du die auch freigegeben?
Gruß,
Jörg
Hallo,
1. sind auf der pfSense, auf der Fortigate und auf der PBX die richtigen Firewallregeln erstellt ?
Ist der TFTP server richtig konfiguriert ?
2. enable logging auf allen 4 Komponenten für jedwelchen Traffic von 192.168.5.28 nach 172.16.200.10 und zurück; ggf zusätzlich noch die Broadcasts von 192.168.5.28 und 172.16.200.10 mitloggen.
Dann solltest du den Fehler finden buw. eingrenze können; ggf. poste die Logs hier.
der TFTP proxy wird wahrscheinlich nicht benötigt und ist eine mögliche Zusätzliche Fehlerquelle
Gruß
CH
1. sind auf der pfSense, auf der Fortigate und auf der PBX die richtigen Firewallregeln erstellt ?
Ist der TFTP server richtig konfiguriert ?
2. enable logging auf allen 4 Komponenten für jedwelchen Traffic von 192.168.5.28 nach 172.16.200.10 und zurück; ggf zusätzlich noch die Broadcasts von 192.168.5.28 und 172.16.200.10 mitloggen.
Dann solltest du den Fehler finden buw. eingrenze können; ggf. poste die Logs hier.
der TFTP proxy wird wahrscheinlich nicht benötigt und ist eine mögliche Zusätzliche Fehlerquelle
Gruß
CH
Denk bitte daran, dass TFTP nur für Anfragen und den Verbindungsaufbau Port 69 UDP nutzt.
Im Anschluss findet die Kommunikation und Datenübertragung über zufällige individuell vergebene Port-Nummern zwischen 1024 UDP und 65535 UDP statt.
Das muss bei der Firewall Konfiguration berücksichtigt werden.
Viele Firewalls bieten hierfür die Möglichkeit direkt per Häckchen anklicken den Datenaustausch für TFTP zu ermöglichen.
Ob hier jedoch wie du es bereits gemacht hast "TFTP Proxy" das richtige ist und ob für TFTP ein Proxy hier notwendig ist kann ich nicht sagen.
Würde dir aber empfehlen speziell für die Firewall nochmal zum Thema TFPT zu recherchieren.
Ggfs. auch prüfen ob an anderer Stelle als die PfSense noch eine Firewall (Software Firewall evtl.) hier die Verbindung blockt.
Ich hab meine Abschlussarbeit zum Thema OS Installation via PXE gemacht und hab dafür auch TFTP benötigt, das hat mit ner Sophos damals auch etwas Probleme bereitet.
Im Anschluss findet die Kommunikation und Datenübertragung über zufällige individuell vergebene Port-Nummern zwischen 1024 UDP und 65535 UDP statt.
Das muss bei der Firewall Konfiguration berücksichtigt werden.
Viele Firewalls bieten hierfür die Möglichkeit direkt per Häckchen anklicken den Datenaustausch für TFTP zu ermöglichen.
Ob hier jedoch wie du es bereits gemacht hast "TFTP Proxy" das richtige ist und ob für TFTP ein Proxy hier notwendig ist kann ich nicht sagen.
Würde dir aber empfehlen speziell für die Firewall nochmal zum Thema TFPT zu recherchieren.
Ggfs. auch prüfen ob an anderer Stelle als die PfSense noch eine Firewall (Software Firewall evtl.) hier die Verbindung blockt.
Ich hab meine Abschlussarbeit zum Thema OS Installation via PXE gemacht und hab dafür auch TFTP benötigt, das hat mit ner Sophos damals auch etwas Probleme bereitet.
Es reicht ja wenn er den Port der Telefonanlage mal mirrort (spiegelt) und den Traffic dort mit dem Wireshark mal ansieht.
Das wäre das sinnvollste zu checken ob die TFTP Requests der Telefone dort auch überhaupt ankommen. Das wäre der richtige Weg und nicht die Telefone selber ansehen.
Wenn der Trace oben vom Serverport ist und die 192.168.5.28 ein Telefon, dann würde der Server ja direkt die unreachable Message schicken, was dann wieder klar zeigen würde das die TFTP Requests dort ankommen.
Kardinalsfrage ist also: WO genau ist gesniffert worden ?
Das wäre das sinnvollste zu checken ob die TFTP Requests der Telefone dort auch überhaupt ankommen. Das wäre der richtige Weg und nicht die Telefone selber ansehen.
Wenn der Trace oben vom Serverport ist und die 192.168.5.28 ein Telefon, dann würde der Server ja direkt die unreachable Message schicken, was dann wieder klar zeigen würde das die TFTP Requests dort ankommen.
Kardinalsfrage ist also: WO genau ist gesniffert worden ?
