Dual WAN - HTTPS handling

[3pointD]

Several months ago I introduced a second ISP service to our network using the WAN2 port on our 80CM. I set it up in Weighted Load Balance mode by following the instructions in the Advanced Routing Guide. This also included setting up Dead Gateway Detection. So far this seems to work fairly well but recently I' ve come up against some HTTPS issues where the sessions get closed by the remote server because it seas the client as coming from two different IP addresses. I began by identifying the remote servers that were having trouble and adding policy routes to steer 443 traffic to them over a specific WAN port. This didn' t really seem like a flexible setup but it worked to alleviate the issues at hand. In the interest of making things more flexible I' d now like to route all HTTPS traffic over WAN2 but allow it to utilize WAN1 if WAN2 goes down. Also I' d like to ensure that I can still access HTTPS services LAN to LAN. What would be the best approach for this? I' m assuming I would write less strict Policy Routes for this. Is the Weighted Load Balance going to affect this or does the Policy Routes take precedence over ECMP because it is higher on the list? Any insight or nudges in the right direction would be greatly appreciated! FWF80CM - MR3 Patch 15

[abc987]

Yes, Policy Routes take precedence over all other routes. For a failover your Policy Routes should not contain a gateway address

[3pointD]

So even though I need to select the " outgoing interface" while creating the policy route I would not populate the " gateway" field?

[abc987]

So even though I need to select the " outgoing interface" while creating the policy route I would not populate the " gateway" field?

yes referring to the Advanced Routing Guide:

Most policy settings are optional, so a matching policy alone might not provide enough information for forwarding the packet. The FortiGate unit may refer to the routing table in an attempt to match the information in the packet header with a route in the routing table. For example, if the outgoing interface is the only item in the policy, the FortiGate unit looks up the IP address of the next-hop router in the routing table. This situation could happen when the interfaces are dynamic (such as DHCP or PPPoE) and you do not want or are unable to specify the IP address of the next-hop router.

[AndreaSoliva]

Hi one hint....! Because of your problem I would never implement this what you implmeneted. To think about look in following forum message: https://forum.fortinet.com/FindPost/107241 I would never recommend to go as mentioned in the Advanced Routing Guide for Load Balancing, Spillover etc. Keep control of you traffic to 100% and this what is mentioned in the link above gives you the possibility to do so. only a hint have fun Andrea

[3pointD]

Yes Andrea - I read that post before I started this thread. I' m pretty sure I understand what you are saying but it seems like the scenario in that post is to use the second wan as failover. I' d like to use both at the same time and I' d like one to be used 40% more than the other. I understand that in order to be in control of the traffic I need to control it with routing. I' m just not sure how to take ECMP Load Balance out of the picture but still providing a " weighted" access to both wan links. Could you give me another hint? :)

[AndreaSoliva]

Hi mmmhhh let' s try to give you my view! If you are using two lines with same IP range you can use some implementation like spillover or weight load balancing. If you use on each line another IP range you will have allways such problems you got. If you say that some traffic has to go over WAN1 and you do not want that it fails over if ECMP is not anymore running for WAN1 to WAN2 you do not implement a corresponding Firewall Policy and that' s it. From my point of view is the automatic stuff like spillover and/or load balancing only useable if you have ONE PUBLIC IP (or the same range) in front. Otherwise you do not really know in EACH REQUEST what will be the case. Also for troubleshooting reasons you do not know really where to troubleshoot because out of the box you do not know where the traffic is/should be. In my scenario you always know WHERE the traffic is if a line is up and as mentioned if you do not like that if a failover happens that the traffic goes over the second line do not implement a corresponding Firewall policy. If you have three ISP lines (example one specially for VOIP) no problem YOU SAY with the configuration (Policy Routes) where the traffic goes and you decide (with the Firewall Policy) if the traffic can use the fialover ISP or not. The only thing in this scenario is that ALL ISP' s meaning from routing perspective have to be configured with the same distance and priority. Since we changed and trained the resellers to this implementation (also for small envs) we do not have anymore problems. In the older releases 4 MR3 Patch 3/4/5/6 our scenario was not 100% working but since Patch 7 we do not have recongnized any problems and we do not have anymore calls from customers etc. For me is only ONE important " I DO NOT LIKE TO GIVE OVER THE DECISION WHERE TRAFFIC GOES! I DECIDE WHERE THE TRAFFIC GOES THAT I HAVE FULL CONTROL WHAT IS GOING ON! Again this sentence and this information is based on the situation that you have on each ISP a different public IP range. As soon as you have your own AS routed over the internet with your public IP range and in front of the firewall is configured some dynamic routing between both IPS (like HSRP) the situation changes and you can use some spillover or laodbalancing etc. hope this gives a understanding of my view and some stuff/points to think about have fun Andrea

[3pointD]

Yes, I understand your point completely. Actually that was sort of the conclusion I was coming to after the issues came up with the SSL connections because when I really thought about it is seemed like a high maintenance setup with lots of room for error and not much control. I' m hoping I can layer the routing policies properly to get what I want and remove the ECMP Load Balancing. Just wondering where you found the information showing the priority of the routing technology i.e. Routing Cache>Policy>Longest Match>Distance>Priority>Metric>ECMP? I haven' t seen that in the handbook. Or is this just general knowledge of routing? Also in order to not use ECMP do I simply take it out of the picture by setting it back to " source based" and implement my routing policies which take precedence? Thanks so much for the information and opinions!

[3pointD]

Hi Any reply RE disable/not use ECMP? I' m assuming that I set ECMP to " Source IP Based" and then override it with Policy Routes but just want to make sure. Also for the general policy routes can I just specify the interfaces and leave the source and destination as 0.0.0.0? I have several internal networks so if I want to ensure that I know exactly what path each will take to the internet I will need to specify a policy route for each internal interface correct? I will not specify " gateway" in these policies so that if that route goes down everything will be routed to default. Many thanks!

[AndreaSoliva]

Hi sorry did not see your answer :-) - Go to Source based ECMP and implement DGD. The Policy Route would overwrite the ECMP configuration and the DGD is to show Forti from routing point of view which path is available. Keep in mind that this would only work if you HAVE ON BOTH ROUTES same " cost" (Distance and/or Priority). Only in this way it works. Do not mix Policy Route and ECMP with different Distance and Priority because this makes situation tricky! Where I found the information of routing! Let' s say in this way! I' m working for a big distributor and have special contacts within Forti. I received this information as I was studying deeper into the stuff. Yes you are right this is nowhere documented and yes it is a pity because it is a " important" information from my point of view. Hope this helps have fun Andrea