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

Assistance with multi WAN rule setup

ICT123
UTM Community,

I’ve recently received a SG310 and have begun the initial prep before deploying it to the production network. 

I would appreciate some guidance in regards to the setup of multiple WAN interfaces.

Currently there are 3 ADSL modem/routers, each used for a particular purpose. 
1. General (primary) internet for staff
2. Cloud service (dedicated internet line for department who relies on solid connection for a cloud service)
3. Guest internet access

I will be changing the modem configurations to bridge mode and setting up PPPoE interfaces on the UTM and will recreate the existing port redirection rules on the modems.

I envision having the 3 WAN interfaces listed as “active interfaces”, but would like some assistance in regards to their actual configuration to preserve the existing traffic separation.

I think I need to create 2 new “network” definitions for the “cloud subnet” and the “guest subnet". Because currently there is only the one “internal” network (default).

I believe I should then be using “Multipath Rules” to achieve the traffic separation from the UTM out to either of the 3 modems, correct?

I create a new rule, source “internal” – service “all” – destination “all” – interface persistence “By Interface” – Bind interface “General”.

Second rule, source “cloud network” – service “all” – destination “all” – interface persistence “By Interface” – Bind interface “Cloud”.

Third rule, source “guest network” – service “all” – destination “all” – interface persistence “By Interface” – Bind interface “Guest”.

Is the above correct?

Documentation states that if an interface should fail, it would fall back to “by connection”, so ideally services would continue to work despite temporarily going out of the wrong internet connection. Is that right? What does a "connection" actually refer to?

Also in regards to “masquerading” do I need to setup additional rules for the new network definitions created (cloud and guest)?

At the moment there is only one rule for “Internal (Network)” > “Uplink Interfaces”. 

Should I be adding a rule for “Cloud” > Uplink Interfaces and “Guest” > Interfaces too? Does the interface need to be changed from “uplink interfaces” to a specific interface (e.g. cloud internet/guest internet) ??

Appreciate some guidance on this.

Thankyou


This thread was automatically locked due to age.
  • 0
    Make sure you have ticked "Default Gateway" on all 3 WAN Uplinks.

    To separate traffic you will need a physical interface for each of your internal networks (or work with VLANs if your infrastructure supports it).

    Your Multipath Rule assumptions seem coorect.

    You don't need to change your masquerading because "Uplink Interfaces" covers all interfaces with "Default gateway" ticked.
  • 0
    Hi, ICT, and welcome to the User BB!

    The only thing I would add is that the preferred destination is "Internet" instead of "Any" in this "culture."  Although it's not an important distinction here, it will be in other situations, so it's a valuable habit to cultivate.

    Cheers - Bob
  • 0 in reply to BAlfson
    Have you thought about load balancing - IE not dedicating a particular connection for a particular task, as this is a bit legacy.

    Obviously you may have your reasons as I don't see the full picture, however it may be worth considering allowing all traffic, then using QoS / Traffic shaping to handle the cloud prioritization.

    That way, if a connection / port / ISP / cable etc... gets lost, desiconected or any other reason, traffic will still pass over the other connection. Plus, dedicating a link will waste that links resources when its not used, and on the  other hand you are also limiting your self to a single connection, rather than spreading it across many.

    My 2 cents!
  • 0 in reply to RStokes
    Thank you all for your valued input, good to know I'm on the right track.

    I think load balancing is certainly something we will look at in the future. I was planning on deploying the UTM without making too many drastic changes straight up, just ensure everything continues to flow as normal, then look at enabling/tweaking additional features once things were stable and we're comfortable with supporting it. But I have however briefly tested failover with a 3G USB modem which was successful.

    Will need to schedule some downtime soon to get all the uplinks online and test everything - exciting times!
  • 0
    So we installed the UTM on Sunday and everything seems to be flowing through as planned. One small issue I ran into was that the "public" and the "cloud" networks couldn't connect to the internet. Hosts would get a DHCP lease from the DC but couldn't even ping the UTM's internal IP. After further troubleshooting I identified the UTM was missing routes to the two additional networks. So I added two "interface" routes going to the new "network" definitions I created to go via the "internal" interface. Following this the hosts on the secondary networks could ping the gateway and also external IPs. However no web browsing!
    I soon discovered I needed to create new firewall rules for each subnet, following this - all was good!

    The multipathing rules "by interface" seems to be splitting the traffic as indented. One question however,

    Q. What does "By Connection" actually mean, in relation to interface persistence?

    The manual states that in the case of an interface failure and if no subsequent rules match, the connection falls back to the default behavior (which is "by connection").

    It is nice to know that should a ADSL link go down, internet traffic should automagically flow to an available interface.
  • 0
    For example, if you had VoIP traffic bound to interface #1 and that connection went down, all of the calls would be dropped and you would begin establishing connections via interface #2.  When interface #1 comes back up, the new conversations will start on it, but the existing conversations will stay on #2.  Was that your question?

    Cheers - Bob