Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Subscribers 3 subscribers
  • Views 14214 views
  • Users 0 members are here
Options
Suggested
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.101-12] RED50 restart loop

hasekamin
Our RED50 seems to disconnect after a certain amount of time and starts to reboot in a loop with the log entry "Overflow happened on reds1:0"

Here the complete log with changed ip addresses and ID

2013:06:14-07:43:27 firewall-1 red_server[4924]: SELF: New connection from 111.111.111.111 with ID A00000000000000 (cipher RC4-SHA), rev1
2013:06:14-07:43:27 firewall-1 red_server[4924]: SELF: Starting REDv2 protocol
2013:06:14-07:43:27 firewall-1 red_server[4924]: A00000000000000: connected OK, pushing config
2013:06:14-07:43:27 firewall-1 red_server[4924]: A00000000000000: Sending PEERS+222.222.222.222
2013:06:14-07:43:30 firewall-1 red_server[4924]: A00000000000000: command 'UMTS_STATUS value=OK'
2013:06:14-07:43:30 firewall-1 red_server[4924]: A00000000000000: command 'PING 0 uplink=WAN'
2013:06:14-07:43:30 firewall-1 red_server[4924]: A00000000000000: PING remote_tx=0 local_rx=0 diff=0
2013:06:14-07:43:30 firewall-1 red_server[4924]: A00000000000000: PONG local_tx=0
2013:06:14-07:43:41 firewall-1 red2ctl[25080]: Overflow happened on reds1:0
2013:06:14-07:43:41 firewall-1 red2ctl[25080]: Missing keepalive from reds1:0, disabling peer 111.111.111.111
2013:06:14-07:43:46 firewall-1 red_server[4924]: A00000000000000: command 'PING 0 uplink=WAN'
2013:06:14-07:43:46 firewall-1 red_server[4924]: A00000000000000: PING remote_tx=0 local_rx=0 diff=0
2013:06:14-07:43:46 firewall-1 red_server[4924]: A00000000000000: PONG local_tx=0
2013:06:14-07:43:51 firewall-1 red2ctl[25080]: Received keepalive from reds1:0, enabling peer 111.111.111.111
2013:06:14-07:44:01 firewall-1 red_server[4924]: A00000000000000: command 'PING 0 uplink=WAN'
2013:06:14-07:44:01 firewall-1 red_server[4924]: A00000000000000: PING remote_tx=0 local_rx=0 diff=0
2013:06:14-07:44:01 firewall-1 red_server[4924]: A00000000000000: PONG local_tx=0
2013:06:14-07:44:05 firewall-1 red_server[5212]: SELF: New connection from 111.111.111.111 with ID A00000000000000 (cipher RC4-SHA), rev1
2013:06:14-07:44:05 firewall-1 red_server[5212]: A00000000000000: already connected, releasing old connection
2013:06:14-07:44:31 firewall-1 red2ctl[25080]: Missing keepalive from reds1:0, disabling peer 111.111.111.111


I think this issue was already reported under Mantis ID #25375 in the beta forum but it still not seems to be fixed in the current release 9.101-12 which we are using. 

Are there any updates on this or maybe workarounds to temporary fix the issue?

The only workaround I found is powering off/on the RED50 manually. 

Since this does not work on remote site I have to wait until this bug is fixed before I can use the red50 in a live system.


This thread was automatically locked due to age.
  • 0
    Hi hasekamin,
    your problem is triggered in Mantis#26460: RED50 frequently reconnecting, red2ctl reports "Overflow happened on redsX" and we are working on it. A workarround would be to use 2nd uplink for "Failover" instead of "Balancing".
    Greetings,
    Andreas
  • 0
    Hi Andreas,
    we tried to use our second uplink but we only have one ip address on the remote site and with the same source ip on the second uplink it results in the same loop as mentioned before.

    So I think we just have to use another vpn router until its fixed.
  • 0
    Hi hasekamin,
    let me  short conclude; you are using one uplink with a static IP. Do you use 2 UTM hostnames?
    Greetings,
    Andreas
  • 0
    Hello Andreas,

    we used one hostname with one static link so just one WAN uplink cable.
    While experiencing the loop problem I entered a second UTM Hostname with another IP but targeting the same UTM 220 Host. Additionally  I configured a second uplink with the same IP informations in failover mode, in the hope that it would break the loop and result in a successful vpn tunnel. After all these settings made i put in the second wan cable deactivated/activated the RED 50 in UTM RED setup while watching the RED live log. The RED50 restarted after getting the new config but the loop continued to show up in log an no vpn tunnel could be established.
  • 0
    Please show a picture of the Edit of your RED configuration with the 'Advanced' section expanded.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Hello Bob,

    here some screenshots of our first and second config including second wan failover




    The current situation is that not even unpowering the device always helps. Most of the time the red50 is just frequently reconnecting and rebooting without creating a vpn tunnel.

    If it manages to build up the tunnel its fine until the next day. When I arrive at work in the morning its frequently reconnecting again. 
    I think its due to the DSL forced reconnect all 24 hours in our test environment
  • 0
    Hi hasekamin,
    your problem is indeed related to your static ip in combination with the 24h reconnect. We know what's wrong and are working on it. For now there is unfortunately no workarround I could tell you if you rely on a static IP.
    I keep you posted.
    Greetings,
    Andreas
  • 0 in reply to treskaan
    Hi hasekamin,
    your problem is indeed related to your static ip in combination with the 24h reconnect. We know what's wrong and are working on it. For now there is unfortunately no workarround I could tell you if you rely on a static IP.
    I keep you posted.
    Greetings,
    Andreas


    I´m having the same problem in firmware version: 9.105-9.
    Is this not fixed yet ?

    The temporary solution is not use static IP ?

    Thanks !
  • 0 in reply to caprocha
    Hi hasekamin,
    your problem is indeed related to your static ip in combination with the 24h reconnect. We know what's wrong and are working on it. For now there is unfortunately no workarround I could tell you if you rely on a static IP.
    I keep you posted.
    Greetings,
    Andreas


    I´m having the same problem in firmware version: 9.105-9.
    Is this not fixed yet ?

    The temporary solution is not use static IP ?

    Thanks !


    Any news on this subject ????
  • 0
    Someone from sophos looking at this forum ? [:(]
Unfiltered HTML