RED down and up, Interface bleibt down

Wir haben ein ähnliches Problem. Wir haben kürzlich 22 RED 15 ausgerollt, und haben gelegentlich (ohne erkennbare Logik) das Problem, dass die Subnets hinter den REDs nach einem Verbindungsneuaufbau (DSL kurz unterbrochen etc.) nicht mehr erreichbar sind, obwohl der Tunnel steht. Ein Ein/Aus auf dem Interface der UTM hilft dann, bzw. ein Reboot des RED vorort. Wir haben einen SG310-Cluster hier mit UTM 9.355-1.

Wir öffnen heute einen Call dazu bei SOPHOS. Das Problem ist recht unangenehm, zumal man weder im Log noch über die Benachrichtigungen was mitbekommt. Für die UTM ist der Tunnel oben, auch wenn er IP-seitig nicht funktioniert. Erst die User vorort merken, das nichts geht.

mfg, Jan

Hallo zusammen,

wir haben das gleiche Problem. RED 15 hinter einer FritzBox 3xxx und dynamischer öffentlicher IP-Vergabe, Verbindung zu einer UTM120 mit Firmware 9.355-1 mit fester IP. Nach dem DSL-Reconnect der FritzBox sind keine Geräte des RED-Netzes vom UTM Netz aus pingbar. RED-Verbindung wird aber als "Online" in der UTM angezeigt, RED-Log zeigt auch keine Auffälligkeiten. DHCP auf der RED-Seite funktioniert ebenfalls nicht mehr.

Hat schon jemand mit der Firmware 9.4 getestet? https://blogs.sophos.com/2016/03/18/sophos-utm-elevated-9-4-is-now-available/

Viele Grüße,

Patrick

Ok, 9.401-11 ist drauf, wir beobachten...

Jan

Hallo zusammen,

habt Ihr das Problem mit den REDs noch?

Bei uns SG330 HA / RED 15 - FW 9.402-7 tritt genau dieses Problem auf. Nach einen DSL Reconnect auf der RED Seite wird die RED zwar als Online angezeigt es geht aber kein Traffic über den Tunnel. Laut Log reconnected sie auch ständig da kein PING/PONG über den Tunnel läuft.

Erst wenn ich die RED15 deaktiviere, das zugehörige Interface deaktiviere, dann ein paar Minuten warte und beides wieder aktiviere kommt der Tunnel wieder so hoch das Traffic drüber läuft.

Cheers Peter

Hi,

das was du beschreibst, scheint ein anderes Problem zu sein.

Bei unserem Thema war das RED ja verbunden, inkl. PING/PONG, es kam nur kein IP-Traffic zustande. Es hat auch nicht ständig reconnected. Dieses Problem ist bei uns seit 9.4.xx nicht mehr aufgetreten.

Mfg, Jan

Wir haben auch massive Problem mit den REDs

Phänomen 1: Tunnel baut sich ständig auf und wieder ab. So nicht benutzbar.

Phänomen 2: Tunnel bricht zusammen sobald eine RDP-Sitzung gestartet wird. dann dauert es wieder ewig bis der Tunnel steht. Sobald RDP kommt bricht der Tunnel wieder weg.

Wir haben 12x RED15 im Einsatz. davon ist mir nur eine bekannt die stabil läuft und bei 4 Kunden kommen massive Beschwerden.

zu Phänomen 1:

