RED15 looses connection, reboot solves the problem

Question

On a remote location I have a RED15 with a slow (but steady) connection. I changed the RED to a faster Fiber connection and changed the IP to static. Connection worked for a day, then went down. To get production up I switched back to the slow connection and bought an extra RED15 to start testing with Fiber. 
 Again everything OK for some time, but then again a disconnect. Rebooting RED solves the problem. Below my Log messages with a working connection, loosing connection and a reboot. 
 Can someone tell me how to troubleshoot this problem, push me in the right direction? 
 2018:01:16-14:16:31 fw red_server[16964]: A3501ED575A9473: command 'PING 0 uplink=WAN' 
 2018:01:16-14:16:31 fw red_server[16964]: A3501ED575A9473: PING remote_tx=0 local_rx=0 diff=0 
 2018:01:16-14:16:31 fw red_server[16964]: A3501ED575A9473: PONG local_tx=0 
 2018:01:16-14:16:46 fw red2ctl[4600]: Missing keepalive from reds3:0, disabling peer 46.145.209.106 
 2018:01:16-14:16:49 fw red_server[4590]: SELF: (Re-)loading device configurations 
 2018:01:16-14:17:02 fw red_server[16964]: A3501ED575A9473: No ping for 30 seconds, exiting. 
 2018:01:16-14:17:02 fw red_server[16964]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A3501ED575A9473" forced="0" 
 2018:01:16-14:17:02 fw red_server[16964]: A3501ED575A9473 is disconnected. 
 2018:01:16-14:24:04 fw red_server[22535]: Self: SSL connect accept failed because of handshake problems2018:01:16-14:24:04 fw red_server[22536]: Self: SSL accept attempt failed with unknown error error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol2018:01:16-14:24:04 fw red_server[22537]: Self: SSL accept attempt failed with unknown error error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol 
 
 REBOOT RED: 
 2018:01:18-09:30:51 fw red_server[22187]: SELF: New connection from 46.145.209.106 with ID A3501ED575A9473 (cipher AES256-GCM-SHA384), rev1 
 2018:01:18-09:30:51 fw red_server[22187]: A3501ED575A9473: connected OK, pushing config 
 2018:01:18-09:30:55 fw red_server[22187]: A3501ED575A9473: command 'UMTS_STATUS value=OK' 
 2018:01:18-09:30:55 fw red_server[22187]: A3501ED575A9473: command 'PING 0 uplink=WAN' 
 2018:01:18-09:30:55 fw red_server[22187]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A3501ED575A9473" forced="0" 
 2018:01:18-09:30:55 fw red_server[22187]: A3501ED575A9473: PING remote_tx=0 local_rx=0 diff=0 
 2018:01:18-09:30:55 fw red_server[22187]: A3501ED575A9473: PONG local_tx=0 
 2018:01:18-09:30:56 fw red_server[4590]: SELF: (Re-)loading device configurations 
 2018:01:18-09:30:57 fw red2ctl[4600]: Overflow happened on reds3:0 
 2018:01:18-09:30:57 fw red2ctl[4600]: Missing keepalive from reds3:0, disabling peer 46.145.209.106 
 2018:01:18-09:31:00 fw red2ctl[4600]: Received keepalive from reds3:0, enabling peer 46.145.209.106 
 2018:01:18-09:31:11 fw red_server[22187]: A3501ED575A9473: command 'PING 0 uplink=WAN' 
 2018:01:18-09:31:11 fw red_server[22187]: A3501ED575A9473: PING remote_tx=0 local_rx=0 diff=0 
 2018:01:18-09:31:11 fw red_server[22187]: A3501ED575A9473: PONG local_tx=0

sachingurung · Answer

Hi Richard, 
 UTM will maintain the RED tunnel, accounting the PING PONG messages between the UTM and RED. 
 2018:01:16-14:16:46 fw red2ctl[4600]: Missing keepalive from reds3:0, disabling peer 46.145.209.106 
 The above log line tells us that there was a missing keepalive(ping-pong) which lead towards the disconnection of the tunnel. There could be possibilities such as: 
 
 RED not sending the keepalives. 
 UTM not receiving the keepalives. 
 UTM not sending the keepalives. 
 UTM sending the keepalives but the messages are lost before reaching the RED. 
 
 You need to do a packetcapture on both end to investigate who fails to forward the keepalives which will tell you what causes the disconnection. 
 Hope that helps.