Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 24 replies
  • Answers 1 answer
  • Subscribers 9 subscribers
  • Views 78321 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

RED down and up, Interface bleibt down

UweLeuckert

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
  • +1

    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

  • 0 in reply to JanGross

    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

  • 0 in reply to patrick.schneider

    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

  • 0 in reply to JanGross

    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

Reply Children
  • 0 in reply to patrick.schneider

    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

  • 0 in reply to JanGross

    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.

  • 0 in reply to patrick.schneider

    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

  • 0 in reply to JanGross

    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 ;-)

  • 0 in reply to patrick.schneider

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

    Jan

  • 0 in reply to JanGross

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

    Jan

  • 0 in reply to JanGross

    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

  • 0 in reply to PeterRist

    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

  • 0 in reply to JanGross

    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'

  • 0 in reply to Ramón Schiff

    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
Unfiltered HTML