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

9.308 Killed RED !!

Hi Guys,

So we finally took the plunge on the 9.3 firmware thinking Sophos would've gotten their act together by now with the firmwares by installing 9.308.. BIG MISTAKE [:O]

Its killed our RED connection and it keeps getting disconnected after every 30 secs. Please HELP !

2015:02:27-19:10:33 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: connected OK, pushing config

2015:02:27-19:10:37 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: command 'UMTS_STATUS value=OK'
2015:02:27-19:10:37 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: command 'PING 1 uplink=WAN'
2015:02:27-19:10:37 DVicSophosUTM01-2 red_server[28872]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A3200C53DAE6057" forced="0"
2015:02:27-19:10:38 DVicSophosUTM01-2 red_server[6990]: SELF: (Re-)loading device configurations
2015:02:27-19:10:38 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: PING remote_tx=1 local_rx=2 diff=-1
2015:02:27-19:10:38 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: PONG local_tx=3
2015:02:27-19:10:53 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: command 'PING 22 uplink=WAN'
2015:02:27-19:10:53 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: PING remote_tx=22 local_rx=22 diff=0
2015:02:27-19:10:53 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: PONG local_tx=22
2015:02:27-19:11:09 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: command 'PING 38 uplink=WAN'
2015:02:27-19:11:09 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: PING remote_tx=38 local_rx=38 diff=0
2015:02:27-19:11:09 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057: PONG local_tx=40
2015:02:27-19:11:37 DVicSophosUTM01-2 red_server[29248]: SELF: New connection from 101.172.213.63 with ID A3200C53DAE6057 (cipher RC4-SHA), rev1
2015:02:27-19:11:37 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: already connected, releasing old connection.
2015:02:27-19:11:37 DVicSophosUTM01-2 red_server[28872]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A3200C53DAE6057" forced="1"
2015:02:27-19:11:37 DVicSophosUTM01-2 red_server[6990]: SELF: (Re-)loading device configurations
2015:02:27-19:11:37 DVicSophosUTM01-2 red_server[28872]: A3200C53DAE6057 is disconnected.
2015:02:27-19:11:38 DVicSophosUTM01-2 redctl[29363]: key length: 32
2015:02:27-19:11:38 DVicSophosUTM01-2 redctl[29364]: key length: 32
2015:02:27-19:11:38 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: connected OK, pushing config
2015:02:27-19:11:43 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: command 'UMTS_STATUS value=OK'
2015:02:27-19:11:43 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: command 'PING 1 uplink=WAN'
2015:02:27-19:11:43 DVicSophosUTM01-2 red_server[29248]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A3200C53DAE6057" forced="0"
2015:02:27-19:11:43 DVicSophosUTM01-2 red_server[6990]: SELF: (Re-)loading device configurations
2015:02:27-19:11:43 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: PING remote_tx=1 local_rx=1 diff=0
2015:02:27-19:11:43 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: PONG local_tx=2
2015:02:27-19:11:59 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: command 'PING 16 uplink=WAN'
2015:02:27-19:11:59 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: PING remote_tx=16 local_rx=16 diff=0
2015:02:27-19:11:59 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: PONG local_tx=20
2015:02:27-19:12:15 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: command 'PING 33 uplink=WAN'
2015:02:27-19:12:15 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: PING remote_tx=33 local_rx=33 diff=0
2015:02:27-19:12:15 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057: PONG local_tx=39
2015:02:27-19:12:42 DVicSophosUTM01-2 red_server[29590]: SELF: New connection from 101.172.213.63 with ID A3200C53DAE6057 (cipher RC4-SHA), rev1
2015:02:27-19:12:42 DVicSophosUTM01-2 red_server[29590]: A3200C53DAE6057: already connected, releasing old connection.
2015:02:27-19:12:42 DVicSophosUTM01-2 red_server[29248]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A3200C53DAE6057" forced="1"
2015:02:27-19:12:42 DVicSophosUTM01-2 red_server[6990]: SELF: (Re-)loading device configurations
2015:02:27-19:12:42 DVicSophosUTM01-2 red_server[29248]: A3200C53DAE6057 is disconnected.
2015:02:27-19:12:43 DVicSophosUTM01-2 redctl[29706]: key length: 32
2015:02:27-19:12:43 DVicSophosUTM01-2 redctl[29707]: key length: 32
2015:02:27-19:12:43 DVicSophosUTM01-2 red_server[29590]: A3200C53DAE6057: connected OK, pushing config
2015:02:27-19:12:48 DVicSophosUTM01-2 red_server[29590]: A3200C53DAE6057: command 'UMTS_STATUS value=OK'
2015:02:27-19:12:48 DVicSophosUTM01-2 red_server[29590]: A3200C53DAE6057: command 'PING 1 uplink=WAN'
2015:02:27-19:12:48 DVicSophosUTM01-2 red_server[29590]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A3200C53DAE6057" forced="0"
2015:02:27-19:12:48 DVicSophosUTM01-2 red_server[6990]: SELF: (Re-)loading device configurations
2015:02:27-19:12:48 DVicSophosUTM01-2 red_server[29590]: A3200C53DAE6057: PING remote_tx=1 local_rx=1 diff=0
2015:02:27-19:12:48 DVicSophosUTM01-2 red_server[29590]: A3200C53DAE6057: PONG local_tx=2


