Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 25 subscribers
  • Views 5990 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

RED50 Problem

Alf17
Hallo,

wir nutzen die UTM 320(Firmware 9.207-19).
Unsere Zweigstellen sind bisher immer über RED10 mit der UTM verbunden.
Die Red's verbinden sich über 2 verschiedene Leitungen mit der UTM in der Zentrale.
Entweder red1.***.com oder red2.***.com.
Ca. 20 RED10 sind im Einsatz. 10 Stück verbinden sich mit red1.***.com und 10 Stück mit red2.***.com.

Nun das eigentlich Problem:
In einer neuen Aussenstelle wollen wir eine RED50 einsetzen.
Wenn als erster UTM-Hostname bei der Konfiguration red1.***.com eingestellt wird, baut die RED50 keine Verbindung auf. Auf dem Display der RED50 steht dann immer: stabilizing peers.

Wähle ich als ersten UTM-Hostname allerdings red2.***.com aus, dann baut die RED50 ohne Probleme den Tunnel auf.

Hat jemand dieses Problem schon einmal gehabt oder einen entsprechenden Lösungsvorschlag?

Herzlichen Dank.


This thread was automatically locked due to age.
Parents
  • 0
    Ah, habe gerade ein ähnliches Problem und hier die Lösung gefunden.

    Das ist aber ein fieser Bug der UTM. Bei einem RED10 über Port tcp/3400 wird die korrekte Absender-IP genommen (nämlich die gleiche, über die auch die Pakete vom RED10 aus dem Internet rein kommen).

    Beim RED50 ist das nur für die Kommunikation über den Port tcp/3400 so, bei der Kommunikation über Port udp/3410 wird der falsche Quell-Port für die Bestätigungs-Pakete Richtung RED50 von der UTM genommen. Das RED50 wird diese Pakete vermutlich verwerfen und deshalb kommt es über den Status "Stabilizing peers" nicht hinweg.

    Das Problem taucht nur auf, wenn man auf der Internet-Leitung mehrere IP-Adressen nutzen kann und für die Kommunikation mit dem RED50 nicht die primäre des WAN-Interfaces, sondern eine zusätzliche virtuelle IP verwendet.

    Auf der UTM läuft parallel dazu auch noch der Prozess "mdw.plx" Amok und sorgt für dauerhaft hohe CPU-Last zwischen 30-50%.

    Werde dazu morgen mal ein Ticket bei Sophos aufmachen, ist ja nur ein kleines Problem was nur auftaucht, wenn man auf einer Internet-Leitung mehrere IP-Adressen nutzen kann und für das RED50 nicht die primäre IP-Adresse sondern eine der zusätzlichen, virtuellen IP-Adressen verwendet.

    Gruß
    Manuel

    PS: Ticket wurde heute geöffnet (Ticket-Nr. 4761837, falls jemand Bezug drauf nehmen möchte)
Reply
  • 0
    Ah, habe gerade ein ähnliches Problem und hier die Lösung gefunden.

    Das ist aber ein fieser Bug der UTM. Bei einem RED10 über Port tcp/3400 wird die korrekte Absender-IP genommen (nämlich die gleiche, über die auch die Pakete vom RED10 aus dem Internet rein kommen).

    Beim RED50 ist das nur für die Kommunikation über den Port tcp/3400 so, bei der Kommunikation über Port udp/3410 wird der falsche Quell-Port für die Bestätigungs-Pakete Richtung RED50 von der UTM genommen. Das RED50 wird diese Pakete vermutlich verwerfen und deshalb kommt es über den Status "Stabilizing peers" nicht hinweg.

    Das Problem taucht nur auf, wenn man auf der Internet-Leitung mehrere IP-Adressen nutzen kann und für die Kommunikation mit dem RED50 nicht die primäre des WAN-Interfaces, sondern eine zusätzliche virtuelle IP verwendet.

    Auf der UTM läuft parallel dazu auch noch der Prozess "mdw.plx" Amok und sorgt für dauerhaft hohe CPU-Last zwischen 30-50%.

    Werde dazu morgen mal ein Ticket bei Sophos aufmachen, ist ja nur ein kleines Problem was nur auftaucht, wenn man auf einer Internet-Leitung mehrere IP-Adressen nutzen kann und für das RED50 nicht die primäre IP-Adresse sondern eine der zusätzlichen, virtuellen IP-Adressen verwendet.

    Gruß
    Manuel

    PS: Ticket wurde heute geöffnet (Ticket-Nr. 4761837, falls jemand Bezug drauf nehmen möchte)
Children
No Data