Aufbau TDSL16 - Fester IP - SG210 9.406003 zu UnityMedia 50 - Fritzbox  RED15 (per Zeitschaltuhr einmal in der Nacht eine Stunde aus, damit wird erträglch) Wenn es jdoch wieder anfängt hilft meist nur den Internet-Anschluss am Homeoffice für min. 5 Minuten vom netz nehmen. Neustarts der Interfaces in der SG beheben das ganze meist nicht. (ja des TDSL16 ist nur für die VPN'S dort hin zuständig, alles andere geht über den VDSL50)

Aufbau TDSL16 - Fester IP - SG210 9.406003 zu UnityMedia 150 - Lancom RED15

zu Phänomen 2:

Aufbau T-VDSL50 - Fester IP SG125 9.408004 zu T-VDSL100 Fritzbox RED15
Aufbau T-VDSL50 - Fester IP SG125 9.408004 zu T-ADSL16 Lancom RED15
Aufbau TDSL16 - Fester IP - SG210 9.407003 zu Vodaphone DSL16 EasyBox RED15
Aufbau TDSL16 - Fester IP - SG210 9.407003 zu T-DSL16 Speedport RED15

Was uns fast verrückt macht, die Tunnels werden fast ausschließlich in den Abendstunden benutzt wenn wir keinen Support anbieten. Dann stehen die Geschäftsführer daheim und kommen nicht in die Firma. Das booten des Routers und der RED Box hilft manchmal, aber nicht immer. Wenn wir dann am nächsten Tag nachschauen steht der Tunnel. den Abbruch durch RDP können wir meist nicht nachprüfen.

hier mal ein ausszug aus dem log:

2016:12:01-17:55:41 wsc-sop01 red_server[28535]: A35012848115668: command 'SYSSTATE unstable peer using stabilization timeout 30'

2016:12:01-17:55:41 wsc-sop01 red_server[28535]: A35012848115668: command 'SYSSTATE last stable peer status:'

2016:12:01-17:55:41 wsc-sop01 red_server[28535]: A35012848115668: command 'SYSSTATE 0 weight: 1 remote: 185.45.240.40 (dev 3), RX: miss 0/267, TX: miss 0/321'

2016:12:01-17:55:41 wsc-sop01 red_server[28535]: A35012848115668: command 'SYSSTATE current peer status:'

2016:12:01-17:55:42 wsc-sop01 red_server[28535]: A35012848115668: command 'SYSSTATE 0 weight: 1 remote: 185.45.240.40 (dev 3), RX: miss 0/267, TX: miss 0/321'

2016:12:01-17:55:42 wsc-sop01 red_server[28535]: A35012848115668: command 'CON_CLOSE reason=unstable_peer'

2016:12:01-17:55:42 wsc-sop01 red_server[28535]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A35012848115668" forced="1"

2016:12:01-17:55:42 wsc-sop01 red_server[28535]: A35012848115668 is disconnected.

2016:12:01-17:55:46 wsc-sop01 red_server[29396]: SELF: New connection from 185.45.240.39 with ID A35012848115668 (cipher AES256-GCM-SHA384), rev1<30>Dec 1 17:55:46 red_server[29396]: A35012848115668: connected OK, pushing config

2016:12:01-17:55:51 wsc-sop01 red_server[29396]: A35012848115668: command 'UMTS_STATUS value=OK'

2016:12:01-17:55:51 wsc-sop01 red_server[29396]: A35012848115668: command 'PING 0 uplink=WAN'

2016:12:01-17:55:51 wsc-sop01 red_server[29396]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A35012848115668" forced="0"

2016:12:01-17:55:51 wsc-sop01 red_server[29396]: A35012848115668: PING remote_tx=0 local_rx=0 diff=0

2016:12:01-17:55:51 wsc-sop01 red_server[29396]: A35012848115668: PONG local_tx=0

2016:12:01-17:56:07 wsc-sop01 red_server[29396]: A35012848115668: command 'PING 0 uplink=WAN'

2016:12:01-17:56:07 wsc-sop01 red_server[29396]: A35012848115668: PING remote_tx=0 local_rx=0 diff=0

2016:12:01-17:56:07 wsc-sop01 red_server[29396]: A35012848115668: PONG local_tx=0

2016:12:01-17:56:21 wsc-sop01 red_server[29396]: A35012848115668: command 'PING 0 uplink=WAN'

2016:12:01-17:56:21 wsc-sop01 red_server[29396]: A35012848115668: PING remote_tx=0 local_rx=0 diff=0

2016:12:01-17:56:21 wsc-sop01 red_server[29396]: A35012848115668: PONG local_tx=0

2016:12:01-17:56:23 wsc-sop01 red_server[29396]: A35012848115668: command 'SYSSTATE unstable peer using stabilization timeout 30'

2016:12:01-17:56:23 wsc-sop01 red_server[29396]: A35012848115668: command 'SYSSTATE last stable peer status:'

2016:12:01-17:56:23 wsc-sop01 red_server[29396]: A35012848115668: command 'SYSSTATE 0 weight: 0 remote: 185.45.240.40 (dev 3), RX: miss 0/0, TX: miss 0/2'

Hallo Ramon,

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

DSL : I wonder if this isn't the MTU problem.

MfG - Bob (Bitte auf Deutsch weiterhin.)

Wir haben folgende MTU Einstellungen gewählt.

T-VDSL50 - SG135 MTU1476 VLAN-ID7
T-VDSL100 Frirtzbox MTU???? VLAN-ID 7

T-ADSL16 SG125 Feste-IP - MTU1456
T-ADSL16 SG135 Feste-IP - MTU1456

Vodafone EasyBox MTU????

Welches MTU Parameter im Home Office vorhanden sind wissen wir aktuell nicht. Da wir den router dort nicht im Griff haben. Ist den die MTU in der Aussenstelle auch wichtig. oder nur die an der SG UTM?

Gruss Ramon

My guess is that both would be important, but I don't know how to check the MTU of a RED.  If Sophos Support tells you how to do that, please share it with us here.

If 8 out of 12 work perfectly, then one must wonder if the other 4 have the MTU problem I linked above.  Then again, if the 4 all connect to one WAN interface and the other 8 connect to different interfaces, then maybe only one Home Office WAN connection has the MTU problem.

MfG - Bob (Bitte auf Deutsch weiterhin.)

Wir haben den MTU Wert auf der UTM für das External Interface erst auf 1472 mit TAG 7 gestellt.

Messtool und Rückfrage beim ISP ergab einen Wert von 1456. Dieser Wert ist nun auf der SG eingestellt.

Am RED Interface ist eine Fritzbox vorgeschaltet. Diese lässt keine MTU Einstellungen zu. Wir haben das RED Interface auf der SG ebenfalls auf 1456 gestellt.

Wissen jedoch nicht, ob dies eine Relevanz hat. Kunde startet trotzdem die RED Box neu. Folgende Einträge haben wir aus dem Log mitgeschnitten:

2016:12:07-19:41:53 wsc-sop01 red2ctl[4233]: Missing keepalive from reds1:0, disabling peer 185.45.240.39

2016:12:07-19:41:59 wsc-sop01 red_server[4287]: SELF: (Re-)loading device configurations

2016:12:07-19:42:12 wsc-sop01 red_server[31100]: A35012848115668: No ping for 30 seconds, exiting.

2016:12:07-19:42:12 wsc-sop01 red_server[31100]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A35012848115668" forced="0"

2016:12:07-19:42:12 wsc-sop01 red_server[31100]: A35012848115668 is disconnected.

2016:12:07-20:06:07 wsc-sop01 red_server[3747]: SELF: New connection from 185.45.240.39 with ID A35012848115668 (cipher AES256-GCM-SHA384), rev1<30>Dec  7 20:06:07 red_server[3747]: A35012848115668: connected OK, pushing config

MfG

Zwischen Verbindungsverlust und Wiederverbinden liegen hier doch über 20 min. Da gibt es wohl eher ein generelles Internetproblem am RED-Standort. Glaube kaum, dass die MTU da was mit zu tun hat.

Habt ihr feste IPs am Außenstandort? Was sagt die Ereignisanzeige der Fritzbox in dem Zeitraum?

Mfg, Jan

Ein generelles Verbindungsproblem am Heimstandort ist ausgeschlossen. Wenn der RED-Tunnel abbricht, haben wir immer noch Internet an dem Standort. Zwischen Fritzbox und RED sind weitere Geräte, 2 Telefone, 1 PC und 2 Tablets. Die können ohne Problem weiter surfen und Telefonnieren. Laut Provider haben wir in der Aussenstellen eine Feste IP.

Ein generelles Verbindungsproblem am Heimstandort ist ausgeschlossen. Wenn der RED-Tunnel abbricht, haben wir immer noch Internet an dem Standort. Zwischen Fritzbox und RED sind weitere Geräte, 2 Telefone, 1 PC und 2 Tablets. Die können ohne Problem weiter surfen und Telefonnieren. Laut Provider haben wir in der Aussenstellen eine Feste IP.