Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 3847 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

Fallback scenarios (again)

Infosystem
Hi there,

I noticed there are similar threads, but they didn't seem to have come to a result.

Shortly after we introduced the RED as a replacement for a site to site VPN using some ancient cisco pix firewalls, our electrician screwed up and cut our optic cable in the main office. As a result, the RED couldn't connect to the ASG anymore. So far so bad, but what made it worse was that when we were out the branch office behind the RED wasn't even able to access the internet anymore. The branch office is set to "Standard Split" and internet traffic does definitely not go through the ASG but directly through the internet. So I don't see why internet access is lost just because the ASG is gone. Is there any way I can configure this?

Second question: We have a spare RED inhouse incase one of the REDs in the branch offices dies. Is there anything in terms of preparations or how tos in case of the situation of a failing RED?

Thanks very much,
Chris


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

    exchanging a defective RED is quite simple (had to do that twice in the last years). It's basically:
    - delete old red device (logical interface and fw rules are not deleted)
    - add new red device (new hardware interface is created)
    - assign new hardware to old logical interface
    - change red's physically and boot up new red
    => done

    I don't know if it is possible to make step 2 in advance.

    Regards
    Manfred


    I  recommend to connect new RED in advance and switch the reds interface in UTM interface config and delete the bricked RED afterwards. This way you definately do not loose any config ;o)
  • 0 in reply to Sascha Paris
    Hi guys,

    Thanks for the procedures, I will note them as our emergency plan.

    Chris
Reply Children
  • 0 in reply to Infosystem
    Hi there,

    We just tried this to test it. We did the following:
    - Added the new RED with the same config as the old one (same public(static) IP, same default gateway, ...)
    - Assigned the new hardware to the existing logical interface
    - Exchanged REDs

    That didn't work. We found out that it's because there is no DHCP server for the WAN, so what we did was we connected the old RED again, switched the physical interface backup, and connected the new RED behind the old RED. So basically we had the original setup again, and the new RED connected the same way the clients on site are connected.

    With that, the new RED was able to connect and get its configuration:

    2013:06:04-18:41:40 isfw-2 red_server[10307]: SELF: New connection from 109.164.245.206 with ID *********XC1C5 (cipher AES256-SHA), rev1
    2013:06:04-18:41:40 isfw-2 red_server[25079]: *********XC1C5: connected OK, pushing config
    2013:06:04-18:41:48 isfw-2 red_server[25079]: *********XC1C5: command 'PING 0'
    2013:06:04-18:41:48 isfw-2 red_server[25079]: *********XC1C5: PING remote_tx=0 local_rx=0 diff=0
    2013:06:04-18:41:48 isfw-2 red_server[25079]: *********XC1C5: PONG local_tx=6

    The new RED even became online on the ASG. So the new RED should have downloaded it's configuration and should now be ready to replace the old RED.

    When we did replace the old RED with the new one though (of course replacing the hardware on the logical interface too), it never got past the "router" light. System went solid, router started to blink, after a while system went red and the RED rebooted again. Even though it must have had the config at that time, and all its settings (IP, gateway, ...) were the same (I double checked that 6 times).

    Any ideas?
Unfiltered HTML