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

RED 10 static IP deployment headaches.

simulant
We've been rolling out RED 10 with static IP configs to our branch locations over the past year and I've now got about 20 REDS and 3 hardware revisions in the field with no clue as to what  the differences are other than the newer ones seem to behave differently during deployment than the old ones

I'm more frequently running into failed deployments.  

  I've had several REDs fail to connect on their initial deployment for no apparent reason only to work days later on subsequent attempts

  Today I had a new RED connect once from our branch location, then fail to reconnect.  I determined that I had inadvertently misconfigured it's default gateway so I had the branch location hook it up on a dhcp network w/internet access to reconfigure it, however it never reconnected using dhcp fallback.  

DHCP fallback has been hit or miss lately and it's getting frustrating.  I feel like I'm working blind.   The REDS are very reliable once you get them working but nearly impossible to troubleshoot when something goes wrong.  Granted I have yet to encounter a truly broken RED 10 but their behavior has changed and it seems every new batch behaves differently.

Since Sophos acquired Astaro I've found it difficult to locate documentation and change logs.   At the very least I'd like to be kept aware of behavioral changes of the RED 10s and Software.   Nothing I've found so far adequately explains  how the REDS have changed.     Can anyone point me in the right direction?     

TIA,


This thread was automatically locked due to age.
Parents
  • 0
    Did you try flashing the misbehaving units?  I've had to flash a new one before.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0
    Did you try flashing the misbehaving units?  I've had to flash a new one before.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • 0 in reply to BAlfson
    Simulant, try this to reset your errant RED appliance:

    There is one way to completely blow the configuration from the RED and force it to go out the provisioning server to pull a new config, as just using the unlock code may not work since the RED always goes back to the its previously connected ASG and if it finds that, it will be happy and not go out to find a new config.

    The way I have it setup here is I just created a new interface on a spare NIC on our Astaro. Then create 2 PF rules:

    1.) NETWORK -- ANY -- RED.ASTARO.COM -- AlLOW
    2.) NETWORK -- ANY -- ANY -- DROP

    You could do it by the IP the RED gets as well but we just do so many here I found it easier to just create a new network for our warehouse.

    Then just plug the REDs WAN port into that interface and let it sit, watch the PF log and watch it drop a few times then it will be back to its factory state and will go out to the provisioning server next time.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

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

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Unfiltered HTML