[solved] RED15W does not update it's firmware after update the UTM to 9.601-5

One of our UTMs has a single RED15W connected to give one of our road warriors access, till today this worked fine.

A few hours ago, I updated this UTMs to 9.601-5, the update itself did it's job, after reboot the UTM was up and running.

Unfortunately now the RED15W can't establish it's VPN to the UTM. I attached some lines of the UTMs RED log file.

Seems the UTM recognizes the REDs old firmware, but there is no update for the RED or at least it doesn't work.

The RED is trying to reconnect every 2minutes, without success, it's always the same error, "Disconnecting: Firmware update required. Trying provisioning service ..."

 

Any hints how to fix this (besides doing a new, clean install with an older UTM firmware)?

 

---------------

2019:02:19-13:46:06 mail red_server[8034]: SELF: Cannot do SSL handshake on socket accept from '<IP>': SSL connect accept failed because of handshake problems
2019:02:19-13:46:06 mail red_server[8035]: SELF: Cannot do SSL handshake on socket accept from '<IP>': SSL connect accept failed because of handshake problems SSL wants a read first
2019:02:19-13:46:09 mail red_server[8043]: SELF: New connection from <IP> with ID A360203FDXXXXXX (cipher AES256-GCM-SHA384), rev1
2019:02:19-13:46:09 mail red_server[8043]: A360203FDXXXXXX: connected OK, pushing config
2019:02:19-13:46:10 mail red_server[8043]: A360203FDXXXXXX: command '{"data":{"version":"0"},"type":"INIT_CONNECTION"}'
2019:02:19-13:46:10 mail red_server[8043]: A360203FDXXXXXX: Initializing connection running protocol version 0
2019:02:19-13:46:10 mail red_server[8043]: A360203FDXXXXXX: Sending json message {"data":{},"type":"WELCOME"}
2019:02:19-13:46:11 mail red_server[8043]: A360203FDXXXXXX: command '{"data":{},"type":"CONFIG_REQ"}'
2019:02:19-13:46:11 mail red_server[8043]: A360203FDXXXXXX: Sending json message {"data":{"pin":"","fullbr_dns":"","split_networks":"1.2.3.4","lan2_vids":"","lan4_vids":"","local_networks":"","tunnel_id":1,"manual2_netmask":24,"asg_cert":"[removed]","manual_address":"0.0.0.0","bridge_proto":"none","unlock_code":"tkc60a7x","password":"","manual2_defgw":"0.0.0.0","prev_unlock_code":"","manual_netmask":24,"lan3_vids":"","version_r2":"2005R2","mac_filter_type":"none","mac":"00:28:4e:14:XX:XX","dial_string":"*99#","manual2_address":"0.0.0.0","version_ng_red50":"1-330-f4c55ab8-0000000","manual_dns":"0.0.0.0","lan1_mode":"unused","username":"","activate_modem":0,"tunnel_compression_algorithm":"lzo","version_red50":"1-330-f4c55ab8-0000000","fullbr_domains":"","htp_server":"mail.hoehne.org","uplink_balancing":"failover","asg_key":"[removed]","type":"red15w","deployment_mode":"online","uplink2_mode":"dhcp","version_red15":"1-330-f4c55ab8-655eb7e","manual2_dns":"0...L1505
2019:02:19-13:46:12 mail red_server[8043]: A360203FDXXXXXX: command '{"data":{"message":"Firmware update required. Trying provisioning service ..."},"type":"DISCONNECT"}'
2019:02:19-13:46:12 mail red_server[8043]: A360203FDXXXXXX: Disconnecting: Firmware update required. Trying provisioning service ...
2019:02:19-13:46:12 mail red_server[8043]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A360203FDXXXXXX" forced="1"
2019:02:19-13:46:12 mail red_server[8043]: A360203FDXXXXXX is disconnected.

---------------

  • Had the same issue this morning.

    I have deleted and recreated the RED Device. Now the RED came up again.

  • In reply to JoWisni:

    Thx a lot, this workaround fixes the problem :)

    No idea, why Sophos q&a did not gave a hint in the release notes...

  • Hi all,

    just encountered the same problem after updating from 9.600 to 9.601.

    Since I had disabled compression in 9.600 to make the RED-tunnel work, I first tried to enable compression again.

    This triggered a redeployment of the config which in turn triggered a firmwareupdate.

    After the firmwareupdate, the RED tunnel came up.

    So, no need to delete the config. Just modifying it should do the trick.

     

    BR,

    Michael