Let’s start by defining session persistency in the context of load balancing firewalls. Session persistency is the ability of the broadband bonding load balancer to keep the on going session alive even during WAN network problems. Normally, persistent sessions need to be kept on the same WAN link to work properly. With standard load balancers, normally this is not possible if the WAN link carrying the session disconnects. However, modern load balancers have a different approach, using broadband bonding, to keep the on-going sessions alive.
WAN network problems can be anything from spikes in packet loss rates to full disconnects. In essence, a load balancing firewall has the ability to steer packets around network problems and simultaneously keep track of the flow state so that the application is shielded from the network problems. For example, let’s assume we are using a dual WAN load balancing firewall with broadband bonding capabilities connecting a VPN tunnel between the main office and a branch office. In the case where one of the two WAN links fully disconnects, the VPN session will only experience reduced throughput rather than completely losing the VPN session, which would be the unavoidable outcome if broadband bonding was not used. In most VPN setups, if the load balancing firewall is not equipped to handle broadband bonding, then the WAN problems of a single WAN link will bring down the sessions that are on it. In our specific VPN example that may translate into longer periods of VPN outages as a disconnected VPN typically takes time to reconnect automatically – a common pain point that broadband bonding routers address directly.
In case the load balancing firewall lacks broadband bonding, then session persistency will be limited to forcing certain groups of sessions onto specific WAN links. As an example, if you have a set of sessions that are used for accessing your banking site, these session have to be kept on the same IP address as the bank servers expects, and therefore a load balancing algorithm that cannot detect session persistency requirements will fail the application. This is because the load balancer will randomly spread the sessions related to the banking site to various ISP WAN links and will therefore appear as if the user is accessing the site via more than one IP address. This will cause the application, i.e. the banking website, to fail automatically.
There are really two types of solutions to this problem. The preferred method is the one we described earlier, whereby you use broadband bonding to present a single IP address to the banking server, even while utilizing several USP WAN links. However, if you have to stick with load balancing without broadband bonding, then at least your load balancing firewall should be able to handle session persistency, where related sessions are kept on the same ISP WAN link, and therefore on the same IP address.
Cahit Akin, CEO, Mushroom Networks, Inc.
Mushroom Networks is the provider of SD-WAN (Software Defined WAN) and NFV solutions capable of Broadband Bonding that enables self-healing WAN networks that route around network problems such as latency, jitter and packet loss.