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

Laut telefonischer Auskunft des SOPHOS-Supports soll das Problem mit 9.4 gefixt sein. Wir haben das aber noch nicht getestet, wir warten auf das reguläre Erscheinen der 9.4 im Up2Date.

Jan

Hallo Jan,

danke für die Antwort - wir haben uns ebenfalls entschlossen, auf das reguläre Up2Date Package zu warten und haben die Kollegen instruiert, morgens die RED neu zu starten.

Viele Grüße,

Patrick

Tritt das Problem bei dir bei jedem DSL-Reconnect auf? Bei uns kam es nur hoch, wenn es Probleme mit dem DSL gab, also die Synchronisation weggeflogen ist und dadurch die Verbindung länger unterbrochen war.

Die reguläre Umgehung der Zwangstrennung durch kurzes Trennen der Verbindung (einer der Gründe für uns, Fritzboxen einzusetzen), dauert ja nur wenige Sekunden, das bekommt das RED bzw. die UTM gar nicht mit. Das Ping/Pong-Intervall auf dem WAN-Interface liegt ja bei 30 Sekunden. Da wir zwar dynamisch vergebene, aber feste IPs an den DSL haben, wird der Tunnel nicht unterbrochen.

Jan

Hi,

das kann ich noch nicht genau beurteilen - wir haben die RED15 erst gestern nachmittag deployed, heute morgen trat das Problem aber schon direkt auf (T-Com DeutschlandLAN IP Start ohne feste IP). 

Da das UTM-RED Log nichts hergibt, kann ich auch nicht genau sagen, ob das Problem genau zu dem Zeitpunkt des DSL-Reconnects auftrat, gehe aber davon aus.

Ein Wechsel der externen IP erzwingt ja einen Neuaufbau des Tunnels, und dabei verhaken sich UTM und RED15.
Nunja, hoffen wir mal auf 9.4.

Jan

Ja, wir hatten uns das RED15 extra deswegen zugelegt (Plug'n'play) ohne langwieriges Gefrickel am VPN FritzBox<->Sophos. 

Aktuell hat es sich aber so zugespitzt(Verbindungsabbrüche, Zugriff langsam etc), dass wir das RED komplett rausgenommen haben und wieder das alte VPN aktiviert haben. Ich bin da etwas enttäuscht... Aber ja - 9.4 wird es hoffentlich richten ;-)

Schon jemand mit 9.4 getestet? 9.401 ist ja jetzt im Up2Date, bei uns allerdings noch nicht aufgeschlagen.

Jan

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

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.

OK, one other Layer-2 possibility: sometimes the UTM and the ISP's device have difficulty with auto-negotiation.  If you think that might be the problem, follow #7.7 in Rulz.

MfG - Bob (Bitte auf Deutsch weiterhin.)