Source–destination IP
The source-destination IP algorithm tries to equally divide the traffic between the interfaces included in the virtual WAN interface. It used the connection criteria of the source and destination IP address combinations as a way of sorting the traffic.
Example:
- 10.10.10.10 to 1.1.1.2 gets sent out one interface
- Subsequent traffic going from 10.10.10.10 to 1.1.1.2 would also go out that same interface
- The next session to connect through the WAN could be either:
- 10.10.10.27 going to 1.1.1.2
- 10.10.10.10 going to 1.1.1.15.
Either one of the connections in the next session, even though they might match the source or the destination IP address do not match both. Traffic with the next unique combination of source and destination IP address would be sent out the other interface. It would go back and forth like this as new traffic and combinations comes in.
Source IP
The source IP address works just the same as the source-destination IP algorithm but it only concerns itself with the source IP address of the connection.
Priority rules
Some traffic requires that it come from a consistent or specific IP address to be processed properly. Because the different WAN interfaces will have different IP addresses there needs to be a way to override the unpredictability of the load balancing algorithms. This is done by using priority rules
Packets can be checked prior to being assigned an interface by the algorithm. If certain source and/or destination criteria matches the priority rules, the packets can be assigned to an outgoing interface as determined by the rule.
Priority rules can be configured under Network > WAN LLB Rules. The source criteria that can be checked are:
- Source address
- User Group
The destination criteria that can be checked are:
- Whether it’s address-based
- Destination address
- Protocol number
- Whether it’s cloud application-based
- The cloud application
Cloud applications
Cloud applications are a new object that can be used and configured on a FortiGate. There are a limited number of places that they can be used as a means of directing traffic and Virtual WAN links are one of them.
Estimated Bandwidth
An optional parameter has been added that allows users to set the estimated uplink and downlink bandwidths of a WAN interface.This setting is available in both the GUI and the CLI.The range of the setting is from 0 to 16776000.
In the GUI, the there are two fields next to Estimated Bandwidth; one for Kbps Upstream and one for Kbps Downstream.
In the CLI, the fields can be set by using the following syntax:
config system interface edit <wan interface>
set estimated-upstream-bandwidth <integer from 0 – 16776000> set estimated-downstream-bandwidth <integer from 0 – 16776000> end
end
Status check
In order for the load balancing to be effective,there needs to be a constant monitoring of the health and status of the links that make up the virtual WAN link. Customized status checks can be configured to check on health of various aspects the traffic flow going through the link. Using either ICMP packets (PING) or HTTP requests to a designated server, the check can analyze one of the criteria: latency, jitters or packet loss. Once the health reaches a specified threshold, the interface can be automatically removed from the virtual WAN link so that the algorithm is not sending traffic to a failed interface and bring down communications for a portion of the FortiGate’s clientele.
Health Check (266883 299426)
A health check option has been added to the Virtal WAN link feature. The check is configured in the CLI as follows:
Config system virtual-wan-link
set fail-detect [enable | disable]
set fail-alert-interfaces (available only if fail-detect is enabled)
config health-check
edit [Health check name]
set server <string>
set protocol [ping | tcp-echo | udp-echo | http | twamp]
Some of the protocol options cause additional settings are made available.
http
twamp
set port
set http-get set http-match
set port
set security-mode[none | authentication]
The security-mode setting authentication generates yet another potential setting, password.
set password
set packet-size
The next settings are available for all protocols
set interval <integer> set timeout <integer> set failtime [1 – 10]
set recoverytime [1 – 10]
set update-cascade-interface [enable | disable]
set update-static-route [enable | disable]
set threshold-warning-latency <integer 0-4294967295> set threshold-alert-latency <integer 0-4294967295> set threshold-warning-jitter <integer 0-4294967295> set threshold-alert-jitter <integer 0-4294967295>
set threshold-warning-packetloss <integer 0-4294967295> set threshold-alert-packetloss <integer 0-4294967295> end
end end
Facing issue with WAN LLB , 3 ILL links are combined to Virtual WAN interface & algorithm is “Source IP” based, but only 1 link gets choked & rest 2 are only consumed only around 30-40%.
I prefer to use bandwidth on mine for LLB. Using source it is possible that you coincidentally just have all of the big hitters going through the same pipe.
i am having issue with mine (2 isp), when i connect to other fortigate outside the office i get disconnected because it uses the 2nd internet connection and the destination fortigate disconnects me.
It seems to happend with other things also.
In situations where you use WLLB and you are dealing with something that is smart enough to know that your IP (or the source in general) is switching up it will be beneficial to use routes. For instance, when I have WLLB enabled I set static /32 routes for the destinations that I know need to stay on a single connection (like a FortiGate I’m trying to administer remotely etc) to go out a specific pipe.
Otherwise, you will constantly get booted out of the device you are trying to manage which is quite annoying.
i havent tested/read about it yet, but lets say you have a policy route that uses wan1 for X reason, will it use wan2 in case the wan1 is down?
You would make two static routes (regular static routes like you do your default gateway routes….no policy route) that have the same destination (the remote device or service that requires the connection to stay on one WAN connection and not bounce between the two) the routes will be identical except the destination interface and gateway address will be different. The one you wish to be your primary you just make it have a lower administrative distance so that it takes precedence and if that connection fails the other route will take over.
ok, nice, thanks alot
Could you please explain me more details on (regular static routes like you do your default gateway routes….no policy route) that have the same destination (the remote device or service that requires the connection to stay on one WAN connection and not bounce between the two)? I would like to have user connection stay on only WAN link because now user internet connection is being kick out because of two difference IP WAN interface.
John,
If you have a specific user that you would like to stay on a specific WAN connection then policy routes tend to be the best). If that user is using only a specific resource that you can tie to an IP Subnet or destination then you can make a static route specific for that destination. This, of course, would force all people to use that pipe though. Policy routes can be very powerful when done properly.
Mike,
In the caso of two ISP with different bandwidth, for example 5 and 3MB, like your example. How do you work with the QoS ?
You consider the maximum bandwidth 5, 3 or the sum 8Mb in the rules ?
Any ideia ?
Thank you very much !!
In situations like this I usually have certain services tied to certain pipes anyways (and then just do the QOS based on that). For what you are asking though I would set my percentages based on the smallest pipe for safety reasons.
Just to clarify, do you recommend not using a policy route for systems that need a fixed, static, external address? We have a PBX server that registers with our SIP provider and needs to have a fixed IP address. Should I not use a policy route and instead use static routes for this system?
On a similar, but related note, how do NAT IP pools work with VIPs when using WLLB? For example, I have two VIPs setup for a server. Should I also have an IP pool setup for each VIP and use both of those when creating an outgoing traffic policy?
Thanks,
Doug
Doug,
Unless you are using BGP to route traffic from a set pool of IPs over BOTH circuits (with different weights for failover) I would definitely use policy routes to force the IP for the PBX to go out the desired pipe. If your phones phone directly out (no internal call manager) you will want to make sure they are on their own subnet for simplicity in the policy route configuration.
In regards to the VIP Rule, the VIP will be used for incoming traffic and the return traffic will use the same external address). Now, with WLLB you can run into some weird shenanigans if the device reaches out for remote services on a regular basis. You normally want the VIP policy match parameter to be set (or a specifically policy for internal to outgoing traffic that is tied to the VIP External IP) in order to ensure that machine can reach out and be translated properly (specially mail servers etc). If pipe 1 goes down and traffic is accessed through pipe 2, the VIPs appropriate will match (and in turn the outgoing policies configured for those interfaces) would work as mentioned. Not really recommended for services that rely on the external IP to be the same for security purposes etc but it does work.
Please let me know if I didn’t clearly explain something.
Mike, Sorry for commenting on an old thread. I need to make a range of ips to use a defined external interface. Lets say, 192.168.0.10-192.168.0.40. I know that i can do it using policy route, but its a lot of work, when other vendors ( Sophos, by example) you can route this way in the firewall policy. I saw someone saying that i can do it using wan llb, but i was unable to do it. What do you suggest?
There are WAN LLB Rules that you can enforce on 5.4 and 5.6 Beta.
They are essentially policy routes though. The cool thing is, at least on 5.6, you are able to set the destination address as “Internet Service” and select options such as “Facebook-DNS, Facebook-FTP,Facebook-Web, Google Gmail”, and so on and so on which keeps you from having to enter individual subnets etc.
Hi
Is it possible to segregate the traffic (one link is for normal traffic for surfing another one is mainly for VPN tunnel) with 2 ISP WAN link ? my current device model is Fortigate 60D.
Please advise the feature and mechanism to be deployed if it is feasible, Thanks
You can do that fine. You just have a 0.0.0.0 route that goes out your WAN1 (internet link) and then when you make your VPN Tunnel configuration you would tie it to WAN2. If you setup an route based IPSEC on WAN2 then you just setup a route saying a.b.c.d (destination network of other side of IPSEC) go out IPSEC INTERFACE and it will traverse the secondary link. If you are talking SSL VPN, you just have two 0.0.0.0 routes, one uses the WAN1 link (internet) the other uses WAN2 (vpn) and you just give them WAN2 link a higher priority (wan1 0, wan2 5) so they both work using ECMP. Then just make SSL VPN listen only on the WAN2 interface.
Hi Mike,
Thanks for your reply. Based on load balancing mechanism, I assume that it’s a mechanism in weight load balance under ECMP. Please correct me if my understanding is wrong. Thanks
Besides, can i deploy a HA environment with two boxes 60d acts as active/standby for incoming traffic (virtual server) which to have fault-tolerance in the event of primary box is down, thanks
It wouldn’t be load balancing on this one. You would just be utilizing different interfaces for different things (IPSEC on WAN2 regular internet traffic on WAN1)
Thanks Mike.
Hi, I just setup the WAN LLB on my fortigate 200D. Internet connection works really well but i have challenges with SSL VPN setup and also IPSEC VPN setup.
I have tunnels on different ISP connections. I have three ISP connections one has no VPN tunnel but the remaining two have. I have looked everywhere and cannot seem to find any documentation for setting up IPsec VPN and SSL VPN on the new fortios 5.4.. please help me… Thanks
You configure the IPSEC and SSL VPN the same way you always have. In a perfect world you could set up a primary and secondary and then load balance across them with ECMP. Just set the route for the network to go out each tunnel and have it match priority and distance. Boom, your tunnel is redundant and possibly faster if the remote end has multiple connections as well.
Hi Mike,
I have 2 WAN links having same bandwidth (80x80Mbps), for some reason I need to user PBR. I have to Bluecoat Proxies i.e. 1.1.1.5 and 1.1.1.6. In the PBR I created following:
1.1.1.5 > WAN1
1.1.1.5 > WAN2
1.1.1.6 > WAN2
1.1.16 > WAN1
I need both proxies to utilize both WAN links equally always, If one proxy goes done then the other just uses the first WAN policy mentioned and doesn’t use the other to LB.
Any suggestion how can I use both proxies to use all WAN links equally all the time?
Thanks
So right now all of your users use the bluecoats. The bluecoats should default to the Gate and then using WAN LLB it should auto switch. Policy routes should not be necessary to do what you are wanting. This is assuming that you have WLLB setup properly and the weights of the circuits properly set.
Hi.
I have 2 wan links, a dedicated 20Mbps (fully guaranteed speed) and a 20 Mbps ADSL (20% guaranteed). I tried to use WAN LLB with the volume algorithm to properly balance the connections, but it causes several issues with internet banking sites, as it breaks SSL comm, by changing client’s IP. I changed the LB algorithm to “Source IP”, which solves my SSL problems, but now the FG is balancing the sessions evenly between the links. Is there any workaround to this? Can i use weighted algorithms and keep connections from same source ip from use different links?
Thanks.
You can use policy routes that will give priority to a certain link (and keep it on that pipe unless it goes down)….in all honesty I much prefer to have two links tied to a zone. make my policy from inside zone to outside (wan) zone and then have health checks that pull the more quality links static route in the event of circuit failure. The crummy DSL line will just give you trouble if you try to use it live with anything else
We have 3 isp and isp1(20mbps), ips2(10mbps), isp3(4mbps). Configured spillover in fortigate os 5.4.5.
configured like
ISP1 –> ingress(19mbps) –> egress(19mbps)
ISP2 –> ingress(9mbps) –> egress(9mbps)
ISP3 –> ingress(4mbps) –> egress(4mbps)
when i observe isp1 link gets 21MBPS used but i do not find any shift over to isp2.
What can we configure yet to make over the shift.
Is this a single machine performing a pull down of a specific file? Are you able to run multiple machines, make one go over the spillover limit and then let the second machine attempt to surf out to see if it switches to the next link?
Mike,
As Ricardo said, I have a similar situation where i want to enforce all traffics coming from a particular source subnet/IP to go via a defined WAN link to all destination. I thought policy routes would be the best option but it forces me to add more policy routes for my other requirements prior to this route.
I am trying to achieve this by adding WAN LLB Priority rules.
unfortunately i am unable to select users as “ALL” in the WAN LLB rules in GUI as well as in CLI.
following are the concern;
1. Is it mandate to have users section to use this WAN LLB priority rules?
2. If i leave users section as blank, will this WAN LLB priority rules be effective?
As of now i don’t have any policy routes in place and i have three WAN links which is included in WAN LLB. I use Source IP based WAN LLB.
Firmware Version- 5.4.4
Appreciate your response.
Regards,
Nanthakumar S