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

RED down and up, Interface bleibt down

Hallo wir haben diverse REDs an einer redundanten SG430.
Ich pinge an das Interface mit der RED aus dem entfernten LAN und an eine Maschine dahinter.

Der Effekt:
Ich schalte das RED down, beide Pings gehen weg.
Ich schalte das RED wieder up, kein Ping kommt wieder. Erst nachdem ich auf das Interface gehe und dieses einmal kurz down und up schalte laufen die Pings wieder an.

Getestet mit RED 10 und RED 15, die 50er will ich nicht, da hängt zu viel dran.

Ich bin nicht sicher aber ich glaube fest, das war nicht immer so. Konfig-Fehler? Denkfehler? Bug?

Hat jemand Hinweise?

Danke

Uwe



This thread was automatically locked due to age.
Parents
  • 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

  • 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

  • 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.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 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.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • 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.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA