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

Disconnect Loop RED 15 -

Hi,

ich have a very strange problem with the new RED 15.

Setting:

UTM 9.350-12 at the main office

RED 15 with static IP behind an LTE-router at the remote location

After the first configuration everything works fine. But after some hours the RED diconnect and reconnected every minute.

After a reboot of the UTM (or if i deactivate the RED for some hours)  the connection is stable for some hours.

Here are some lines out of the RED log:

2015:11:10-16:42:48 che-igw01 red_server[20657]: A350124B7XXXXXX: command 'PING 0 uplink=WAN'
2015:11:10-16:42:48 che-igw01 red_server[20657]: A350124B7XXXXXX: PING remote_tx=0 local_rx=0 diff=0
2015:11:10-16:42:48 che-igw01 red_server[20657]: A350124B7XXXXXX:: PONG local_tx=0
2015:11:10-16:42:52 che-igw01 red_server[20939]: SELF: New connection from 2.200.175.176 with ID A350124B7XXXXXX: (cipher AES256-GCM-SHA384), rev1
2015:11:10-16:42:52 che-igw01 red_server[20939]: A350124B7XXXXXX:: already connected, releasing old connection.
2015:11:10-16:42:52 che-igw01 red_server[20657]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A350124B7XXXXXX" forced="1"
2015:11:10-16:42:52 che-igw01 red_server[20657]: A350124B7XXXXXX: is disconnected.
2015:11:10-16:42:52 che-igw01 red2ctl[4266]: Overflow happened on reds2:0
2015:11:10-16:42:52 che-igw01 red2ctl[4266]: Missing keepalive from reds2:0, disabling peer 2.200.XXX.XXX
2015:11:10-16:42:52 che-igw01 red_server[4255]: SELF: (Re-)loading device configurations
2015:11:10-16:42:53 che-igw01 red_server[20939]: A350124B7XXXXXX:: connected OK, pushing config
2015:11:10-16:42:53 che-igw01 red_server[20939]: A350124B7XXXXXX:: Sending PEERS+178.15.XXX.XXX
2015:11:10-16:42:57 che-igw01 red_server[20939]: A350124B7XXXXXX:: command 'UMTS_STATUS value=OK'
2015:11:10-16:42:57 che-igw01 red_server[20939]: A350124B7XXXXXX:: command 'PING 0 uplink=WAN'
2015:11:10-16:42:57 che-igw01 red_server[20939]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A350124B7XXXXXX:" forced="0"
2015:11:10-16:42:57 che-igw01 red_server[20939]: A350124B7XXXXXX:: PING remote_tx=0 local_rx=0 diff=0
2015:11:10-16:42:57 che-igw01 red_server[20939]: A350124B7XXXXXX:: PONG local_tx=0
2015:11:10-16:42:58 che-igw01 red_server[4255]: SELF: (Re-)loading device configurations
2015:11:10-16:42:59 che-igw01 red2ctl[4266]: Missing keepalive from reds2:0, disabling peer 2.200.XXX.XXX
2015:11:10-16:43:02 che-igw01 red2ctl[4266]: Received keepalive from reds2:0, enabling peer 2.200.XXX.XXX
2015:11:10-16:43:11 che-igw01 red_server[20939]: A350124B7XXXXXX:: command 'PING 0 uplink=WAN'
2015:11:10-16:43:11 che-igw01 red_server[20939]: A350124B7XXXXXX:: PING remote_tx=0 local_rx=0 diff=0
2015:11:10-16:43:11 che-igw01 red_server[20939]: A350124B7XXXXXX:: PONG local_tx=0
2015:11:10-16:43:26 che-igw01 red_server[20939]: A350124B7XXXXXX:: command 'PING 0 uplink=WAN'
2015:11:10-16:43:26 che-igw01 red_server[20939]: A350124B7XXXXXX:: PING remote_tx=0 local_rx=0 diff=0
2015:11:10-16:43:26 che-igw01 red_server[20939]: A350124B7XXXXXX:: PONG local_tx=0
2015:11:10-16:43:30 che-igw01 red_server[21136]: SELF: New connection from 2.200.XXX.XXX with ID A350124B7XXXXXX: (cipher AES256-GCM-SHA384), rev1
2015:11:10-16:43:30 che-igw01 red_server[21136]: A350124B7XXXXXX:: already connected, releasing old connection.
2015:11:10-16:43:30 che-igw01 red_server[20939]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A350124B7XXXXXX:" forced="1"
2015:11:10-16:43:31 che-igw01 red_server[20939]: A350124B7XXXXXX: is disconnected.
2015:11:10-16:43:31 che-igw01 red_server[4255]: SELF: (Re-)loading device configurations
2015:11:10-16:43:32 che-igw01 red2ctl[4266]: Overflow happened on reds2:0
2015:11:10-16:43:32 che-igw01 red2ctl[4266]: Missing keepalive from reds2:0, disabling peer 2.200.XXX.XXX
2015:11:10-16:43:32 che-igw01 red_server[21136]: A350124B7XXXXXX:: connected OK, pushing config
2015:11:10-16:43:32 che-igw01 red_server[21136]: A350124B7XXXXXX:: Sending PEERS+178.15.XXX.XXX
2015:11:10-16:43:35 che-igw01 red2ctl[4266]: Overflow happened on reds2:0
2015:11:10-16:43:35 che-igw01 red2ctl[4266]: Missing keepalive from reds2:0, disabling peer 2.200.XXX.XXX
2015:11:10-16:43:35 che-igw01 red_server[21136]: A350124B7XXXXXX:: command 'UMTS_STATUS value=OK'
2015:11:10-16:43:35 che-igw01 red_server[21136]: A350124B7XXXXXX:: command 'PING 0 uplink=WAN'
2015:11:10-16:43:35 che-igw01 red_server[21136]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A350124B7XXXXXX:" forced="0"
2015:11:10-16:43:35 che-igw01 red_server[21136]: A350124B7XXXXXX:: PING remote_tx=0 local_rx=0 diff=0
2015:11:10-16:43:35 che-igw01 red_server[21136]: A350124B7XXXXXX:: PONG local_tx=0
2015:11:10-16:43:41 che-igw01 red2ctl[4266]: Received keepalive from reds2:0, enabling peer 2.200.XXX.XX
Other RED devices (RED10) at the same UTM works fine.
Any ideas?



This thread was automatically locked due to age.
Parents
  • Hi,

    we have the same Problem here at one of our customers (SG125 with 22 RED 15. That sounds like a lot of REDs but the traffic is farily low. Only a few MB around Midnight for POS-Station informations). 

    REDs reconnecting ( in under 30 seconds so the FireWall didn't notice the disconnect ) 

    Perheps anyone was able to look at the RED LEDs. Here it was the case that the Tunnel LED remains flashing even though the RED appears online on the FireWall.

    But we managed to find a workaround:

     From a Internal Server sending endless Ping pakets to a POS-Station behind a RED. 

    e.g. ping 127.0.0.1 -l 1024 -t

    I decidet to increase the size of the ping to make sure there is enough traffic on the RED Tunnel.

    The effect is that the RED Tunnel stays online and the CPU workload has gone down to normal. 

    Of course this is only a temporarly fix. I am in contact with the Support to fix this.

    Best regards from Germany

    Dennis

Reply
  • Hi,

    we have the same Problem here at one of our customers (SG125 with 22 RED 15. That sounds like a lot of REDs but the traffic is farily low. Only a few MB around Midnight for POS-Station informations). 

    REDs reconnecting ( in under 30 seconds so the FireWall didn't notice the disconnect ) 

    Perheps anyone was able to look at the RED LEDs. Here it was the case that the Tunnel LED remains flashing even though the RED appears online on the FireWall.

    But we managed to find a workaround:

     From a Internal Server sending endless Ping pakets to a POS-Station behind a RED. 

    e.g. ping 127.0.0.1 -l 1024 -t

    I decidet to increase the size of the ping to make sure there is enough traffic on the RED Tunnel.

    The effect is that the RED Tunnel stays online and the CPU workload has gone down to normal. 

    Of course this is only a temporarly fix. I am in contact with the Support to fix this.

    Best regards from Germany

    Dennis

Children
  • Hi DRSmokey,

    That is a very interesting workaround! I will try this for one of our clients on a RED50.

    Can I ask when you look at the RED live logs does it also always show a ping and pong response of 0 for the RED v2 protocol? :

    2015:12:07-12:51:25 ASTARO red_server[19645]: A3400753F7xxxxx: PING remote_tx=0 local_rx=0 diff=0

    2015:12:07-12:51:25 ASTARO red_server[19645]: A3400753F7xxxxx: PONG local_tx=0

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

    Kevin

  • Any news from support,
    Just had a customer today with 30 RED 15 devices with the same issues. Attaching some RED 10 fixes the problems :-)

    -----

    Best regards
    Martin

    Sophos XGS 2100 @ Home | Sophos v20 Technician

  • Hi Kevin_Miller,

    jep exactly the same.
  • Hi twister5800,

    Unfortunately not :(

    The support seems to have problems to understand the problem. Unfortunately I get no feedback at all. And when I am asking about the status, the only answer was that my SG125 is too small and our customer should buy a bigger one. But I think my workaround shows thats not the case.

    That adding a RED10 device solves the Problem is interresting. Will try that here as well.