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

2nd ISP brings REDs down

Chris King3

Hello,

I have an odd problem I hope you can advise me on. 

I have a single SG310.  I have the primary ISP on Eth1, the Internet network on Eth0 and a secondary ISP on Eth5.   We have 11 RED devices (a mix of 10's, 15's and 50's).   The ISP on Eth1 has a static public address.  The ISP on Eth5 has a dynamic IP (ethernet).  I have setup Unlink Balancing and assigned both as Active and weighted ISP 1 as 100 and ISP2 as 10.  I don't think I've done anything else relating to this secondary ISP setup.

Whenever I turn the interface on for that secondary ISP, it works correctly.  I can create firewall rules to route an individual client out that secondary ISP and it works correctly.  However, over the course of 30 -60 minutes, my RED's start going offline.   Generally starts with the same 2 REDs going down within 30 minutes but within 60-120 minutes, they all will eventually go down. 

I can't for the life of me figure out what is causing this.  I use the actual primary ISP IP address for the UTM hostname.   

Do you all have any thoughts on what might be causing this?  I am happy to give you any other configuration information or try anything you suggest.

Thank you

Chris



This thread was automatically locked due to age.
  • 0

    Hi Chris and welcome to the UTM Community!

    Since you're in the US, you can open a Support case yourself at support.sophos.com.

    "I use the actual primary ISP IP address for the UTM hostname." - Please show a picture of that.

    Also, pics of the weighting and of the Edits of any related Multipath rules.  Are you using 'Automatic monitoring'?

    Also, a pic of the Edit of the Server definition of one of the 2 REDs that first disconnect.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thank you for the welcome Bob and for your time.  I will open a case if you guys here think that is best.  Here is the info you requested.  Again, thank you for your time.  I have erased a few octets of the addressing for security but there should be enough there to follow what I've done.  If not, please let me know.

    Primary ISP IP for RED UTM hostname:

    IP Address of External interface:

    Uplink Weighting:

    Yes Automatic Monitoring

    Multipath rules.  I created some of these to test traffic going to the secondary ISP (with dynamic addressing).  Rule 4 is our primary ISP.

    I think the RED server definition is what I posted in the 1st pic, correct?  If not, please let me know and I'll get that. 

    Thank  you again for your time.

    Chris

  • 0 in reply to Chris King3

    In your Multipath rules, Chris, which ones have 'Skip rule on interface error' selected?  I'm not sure that the 100-10 weighting is desirable/necessary given your Multipath rules.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hey Bob,

    So all 4 multipath rules have "skip rule on interface error" checked.   Is that a problem or should be different?  The multipath rules you see that I created are mostly to test traffic outbound through the backup (Suddenlink) interface.   I think, honestly, we just want to use that secondary ISP as failover and maybe to handle our "guest" network traffic.   Your thoughts on the rules and weighting are certainly welcome.

    Just confused why enabling that secondary ISP interface brings all my REDs down.

    Thank you

    Chris

  • 0 in reply to Chris King3

    Since all traffic is bound to an interface, there's no reason to set weighting at anything other than 100/100.  Weighting is important when you have no Multipath rules or choose one of the other persistence settings in one or more.

    I would suspect the ISP's service on the External interface.  What happens if you un-check 'Skip rule on interface error' for rule 4?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thanks Bob, I tried un-checking "Skip rule on interface error" on the Mutlpath rule for the External Interface and setting the weighting to 100/100.  Within a few minutes, most all of my REDs were down when I enabled the 2nd ISP Interface.

    Chris

  • 0 in reply to Chris King3

    Chris, I can't think of anything in the UTM that would cause this.  I bet Sophos Support says it's your ISP or the ISP's equipment, but I'd be happy to be proven wrong!

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    OK, thank you.   So just to be sure i understand how this is working.   With my single primary ISP, the REDs work correctly.   When I bring up my secondary ISP, the REDs stop working.  Is this telling me that the REDs switch over to use that secondary ISP for their connectivity?  Would there be a way to force them to continue to use the primary ISP when the secondary one is on (Eth enabled)?

    Do appreciate your time and thoughts.  I would also kinda suspect the ISP since it is cable-based and there are odd things that occur with Cable-based ISPs (port blocking, etc), even though they say they don't block.  However, I have another client that uses Comcast as their sole, primary ISP and we have several REDs and they all work fine.   Just so odd......

    Chris

Unfiltered HTML