Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 27 subscribers
  • Views 7786 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Update eines IP-Telefon hinter RED nicht möglich

*Ludo*

Hallo liebe Sophos-Gemeinde,

ich habe eine neue UNIFY OpenScape Business TK-Anlage in meinem Hauptnetz und unter anderem hinter einer RED in einer Außenstelle IP-Telefone. Zwischen meinem Haupnetz und dem RED-Netz ist Any to Any zugelassen. Ich habe aber nun das Problem, dass die IP-Telefone in dem RED-Netz keine Updates von der Anlage ziehen. Auch das Displaylogo das die Anlage verteilt wird auf die Geräte im RED-Netz nicht übermittelt. Telefonie wiederum funktioniert ohne Probleme....

Hat jmd. von euch ne Idee/Ahnung, woran das liegen könnte?



This thread was automatically locked due to age.
Parents
  • 0

    Deine Infos sind sehr allgemein. Wie wird das Update im Hauptnetz durchgeführt? Über Bootp? Kann der Server auf dem die Updates liegen erreicht werden (prüfen auch wenn da Any  to Any steht). Ggf. DHCP Optionen der beiden Netze vergleichen.

  • 0 in reply to BeEf

    Hi,

     

    ja das mit den Infos ist immer so ein Thema - aber du hast Recht....

     

    Auf den IP-Telefonen wird ein Update Service (DLS) per IP angegeben - in meinem Fall die TK-Anlage aus dem Hauptnetz via Port 18443. Der Server, auf dem die Updates liegen ist sozusagen die TK-Anlage. Die Telefone fragen alle 300 Sekunden bei der Anlage an, ob ein Update vorliegt. Im Log der Filterregel Any-to-Any wird auch nichts geblockt...
    Die Telefone aus dem RED-Netz ziehen sich via DHCP-Relay eine IP von unserem Windows DC - die DHCP-Optionen der beiden Bereiche sind sozusagen identisch bis auf die IP-Adressen natürlich....

  • 0 in reply to *Ludo*

    Ok.

    Das Hauptnetz und das RED Netz werden auf der Firewall geroutet ?! Es gibt da kein NAT oder ähnliches (bin mir nicht sicher ob NAT an der Stelle überhaupt geht).

    Zur weiteren Fehlersuche würde ich einen PC Client in das RED Netz hängen und mit einem Portscanner testen ob man den Port erreichen kann bzw. ob er offen ist.

    Des weiteren würde ich auf der Telefonanlage prüfen, ob es dort eine Firewall oder sonstige Einschränkungen gibt die verhindern dass das Update geladen wird.

    Gibt es neben dem Hauptnetz und RED Netz weitere (direkt) geroutete Netze ohne daß die Firewall dazwischenhängt? Wenn ja funktioniert das Update von da?

     

     

  • 0 in reply to *Ludo*

    Hi,

    (Sorry, my German-speaking brain isn't creating thoughts at the moment. [:(])

    Does doing #1 in Rulz give you any insights?

    MfG - Bob (Bitte auf Deutsch weiterhin.)

  • 0 in reply to BAlfson

    Hi,

    im Liveprotokoll der Firewallregel ist alles grün - es wird nichts verworfen.... Auch jeglicher Verkehr von der IP-Adresse des Gerätes über/zu Port 18443.... Nichts rotes!

    Leider ist dies das einzige separate Netz - ich habe also leider keinen Funktionsvergleich zu einem anderen Netz (außer das interne)....

    Nach Rücksprache mit dem Support der TK-Anlage muss es so funktionieren.... Es bedarf auch keinerlei spezieller DHCP-Optionen....

    Einziges Thema was noch in den Raum geworfen wurde ist der Punkt MTU - die TK-Anlage erwartet eine MTU von 1500... Wie gesagt, im internen Netz funktioniert das Update... Die MTU an der Schnittstelle wo die RED gebunden ist steht auch auf 1500.

    Viell. kommt der Updateservice nicht ganz damit zurecht? Wobei ein Bekannter von mir ein ähnliches Szenario jedoch mit anderer Firewall hat und bei dem funktioniert`s auch....

    C:\>ping 192.168.46.106 -f -l 1473

    Ping wird ausgeführt für 192.168.46.106 mit 1473 Bytes Daten:
    Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
    Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
    Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
    Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

    Ping-Statistik für 192.168.46.106:
        Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
        (100% Verlust),

    C:\>ping 192.168.46.106 -f -l 1472

    Ping wird ausgeführt für 192.168.46.106 mit 1472 Bytes Daten:
    Antwort von 192.168.46.106: Bytes=1472 Zeit=39ms TTL=127
    Antwort von 192.168.46.106: Bytes=1472 Zeit=38ms TTL=127
    Antwort von 192.168.46.106: Bytes=1472 Zeit=39ms TTL=127
    Antwort von 192.168.46.106: Bytes=1472 Zeit=41ms TTL=127

    Ping-Statistik für 192.168.46.106:
        Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
        (0% Verlust),
    Ca. Zeitangaben in Millisek.:
        Minimum = 38ms, Maximum = 41ms, Mittelwert = 39ms

Reply
  • 0 in reply to BAlfson

    Hi,

    im Liveprotokoll der Firewallregel ist alles grün - es wird nichts verworfen.... Auch jeglicher Verkehr von der IP-Adresse des Gerätes über/zu Port 18443.... Nichts rotes!

    Leider ist dies das einzige separate Netz - ich habe also leider keinen Funktionsvergleich zu einem anderen Netz (außer das interne)....

    Nach Rücksprache mit dem Support der TK-Anlage muss es so funktionieren.... Es bedarf auch keinerlei spezieller DHCP-Optionen....

    Einziges Thema was noch in den Raum geworfen wurde ist der Punkt MTU - die TK-Anlage erwartet eine MTU von 1500... Wie gesagt, im internen Netz funktioniert das Update... Die MTU an der Schnittstelle wo die RED gebunden ist steht auch auf 1500.

    Viell. kommt der Updateservice nicht ganz damit zurecht? Wobei ein Bekannter von mir ein ähnliches Szenario jedoch mit anderer Firewall hat und bei dem funktioniert`s auch....

    C:\>ping 192.168.46.106 -f -l 1473

    Ping wird ausgeführt für 192.168.46.106 mit 1473 Bytes Daten:
    Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
    Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
    Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
    Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

    Ping-Statistik für 192.168.46.106:
        Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
        (100% Verlust),

    C:\>ping 192.168.46.106 -f -l 1472

    Ping wird ausgeführt für 192.168.46.106 mit 1472 Bytes Daten:
    Antwort von 192.168.46.106: Bytes=1472 Zeit=39ms TTL=127
    Antwort von 192.168.46.106: Bytes=1472 Zeit=38ms TTL=127
    Antwort von 192.168.46.106: Bytes=1472 Zeit=39ms TTL=127
    Antwort von 192.168.46.106: Bytes=1472 Zeit=41ms TTL=127

    Ping-Statistik für 192.168.46.106:
        Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
        (0% Verlust),
    Ca. Zeitangaben in Millisek.:
        Minimum = 38ms, Maximum = 41ms, Mittelwert = 39ms

Children
No Data