This thread was automatically locked due to age.
  • We have exactly the same after an update to 9.308-16. Everything behind the RED is DEAD.
    We came from version 9.307-6 and that works fine!
  • Hi Guys,

    OK, i tried changing the order of interfaces in 'Uplink Monitoring' and it worked.

    However, what i cannot understand is that if this issue is so re-producible (HA System with Uplink monitoring) then how can it escape the Sophos QA people ?!

    Is there even such a thing like Sophos QA or are the paying customers being used as a beta testing platform ? If it were issues with an odd firmware here or there its understandable. However, releasing every firmware with such business stopping bugs is absolutely not acceptable !

    Why does it feel like having Sophos UTM in your network is more dangerous than leaving it wide open to the internet, and updating each firmware is like introducing 'malware' into your production system yourself.
  • workaround with changing the order of the Upload Interfaced worked here too.

    we also had a problem with our IPv6 Tunnelbroker, i feel like this problem is related with the Uploaded Interfaces...
  • New KB article about this:  Advisory: Workaround for RED issues (Bug ID 34563 and 34558) in Sophos UTM v9.308


    Edit:   AAaaahhh, Bob is Like bombing me!!!  ;P
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
  • Does your RED config apply for the workarounds? Do you have case 1 or case 2 from the kb entry?
  • Does your RED config apply for the workarounds? Do you have case 1 or case 2 from the kb entry?

    Yes, I have two uplink interfaces and moved the one on which the REDs connect to the first position, also I entered the IP of this interface in the RED Config. But still I get reconnects every minute or so...

    Edit: What seems to help is to move the second to the standby interfaces, then let the reds connect on move it back. I will keep an eye on it...
  • Hi Guys,

    OK, i tried changing the order of interfaces in 'Uplink Monitoring' and it worked.

    However, what i cannot understand is that if this issue is so re-producible (HA System with Uplink monitoring) then how can it escape the Sophos QA people ?!

    Is there even such a thing like Sophos QA or are the paying customers being used as a beta testing platform ? If it were issues with an odd firmware here or there its understandable. However, releasing every firmware with such business stopping bugs is absolutely not acceptable !

    Why does it feel like having Sophos UTM in your network is more dangerous than leaving it wide open to the internet, and updating each firmware is like introducing 'malware' into your production system yourself.


    It becomes worse and worse after the acquisition of Astaro [:(] QA is crap, as you can see so many show stopper bugs for the last months. What do they think? Let's do the final QA by our stupid customers in their production environments? Glad I didn't install 9.308 on our HA-Cluster, 35 reds down ...
    But hey, let's do some cloud bullshit, and do more feature ****ing, that's what administrators care about ... [:@]

    Administrating:

    • 2x UTM Software HA-Clusters (Active-Passive), Enthusiast Home Lab
    • 1x UTM525 HA-Cluster (Active-Passive), Full Guard, 6x AP15, 2x AP30, 40x RED10, 1x RED50
    • 1x SG230, Full Guard, 6x AP10, 1x AP15
    • 1x UTM220, Full Guard, 16x AP10
    • 1x UTM220, Full Guard
  • Our UTM is behind a Cisco firewall with NAT. The RED was connecting to one of the additional addresses of the WAN interface of the UTM.
    After the update to 9.308-16 the RED was connecting/disconnecting every 30 seconds. When changing the IP address to the 'real' ip address of the WAN interface the problem was solved and the RED came back online again.
  • It becomes worse and worse after the acquisition of Astaro [:(] QA is crap, as you can see so many show stopper bugs for the last months. What do they think? Let's do the final QA by our stupid customers in their production environments? Glad I didn't install 9.308 on our HA-Cluster, 35 reds down ...
    But hey, let's do some cloud bullshit, and do more feature ****ing, that's what administrators care about ... [:@]


    signed! .. (also adding some text here to let me submit the post)

    and on top of that threatening helpful people such as trollvottel ... (https://www.astaro.org/gateway-products/general-discussion/55412-time-say-goodbye.html#post284160)