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

RED15 looses connection, reboot solves the problem

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



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

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

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

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

Children
No Data