Your engineering team just got pulled off their planned work. Again.

For the third time in 18 months, the script is the same: a high-severity vulnerability drops, the emergency siren blares, and your roadmap takes a back seat to a load balancing vendor’s recurring technical debt.

We need to talk about the cycle of memory leaks, the cost of the 'patching tax', and whether your architecture is serving your business—or just surviving your vendor.

The current crisis: CVE-2026-3055

If you're running a customer-managed NetScaler load balancer or Gateway, stop reading this and verify your versions. This isn't a next week task; attackers are already actively probing /cgi/GetAuthMethods in the wild.

This latest flaw follows the path of its predecessors, CVE-2023-4966 (Citrix Bleed) and CVE-2025-5777. All three are memory leak vulnerabilities. All three carry CVSS scores above 9.0.

Patch immediately if your builds are older than:

• 14.1 < 66.59
• 13.1 < 62.23
• 13.1-FIPS/NDcPP < 37.262

The current crisis has ignited a firestorm of collective grief across the internet, with widespread alarm and frustration expressed by the tech community:

• The Sequels Are Never As Good, But We're Still In Pain
• Please, We Beg, Just One Weekend Free Of Appliances

The hidden bill: Engineering debt

Beyond the immediate security risk lies a massive operational drain. Every emergency patching cycle carries a heavy price tag for your engineers:

1. Direct labour costs: Multiple engineering days lost to staging, testing, and deploying patches.
2. The distraction tax: The resistance felt afterwards when trying to restart a deep-work engine, having ripped developers away from their work on your high-value roadmap.
3. The compound interest: Multiply these interruptions by three in 18 months. You aren't just maintaining a load balancer; you're burning a significant percentage of your annual engineering capacity on a single vendor's recurring failures.

You've got to ask yourself: if you know other load balancers exist, why are you still tolerating one that's causing you so much pain?

Is your NetScaler still earning its place?

The load balancer market has matured, with NetScaler alternatives offering comparable performance with significantly simpler patching models and a lower Total Cost of Ownership (TCO).

At your next architecture review, move past the "it's what we've always used" defense and ask yourself these hard questions:

• The audit: What was your actual load balancer patch cadence over the last 24 months, and what did that truly cost us in engineering time?
• The exposure: Are our management interfaces properly isolated, or are we just assuming they are?
• The justification: Could we honestly justify this vendor choice to the higher-ups today based on its recent track record?

The bottom line: The tipping point?

Security is a shared responsibility, but at some point, a pattern of critical vulnerabilities in such quick succession becomes a signal.

Patch your systems today. But tomorrow, start the conversation about whether it’s time to migrate to a platform that respects your team's time as much as your data's security. The 'patch first, then ask questions' approach simply doesn't cut it when the frequency of critical flaws starts to disrupt the core mission of your engineering team.

Further reading

• Citrix NetScaler bug exploited in days, may be multiple flaws in a trench coat
• NetScaler ADC and NetScaler Gateway Security Bulletin for CVE-2026-3055 and CVE-2026-4368

I've said it before, and I'll say it again: a major pitfall of the F5 ecosystem is the total lack of control over the product lifecycle. When they decide a product is finished, you're forced to move on their timeline, not yours.  

On the chopping block this time is nearly the entire F5 iSeries. In 2024, the much-loved F5 i2600 and almost all iSeries SKUs went End of Sale (EOS). Now, it's the last hurrah, with the official wrapping up of the iSeries family confirmed for January 1st 2027. This leaves many re-evaluating (yet again) whether migrating to an alternative might make more sense.

So, how do you prevent history repeating itself with your next provider? It’s easy to assume that forced product retirements are just a standard industry headache—but they don't have to be.

At Loadbalancer.org, we do things differently. If you’re looking for a partner that prioritizes longevity over planned obsolescence, here's why we’re the refreshing change you’ve been waiting for.

The death of the F5 iSeries

In 2024, F5 stopped selling the iSeries. Of course, this initially only applied to new customers; many existing users continued to run their appliances without issue. However, F5 has now announced it will finally End Software Support (EoSS) for the iSeries in 2027.

This means:

• No more software updates: F5 will no longer provide software fixes, security patches (CVEs), or maintenance releases.
• Version pinning: You can continue to run your currently installed versions, but you won't be able to move to newer releases.
• Standard support ends: You will automatically transition from Standard Support to Extended Support (provided you have a contract that covers it).

So where does this leave you?

Option 1: Stick with F5

To continue receiving software support, F5 customers must transition to rSeries or VELOS hardware running a supported software version (listed here) before the deadline.

Option 2: Switch to an F5 alternative with End of Life

While the iSeries has strong contenders, simply switching to a giant like Citrix NetScaler often just trades one expiration date for another. While it's a capable alternative, it doesn't solve the primary headache—you’re still at the mercy of a rigid product lifecycle. And, given the high cost of a NetScaler, that's a hefty investment for a solution with a limited shelf life.

Option 3: Choose an F5 alternative with no End of Life

Loadbalancer.org is unique in the market because we do not End of Life our products. It’s a commitment we made years ago to put our customers first. Choosing our Enterprise load balancer allows you to bypass the traditional EOL cycle completely, helping you regain control over your infrastructure's budget, security, and stability.

Don't get me wrong...we're not saying you shouldn't upgrade when a new version of our product is released—just that you don't have to. The timing is up to you. In fact, we recently heard from a customer running v6.2 of our Enterprise hardware load balancer (we're currently on v8.13.5!). They set it up in 2016, left it for a decade, and it was still running perfectly. As they put it: "perhaps it is time to upgrade". If that's not an advert for a rock-solid solution that 'just works', I don't know what is!

But while our refusal to End of Life our products might have caught your attention, that's just the start.

Beyond breaking the cycle of planned obsolescence, here are five other compelling reasons to migrate to Loadbalancer.org...

5 reasons to choose Loadbalancer.org

1. Cost

Cut costs without cutting corners. With some of the most affordable appliances on the market, you can have enterprise-grade performance without the enterprise tax. We also believe you should be in the driver’s seat of your procurement process, which is why we provide total pricing transparency. No gatekeepers, no sales pressure, and no need to speak to a human (unless you want to).

"We've been using Loadbalancer.org across multiple environments, and it's hands-down one of the best infrastructure investments we've made". Manuel Carrillo, Linux Architect & System Engineer, Reviews.io.

2. The market sweet spot

Most IT teams feel stuck between two extremes: overpaying for complex solutions like F5 or Citrix, or drowning in the complexity of DIY open-source tools. We hit the sweet spot: enterprise-grade load balancers built on rock-solid open-source foundations (Linux and HAProxy) but with a proprietary, streamlined GUI and professional support.

"Great appliances and even greater support - there's not much more a man could ask from Loadbalancer.org, keep up the good work!”. Dragan Janjusevic, Linux System Administrator, Reviews.io.

3. WAF & GSLB included

We've eliminated feature-gating. We offer our Web Application Firewall (WAF) and Global Server Load Balancing (GSLB) straight out of the box. You get advanced security and multi-site resilience from day one without being hit with secondary license keys, per-feature subscriptions, or throughput penalties.

"We now have seamless failover of our storage services to the live site of our choosing when maintenance is carried out, or one of our data centers goes down". Read success story.

4. Designed by engineers, for engineers

Load balancing doesn’t need to be rocket science. Our intuitive WebUI simplifies the complexity, putting power back in your hands. This allows you to slash the risk of configuration errors, accelerate deployment, and manage the appliance entirely in-house—eliminating the need for expensive third-party specialists.

"From a technical standpoint, the platform is incredibly reliable, flexible, and straightforward to manage. It provides all the functionality we need to build highly available services without unnecessary complexity". Patrick Bemis, IT Infrastructure Manager, Reviews.io.

5. Consultative support that goes beyond the box

The secret sauce of Loadbalancer.org is our people. Unlike vendors who stop helping the moment a packet leaves their appliance, our support team acts as an extension of your own. Our tierless team of Level 3 engineers help solve the whole problem; in fact, more than half of our resolved tickets involve issues with a client’s own network or a third-party solution.

"Your support team is by far the best support we experience across any of our contracts and suppliers. If only others could match your level of knowledge and speed of response, the IT world would be a happier and less cynical space". Nick Woodruffle, Managing Director, Reviews.io.

Putting you back in control

The 2027 deadline for the F5 iSeries is a loud reminder that in the world of proprietary hardware, you don't always own your infrastructure strategy. When a vendor decides your appliance is done, they aren't just retiring a product; they are disrupting your budget, your team's bandwidth, and your long-term stability.

At Loadbalancer.org, we believe that an appliance bought in 2016 should still be a high-performing asset in 2026 if that’s what your business requires. Whether you're looking to escape the enterprise tax, simplify management, or finally end the forced migration cycle, we’re here to make the transition seamless.

Further reading

• Load balancer migration: The F5 alternative turning heads
• Seamless migration from F5 BIG-IP to Loadbalancer Enterprise
• Scared of moving away from an F5 load balancer?

In modern cloud-native environments, HashiCorp Vault is the definitive source of truth for secrets, identity, and encryption. However, placing Vault at the center of your stack introduces a critical paradox: your security solution then becomes your most significant single point of failure!  

When a standalone Vault instance hangs or goes offline, the blast radius is total. CI/CD pipelines fail to authenticate, microservices crash during boot because they cannot lease database credentials, and automated rotation scripts stall. In a production environment, Vault downtime isn't just a security risk — it’s a total operational hard-stop.

To move beyond a lab-grade setup, engineers must implement High Availability (HA) architecture using Raft integrated storage and intelligent traffic management. This guide breaks down how to deploy a resilient, 5-node Vault cluster behind an enterprise-grade load balancer.

I’ll focus on ensuring seamless leader election, automated health monitoring via the /v1/sys/health endpoint, and maintaining TLS integrity across the entire request path.

Table of contents

1. Bare metal specs for this lab configuration
2. Pre-requisites for HashiCorp Vault
3. Installing HashiCorp Vault
4. Initializing the Vault cluster
5. The load balancer appliance configuration

What is HashiCorp Vault?

HashiCorp Vault is an identity-based secrets management tool designed to secure, store, and tightly control access to sensitive credentials, such as API keys, passwords, and certificates. Unlike a static key-value store, Vault functions as a centralized Encryption as a Service platform that automates the entire lifecycle of sensitive data.

Think of HashiCorp Vault as the ultimate air-gapped logic for your credentials. In the networking world, we’re used to managing static service accounts or SSH keys tucked away in config files. Vault kills that practice.

It’s an open-source powerhouse that treats every 'secret' — whether that’s an API key, a database password, or a TLS certificate — with the same level of scrutiny you'd give a core switch login.

Why it’s different from a standard KV store:

• Identity, not just keys: It doesn't just hand out data. It hooks into your existing sources of truth (like LDAP, AWS IAM, or K8s) to verify exactly who's asking before it opens the door.
• Encryption as a Service: You can offload the heavy lifting of encrypting data-at-rest to Vault via its API, so your apps never actually handle the raw keys.
• Automated Lifecycle: It acts like an automated Certificate Authority, handling the generation, rotation, and revocation of certificates so you aren't the one getting paged when a certificate expires at 3:00 AM...

Essentially, Vault moves you away from static security to a programmable, API-driven workflow that covers your entire infrastructure. Pretty awesome, huh?

Why a production-ready Vault environment needs a load balancer

The scenario: Vault as the central nervous system

In a modern GitOps or IaC-driven environment, Vault isn't just a static password manager — it’s a mission-critical infrastructure component. It handles dynamic secret generation, ephemeral database credentials, and just-in-time cloud access across your entire CI/CD lifecycle.

The problem: The secret bottleneck

Running a standalone Vault instance in production is a recipe for a cascading failure event. If that single node hits a network partition, a disk I/O hang, or a memory leak, your entire stack goes dark (eek!!), resulting in:

• Pipeline gridlock: CI/CD runners can't pull secrets, effectively freezing all code deployments.
• Microservice boot failure: New pods fail their readiness probes because they can’t retrieve their initial database leases.
• Monitoring blackout: Automated backup and observability scripts lose the credentials needed to function, leaving you blind during an outage.

The solution: HA architecture with load balancing

Transitioning to a multi-node raft-integrated storage cluster solves the state problem, but the load balancer solves the traffic problem.

By fronting your cluster with a load balancer, you move from a fragile setup to a hardened security service, with:

• Active-standby coordination: While Vault nodes manage their own leader elections, the load balancer ensures that clients only ever talk to the node that can actually process requests.
• Intelligent health probing: The load balancer continuously polls the /v1/sys/health endpoint. It automatically distinguishes between an Active Leader (200 OK) and a Standby Node (429 Too Many Requests), ensuring zero-latency failover.
• Easy lifecycle management: Need to patch the OS or upgrade Vault? No problem. You can cycle nodes one by one, while the load balancer proactively diverts traffic away from draining nodes, preventing the dreaded 504 Gateway Timeout in your application logs.

The result? Zero trust reliability

By decoupling the client from the specific node IP, you create a security layer that is as reliable as the power grid. Security stops being a bottleneck for velocity and becomes a robust foundation for 24/7 global operations.

How to load balance HashiCorp Vault

Now, let's look at the reference architecture and load balancer configuration.

Bare metal specs for this lab configuration

Recommend Operating System

Ubuntu 24.04 LTS: These are the gold standards for Vault. They have excellent support, modern kernels, and the official HashiCorp repositories are always up-to-date.

RHEL/AlmaLinux 9: A solid choice if your organization requires an enterprise-grade RedHat-based environment.

Cluster size

• 3 Nodes (Minimum): Provides High Availability (HA). The cluster can survive 1 node failure.
• 5 Nodes (Recommended for Production): Provides better quorum stability. The cluster can survive 2 node failures.

Hardware specs (per node) for production

And the final part before we get started...

We need to make sure that each node has a static IP address with a resolvable hostname, so you might need some DNS changes.

We are also going to either need a SSL cert for each node or a wild card cert (I'll be using my wildcard cert *.digiscout.uk for this blog).

And finally we need a shared FQDN that points at your floating IP (I'll be using vault.digiscout.uk).

Pre-requisites for HashiCorp Vault

Before we do anything else, we need to make sure that each of the servers that will be used to host vault have had the following checks done...

Make sure they are all up-to-date on system patches:

sudo apt update && sudo apt upgrade -y 

Ensure each node has a reachable FQDN, configured by a root user within the local hosts file.

Be sure to update the line that points to 127.0.1.1 (or your static IP) so it looks like this:

127.0.1.1 vault-01.<doamin> vault-01

After you add the FQDN you can also test it with the following, where you should see both the hostname and the FQDN in the output:

hostname && hostname -f

Make sure each has a local copy of the certificate:

sudo mkdir /vault_files
cd /vault_files
sudo mkdir certificates 
cd certificates

Then use a tool like SCP to transfer your Certificate (note, Vault cannot use a single .pem file if it contains both the certificate and the private key together):

# 1. Extract the Private Key 

sudo openssl pkey -in /path/to/your/original.pem -out /vault_files/certificates/vault.key

# 2. Extract the Certificate(s) # This gets the wildcard cert + any intermediate/CA certs in the file 

sudo openssl crl2pkcs7 -nocrl -certfile /path/to/your/original.pem | sudo openssl pkcs7 -print_certs -out /vault_files/certificates/vault.crt 

Installing HashiCorp Vault

Now we need to add the HashiCorp gpg key and repo to the server:

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg 

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list 

Then we can update the package list:

sudo apt update 

And you should see apt.releases.hashicorp.com in the output:

Now we can install Vault:

sudo apt install vault

We then need to set the permissions on our Certificate and key so that only Vault can use them (note, we couldn’t do this earlier as the required user and group hadn't been created yet!):

sudo chown -R vault:vault /vault_files/certificates 
sudo chmod 600 /vault_files/certificates/vault.key 
sudo chmod 644 /vault_files/certificates/vault.crt

Now we need to configure the system permissions (Vault needs to lock its memory to prevent sensitive data from being swapped to disk):

sudo setcap cap_ipc_lock=+ep /usr/bin/vault

Next, we need to create a HashiCorp Vaults config file. But first we need to back up the one provided by the install:

sudo mv /etc/vault.d/vault.hcl /etc/vault.d/vault.hcl.old

Now we create a new configuration file:

sudo nano /etc/vault.d/vault.hcl

Here is a template for the configuration file for node 1 of a 5 node cluster:

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-node-01" # Update this per node (01, 02, 03, etc.)
  
  # All nodes should list the other 4 nodes here
  retry_join { leader_api_addr = "https://vault-01.digiscout.uk:8200" }
  retry_join { leader_api_addr = "https://vault-02.digiscout.uk:8200" }
  retry_join { leader_api_addr = "https://vault-03.digiscout.uk:8200" }
  retry_join { leader_api_addr = "https://vault-04.digiscout.uk:8200" }
  retry_join { leader_api_addr = "https://vault-05.digiscout.uk:8200" }
}

listener "tcp" {
  address            = "0.0.0.0:8200"
  cluster_address    = "0.0.0.0:8201"
  
  # Using your new path
  tls_disable        = "false"
  tls_cert_file      = "/vault_files/certificates/vault.crt"
  tls_key_file       = "/vault_files/certificates/vault.key"
  
  # Since you're using a wildcard, Vault needs to know which name to expect
  tls_min_version = "tls12"
  tls_prefer_server_cipher_suites = "true"
}

# The address clients (and other nodes) use to reach THIS specific node
api_addr      = "https://vault-01.digiscout.uk:8200"
cluster_addr  = "https://vault-01.digiscout.uk:8201"
ui            = true

Lastly, verify that the Vault storage directory exists and has the appropriate permissions configured:

sudo mkdir -p /opt/vault/data 
sudo chown -R vault:vault /opt/vault/data

Initializing the Vault cluster

On each node, start the Vault Service:

sudo systemctl start vault
sudo systemctl status vault

This is this the normal and expected output:

To start, we need to initialize the Vault on node 1 only:

export VAULT_ADDR='https://vault-01.digiscout.uk:8200'
vault operator init

Now, unseal the first node using 3 of the keys provided:

vault operator unseal <key1> 
vault operator unseal <key2> 
vault operator unseal <key3>

After you enter the first key, the output will show:

And once you have entered 3 keys, you should see it change:

Now we need to unseal the other nodes in the cluster.

First, we need to make each node use their FQDN:

export VAULT_ADDR='https://vault-<number>.<domain>:8200'

N.B. To avoid typing this every time you log in, you might want to add this to your user profile....

Open your bash profile: nano ~/.bashrc

Scroll to the bottom and add: export VAULT_ADDR='https://vault-01.digiscout.uk:8200'

Save and exit (Ctrl+O, Enter, Ctrl+X).

Apply it: source ~/.bashrc

Remember to do this on every node, replacing the 01 with the correct node number for that specific server.

Now, enter 3 of the unseal keys, like you did on node 1:

vault operator unseal <key1> 
vault operator unseal <key2> 
vault operator unseal <key3>

Check the vault status and make sure each node has unsealed:

vault status

Look for these specific lines in the output:

• Initialized: Must be true.
• Sealed: If true, it still needs keys.
• Storage Type: Should be Raft.
• HA Mode: Should be standby (on node 2) or active (on node 1).

The final test is to run the following on the leader node (in our case node 1), this will cause the Vault to tell you which of the other nodes have joined the cluster.

To do this...

First we need to Authenticate to the vault:

vault login

When prompted, enter the initial root token that was created at the same time as the unseal keys.

This should return something like the following:

Now we can test the cluster:

vault operator raft list-peers

And if the cluster is healthy, it should return something like the following:

One last test we can do is to access the WebUI of Vault. To do this, open your favourite web browser and go to the address of your first node -> https://vault-01.<domain>:8200/ui

For now, let's leave it set to 'Token' for the method and use the initial root token.

The load balancer appliance configuration

Now let's move on to configuring the load balancer for use with the HashiCorp Vault cluster. For illustrative purposes, I'll use a Loadbalancer.org appliance.

Custom health checks

The first thing we are going to do is create a custom health check script for the cluster:

1. Login to your Primary Loadbalancer and navigate to:

Cluster Configuration > Health Check Scripts

2. Click 'Add New Health Check'

3. Fill in the following:

• Name: HashiCorp_Vault_Health_Check
• Type: Virtual Service
• Template: Example
• Primary Node Health Check Content:

#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/root/

## Vault Health Check Script
## By: Nick Hawkins-Booth - Loadbalancer.org Technical Support Engineer
## Version: 1.0 - Initial Script

_RIP=$3
_PORT=$4
_TIMEOUT=5

# We check the standard Vault health endpoint
_CHECK_URL="v1/sys/health"

# Perform the test to get the HTTP response code
# -s: Silent
# -k: Insecure (ignores self-signed certs on Vault nodes)
# -o /dev/null: Discard the body
# -w: Output only the status code
_HTTP_STATUS=$(curl -m $_TIMEOUT -s -k -o /dev/null -w "%{http_code}" https://$_RIP:$_PORT/$_CHECK_URL)

# Vault Status Code Logic:
# 200 = Active Leader
# 429 = Standby (Healthy, but not the leader)
# 503 = Sealed or Uninitialized (Not ready for traffic)

if [[ "$_HTTP_STATUS" == "200" ]] || [[ "$_HTTP_STATUS" == "429" ]]
then
    # Node is initialized and unsealed.
    _EC=0
else
    # Node is sealed, uninitialized, or down.
    _EC=1
fi

exit $_EC

• Secondary Node Health Check Content: Un-tick this

4.  Click Update

Virtual Service creation

Now that our Loadbalancer can better understand what the Vault cluster is telling it, let's create a Virtual Server for the cluster. This is a standard Layer 7 VIP just using the External Script with our new Health check script and port 8300.

Let's start by building out the Virtual Service for the Vault Cluster. Go to:

1. Cluster Configuration > Layer 7 - Virtual Services

2. Click 'Add a new Virtual Service'

3. Fill in the following details

• Label: VIP_Vault_Cluster -> or something meaningful
• IP Address: The Floating IP for this service
• Ports: 8200
• Layer 7 Protocol: TCP Mode
• Click Update

4. Click 'Modify' on your new VIP

5. Scroll down to the health check section and make the following changes:

• Health Checks: External script
• Check Script: HashiCorp_Vault_Health_Check

Real Server configuration

Now with have a Virtual Service set up, let's add the Real Server.

1. Cluster Configuration > Layer 7 - Real Servers

2. Click 'Add a new Real Server'

3. Fill in the following details:

• Label: HashiCorp_Vault_Node_1 > or something meaningful
• Real Server IP Address: The IP address relevant to the node in the cluster
• Real Server Port: 8200
• Re-Encrypt to Backend: unticked
• Weight: 100

4. Click Update

Repeat this for each node.

Once your done, remember to reload the HAProxy service.

And if we go back to the 'System Overview' you'll see that that's it!

But what if you don't want to go to the load balancer WebUI to run a test?!

No problem! To test the WebUI just open your favourite web browser and point it at: https://vault.<domain>:8200/ui.

Or, if you want to create a Key Vault and add a Test Secret via the command line, here's how...

1. Enable the KV secrets engine

Since we're working with curl from your workstation, we can enable a KV version 2 engine (the recommended version) at the secret/ path with this command:

curl -k -H "X-Vault-Token: YOUR_TOKEN" \
     -X POST \
     -d '{"type":"kv-v2"}' \
     https://vault.<domain>:8200/v1/sys/mounts/secret

Wait for an HTTP 204 response (Success or No Content).

2.  Write a test secret

Now that the 'handler' (the KV engine) exists at that route, we will need to create the test secret:

curl -k -H "X-Vault-Token: YOUR_TOKEN" \
     -X POST \
     -d '{"data": {"password": "mypassword"}}' \
     https://vault.<domain>:8200/v1/secret/data/test

3. Now, read the secret back from the Vault:

curl -k -H "X-Vault-Token: YOUR_TOKEN" \
     https://vault.<domain>:8200/v1/secret/data/test

This should return a JSON object that contains your test data:

4. Finally, let's clean up and delete the test data, but leave the KV version 2 engine:

curl -k -H "X-Vault-Token: YOUR_TOKEN" \
     -X DELETE \
     https://vault.<domain>:8200/v1/secret/metadata/test

And that should be your testing completed.

Conclusion: Production-ready sensitive data management

Deploying this 5-node HashiCorp Vault cluster transitions your infrastructure from fragmented secret management to a centralized, High Availability (HA) identity provider.

By moving beyond the initial install, you’ve hardened the environment against both infrastructure failure and lateral movement, and achieved the following architectural outcomes:

• Operational autonomy: Utilizing Raft Integrated Storage (FSM-based consensus) removes the "hidden" overhead of managing external Consul clusters or cloud-native backends, simplifying the failure domain.
• Cryptographic integrity: Custom mTLS ensures end-to-end encryption in transit, while Least Privilege ACLs enforce a zero-trust model even for privileged operators.
• High Availability (HA): The 5-node quorum ensures the cluster remains operational and maintains a leader even during a two-node concurrent failure.

But a production-grade foundation is likely only the beginning.

Your ultimate objective will be to reach a zero-static state, so you'll need to implement dynamic secrets.

Instead of rotating long-lived passwords, you'll need to configure Vault to interface directly with your database and cloud IAM engines. This allows Vault to generate on-demand, time-bound credentials that expire automatically, effectively eliminating the risk of credential leakage and manual rotation cycles.

Further reading

• How to configure a Vault cluster with integrated storage
• What is Raft Integrated Storage
• Audit logging
• What Secrets can Vault keep
• MySQL/MariaDB database secrets engine
• Redis database secrets engine
  

The IaaS hyperscalers (AWS, Azure and GCP) all claim to provide ‘seamless’ load balancing with a single click. But as your architecture grows (spanning multiple regions, hybrid environments, or multi-cloud clusters), those ‘simple’ native tools often hit a wall. Whether it's a lack of deep packet inspection, the inability to ‘lift and shift’ your routing rules, or the frustration of the so-called ‘80% Rule’, enterprise traffic management is rarely as simple as a checkbox.

Choosing the right load balancer is about more than just moving traffic; it’s about avoiding vendor lock-in, cost control, security and multi-cloud resilience.

For enterprise, the market is split into two distinct offerings: cloud-native services like AWS, Azure and GCP, tailored to each ecosystem, and third-party, cloud-agnostic appliances built for consistency.

This guide explores the best cloud load balancers on the market today, comparing the native stacks of the Big Three IaaS providers (AWS, Azure and GCP) against third-party, virtual alternatives, to help you find the right fit for your use case.

Table of contents

1. What is cloud load balancing
2. Best cloud load balancer for AWS
3. Best cloud load balancer for Azure
4. Best cloud load balancer for GCP
5. AWS, Azure vs GCP load balancer comparison
6. Best cloud load balancer for multi-cloud
7. Best cloud load balancer for security
8. Best cloud load balancer for cost
9. Hang on, what about Cloudflare?

What is cloud load balancing?

Cloud load balancing is a distributed service that manages traffic across regional and global resources, providing solutions such as:

• High Availability: They manage the distribution of traffic and computing resources across virtual server pools.
• Scalability: They facilitate horizontal scalability by seamlessly integrating newly provisioned instances into the rotation.
• Performance: They evenly distribute traffic to maximize throughput and minimize latency.

Unlike traditional hardware, modern cloud load balancers operate across multiple layers (L3–L7) and often integrate with DNS and Content Delivery Networks (CDNs) to ensure high availability and low latency.

How does cloud load balancing differ from traditional server load balancing?

Traditional server load balancing and cloud load balancing share the same primary goal (distributing traffic to prevent server overload) but they differ fundamentally in architecture, scalability, and management.

While traditional on-premise load balancing relies on ‘racking and stacking’ physical appliances, cloud load balancing is a software-defined service integrated into a global network.

What’s the difference between a cloud-native and cloud-agnostic cloud load balancer?

Cloud‑native load balancing services found built-in to public cloud providers like AWS, Azure and GCP are tailored to each provider, and offer a one-click setup and automatic scaling.

They are:

• Fully managed and tightly integrated with each platform’s autoscaling, observability, security and container stack.​
• Designed for massive scale, multi‑AZ or global availability, and pay‑per‑usage economics.​

Meanwhile, third‑party, cloud-agnostic cloud load balancers, such as those provided by Loadbalancer.org, are independent software solutions that work identically across any cloud or on-premise environment, preventing vendor lock-in.

They are:

• A full ADC you manage as a VM appliance, with rich L4/L7 features, WAF, GSLB and detailed health‑check and persistence options.
• Consistent across environments, providing the same UI and behaviour in on‑prem, AWS, and Azure (with GCP currently single‑node).​

In this sense, native load balancers compete on integration, simplicity, and cloud‑first workflows; Loadbalancer.org competes on feature depth, operational consistency across clouds, and vendor support.

So which one do you need?

We’ll dive into a side-by-side comparison of AWS, Azure and GCP load balancer offerings shortly. But first, a critical question:

If your cloud provider already offers a built-in load balancing add-on, why would you even think about buying a third-party solution?! The answer lies in the trade-off between the convenience, commercials and control needed for your use case.

Why built-in, cloud-native load balancers aren’t always the right choice

Many cloud providers offer their own, cloud-native, load balancer add-ons. But while these are convenient and easy to spin up, they often lack the depth required for complex, high-scale, or multi-cloud architectures.

The bottom line? Built-in isn’t always better for these reasons:

1. Vendor lock-in and lack of portability: With cloud-native load balancers, moving to a different cloud or adopting a multi-cloud strategy is incredibly painful. You can’t simply 'lift and shift' your routing rules, security policies, or automation scripts because the load balancing architecture is unique to each cloud. This means you’re forced to re-architect your traffic management layer every time you want to expand to a new environment.
2. Limited visibility and observability: Troubleshooting complex issues—like microbursts of traffic or specific API errors—can be difficult. You typically don’t get deep packet inspection, detailed transaction logs, or the ability to trace a request’s full journey through the load balancer in real-time without expensive add-ons. This results in a slower Mean Time to Resolution (MTTR) during outages and performance degradation.
3. The 80% Rule: You might find yourself missing critical capabilities like advanced WAF (Web Application Firewall) customization, complex traffic mirroring, sophisticated rate limiting logic, or support for legacy protocols. This places additional burdens on engineering teams, requiring them to build workarounds to plug feature gaps. For example, native load balancers often lack advanced HTTP header manipulation, forcing engineers to use sidecars to compensate, adding unnecessary complexity.

Let’s do a deep-dive of each of the main hyperscalers to illustrate this.

Best cloud load balancer for AWS

What does the AWS Elastic Load Balancing (ELB) portfolio offer?

AWS has two main load balancer types:

• Application Load Balancer (ALB): Layer 7 HTTP/HTTPS/gRPC, with host/path‑based routing, header and query‑based rules, WebSockets, HTTP/2, and deep integration with ECS, EKS and Lambda targets.​
• Network Load Balancer (NLB): Layer 4 TCP/UDP/TLS with static IPs, ultra‑low latency and very high throughput, ideal for non‑HTTP protocols and real‑time workloads.​

In a traditional setup the ALB or NLB load balancer is the destination. The client talks to the load balancer, the load balancer terminates that connection, before then starting a new connection to the server.

AWS also offers the following (although the Classic Load Balancer is a legacy solution, and the Gateway Load Balancer isn't a reverse proxy, operates at Layer 3 and forward packets instead of changing the source or destination IP):

• Gateway Load Balancer (GWLB): IP‑level load balancer for inserting and scaling virtual network appliances (firewalls, IDS/IPS) using GENEVE encapsulation.​
• Classic Load Balancer (CLB): Legacy L4/7 load balancer retained mainly for older EC2‑Classic and simple apps; not available for new designs.​

Collectively, AWS load balancers are referred to as Elastic Load Balancers (ELBs), a generic term encompassing all AWS load balancers, although personally I find this catch-up all term unhelpful given the very different solutions on offer.

Redundancy and scalability are fully managed, and each load balancer type is inherently multi‑AZ within a region, scales automatically, and integrates tightly with EC2 auto scaling and container services.​

Path-based vs. host-based routing

The AWS Application Load Balancer (ALB) operates at the Application Layer (Layer 7), which allows it to make intelligent routing decisions based on the content of the HTTP/HTTPS request in the following ways:

• Host-based routing: The ALB routes traffic based on the domain name in the request. This allows you to host multiple websites or services with different domains behind a single load balancer, saving costs on infrastructure.
• Path-based routing: The ALB routes traffic based on the URL path after the domain. This is critical for microservices architectures, where a single entry point (one domain) serves many different independent services.

AWS Lambda functions

Traditionally, load balancers sent traffic to 'always-on' resources like EC2 instances or containers (ECS). A major selling point of the AWS ALB is the ability to register AWS Lambda functions as a target. More on the benefits of AWS Lambda.

So how do the AWS ALB and NLB compare to a cloud-agnostic load balancers such as Loadbalancer.org?

What does a third-party load balancer offer in AWS?  

Let's take Loadbalancer.org as an example third-party, cloud load balancing provider so we can talk specifics.

Loadbalancer’s Enterprise AWS ADC is cloud-agnostic load balancer, delivered as a virtual appliance on EC2 — usually deployed as an HA pair behind one or more AWS load balancers, or directly with Elastic IPs.​

Key characteristics of the Enterprise AWS:

• Full ADC feature set: Advanced L4/L7 virtual services, SSL termination and re‑encryption, content switching, URL rewrites, cookie/persistence options, application‑aware health checks, and an integrated WAF.​
• HA and failover: Active/standby pairs are available with state and config sync, typically fronted by an AWS NLB or ALB for IP stability and seamless failover.​
• Portability and a Freedom License: The same product and interface can run on‑prem, in AWS, Azure, and other environments, allowing reuse of policies and configuration across estates.​

Which one makes sense for your AWS environment?

Let's start with a feature comparison of the two AWS load balancing offerings described above (AWS ALB and NLB load balancers, and the third-party load balancer Loadbalancer.org).

Based on this, I'd personally recommend using an ALB or NLB AWS load balancer when:

• Workloads are cloud‑first web APIs or microservices on ECS/EKS/Lambda and fit neatly in ALB and NLB feature sets. ​
• Operational simplicity matters more than granular ADC features. ​

And instead use a Loadbalancer.org appliance in AWS when:

• You need consistent ADC behaviour across data centres and clouds (e.g. same persistence or health‑check semantics in multiple environments).​
• You need richer ADC features, custom WAF policies, or GSLB patterns that exceed standard AWS capabilities. ​

Here's an example use case for a third-party load balancer in AWS:

Best cloud load balancer for Azure

What does the Azure native load‑balancing stack offer?

Azure’s load‑balancing portfolio is split by layer and scope:

• Azure Traffic Manager: Global DNS‑based load balancing service providing priority, performance and geographic routing across endpoints.
• Azure Standard Load Balancer: Regional Layer 4 (TCP/UDP) load balancer for internal and public traffic, with zone‑redundant frontends, health probes, and support for high‑availability (HA) ports to balance all ports with one rule.​
• Azure Application Gateway (v2): Regional Layer 7 HTTP(S) reverse proxy and WAF, with path/host routing, autoscaling, zone‑redundancy and tight integration with AKS as an ingress controller.​
• Azure Front Door: Global, edge‑based HTTP(S) front door combining anycast routing, TLS termination, optional CDN, and WAF, comparable to Front Door and global ALB in other clouds.​

They also used to offer something called an Azure Basic Load Balancer, but this was retired in Sept 2025.

High Availability is built around Availability Zones and regional redundancy, while the Standard Load Balancer and Application Gateway v2 can be zone‑redundant inside a region, while Front Door and Traffic Manager handle multi‑region failover.​

Azure Front Door WAF v Application Gateway's WAF

The most misunderstood security aspect of Azure's load balancing offering is the difference between their Global WAF (Front Door) and their Regional WAF (Application Gateway). In fact, in many enterprises, engineers use both.

• Azure Front Door WAF: The Front Door WAF blocks broad, high-volume attacks and bots at the global edge.
• Azure Application Gateway WAF: The Application Gateway WAF provides a second layer of security inside the region, closer to the actual code, to catch anything that might have slipped through or to protect internal-only services

In my experience, if you have a public website with users across the country or world, use the Front Door WAF. If you have a single-region app or need to keep traffic strictly private, then you need the Application Gateway WAF.

HA ports in Azure

The use of HA ports will let a single internal Standard Load Balancer rule handle all TCP/UDP traffic across all ports, using 5‑tuple hashing per flow. ​

I'd recommend considering HA ports in the following use cases:

• You have Network Virtual Appliances (NVAs) and third‑party ADCs that must see arbitrary east‑west flows without per‑port configuration.​
• Complex multi‑port applications where dozens of rules would otherwise be required.​

What does a third-party load balancer offer in Azure?  

Let's take the same third-party load balancer we did before to keep the comparison like-for-like.  

On Azure, Loadbalancer.org is delivered as a virtual appliance pair in a Virtual Network, relying explicitly on the Azure Load Balancer to manage failover.​

This tag-team approach plays out in the following way:

• Azure Load Balancer frontends terminate the VIP and use health probes to direct traffic to the active Loadbalancer.org node. If the active node then fails, Azure will stop sending traffic to it and shift to the standby node. ​
• HA ports are commonly used in front of the appliance pair when the ADC is acting as a generic NVA handling many ports or protocols.​
• The same ADC features and UI as in AWS and on‑prem are also available, enabling consistent behaviour and policies.​

Which one makes sense for your Azure environment?

Let's compare the features of each load balancer in the same way we did for AWS:

Given this, I'd favour using Azure native services when:

• You're building primarily on AKS or VMSS and want Application Gateway + Standard Load Balancer + Front Door to handle in‑region and global web traffic with minimal operational overhead.​
• You want first‑class integration with Azure WAF, DDoS, Identity, and monitoring without managing appliance OS upgrades.​

And opt for Loadbalancer.org in Azure when:

• You need to replicate an existing Loadbalancer.org or other ADC configuration from on‑prem or AWS, with identical failover and persistence behaviour.​
• You want one ADC skillset and UI across multiple clouds and data centres, while still leveraging Azure Load Balancer and Front Door for zoning and global reach​.

In practice, a common model is to have the Azure Front Door → Application Gateway or Azure Load Balancer → Loadbalancer.org HA pair → backend pools, especially in hybrid or regulated environments.

Best cloud load balancer for GCP

What does the GCP Cloud Load Balancing portfolio offer?

Google Cloud focuses heavily on global, software‑defined load balancing.​

It's main services include:

• External Application Load Balancer: Global, anycast Layer 7 HTTP(S) load balancer with a single global IP, content‑based routing, Cloud CDN and Cloud Armor WAF.​
• External Network Load Balancers / proxy: Regional L4/L7 options for TCP, UDP and SSL proxy traffic, suited to non‑HTTP and legacy protocols.​
• Internal HTTP(S) Load Balancer: Regional L7 for service‑to‑service communication inside a VPC, ideal for internal APIs and microservices.​
• Internal TCP/UDP Load Balancer: Regional L4 for east‑west traffic within a VPC, often fronting NVAs and internal services.​

All Cloud Load Balancing services are fully managed and integrate with Managed Instance Groups (MIGs), enabling automatic scaling and zone‑redundant deployments within a region.​

What does a third-party load balancer offer in GCP?  

Currently, the Loadbalancer.org appliance on GCP runs as a single virtual ADC instance on Compute Engine with no supported HA clustering or active/standby model equivalent to AWS and Azure. ​

Practical consequences:

• You can front the appliance with internal or external GCP load balancers, but these will only distribute traffic to that single appliance instance.​
• Appliance failure results in downtime until the instance is restarted or rebuilt; there is no native, vendor‑supported HA pair with automatic failover at the ADC layer at the time of writing this.​

Which one makes sense for your GCP environment?

This makes GCP’s own Cloud Load Balancing the primary option for production‑grade HA, with Loadbalancer.org currently best suited to PoCs, labs, or lower‑criticality roles where a single ADC instance is acceptable.

AWS, Azure vs GCP load balancer comparison

High-level AWS, Azure, and GCP comparison

Here's a high-level load balancing comparison of AWS, Azure, and GCP's load balancers:

You can see at a glance that their load balancing architectures prioritize completely different operational goals:

High-level AWS, Azure, and GCP comparison

• Global connectivity strategy: Google Cloud (GCP) is the most natively global, using a single anycast IP to route traffic across the world. In contrast, AWS and Azure are more regional by default; to achieve similar global reach, you must layer on additional services like AWS Global Accelerator or Azure Front Door.
• Ecosystem Specialization: The "Best For" row illustrates that the choice often depends on your existing stack rather than just the load balancer's features. AWS excels in deep, granular integration (like triggering Lambda functions), while Azure is the logical choice for enterprises deeply embedded in Active Directory or hybrid Windows environments.
• Management Overhead: GCP offers the most unified experience with a single control plane. Azure’s portfolio is more fragmented, requiring users to manage multiple distinct services (Standard LB, App Gateway, and Front Door) to cover all layers of the OSI model, which increases configuration complexity but offers specialized control at each tier.

AWS vs Azure vs GCP (L7 web capabilities)

Layer 7 (L7) web capabilities in the cloud refer to the Application Layer of the OSI model, where the infrastructure understands the actual content of the web traffic (HTTP/HTTPS). This allows for smart routing based on URLs, cookies, and headers, rather than just IP addresses.

The primary L7 services for the Big Three providers are:

• AWS: ALB is regional; for global anycast and CDN‑style behaviour you combine CloudFront and/or Global Accelerator.​
• Azure: Application Gateway is regional; Front Door provides the global, edge‑based HTTP(S) tier.​
• GCP: External Application Load Balancer is global by default with a single anycast IP, combining many features other clouds split across services.​

AWS vs Azure vs GCP (L4 and NVA patterns)

Layer 4 (L4) capabilities focus on the Transport Layer (TCP/UDP). Unlike Layer 7, these services do not peek inside the data packets; they route traffic based purely on IP addresses and ports. This makes them significantly faster and capable of handling millions of requests per second with ultra-low latency.

NVA (Network Virtual Appliances) are third-party VMs (like Fortinet, Cisco, or Palo Alto firewalls) that you insert into your cloud network to perform specialized security or routing functions.

The primary L4 services for the Big Three providers are:

• AWS NLB/GWLB are strong fits for high‑performance TCP/UDP and appliance chaining.​
• Azure Standard Load Balancer with HA ports is highly flexible for NVAs and multi‑port workloads.​
• GCP Internal TCP/UDP Load Balancing plays the same NVA front‑end role but with a different implementation model.

Here's some differing opinions from real people on which of the Big Three load balancers is better:

• What are GCP feature advantages compared to AWS, Azure, other cloud providers?
• Honest question: why do people choose Google Cloud over AWS (or even Azure) when AWS still dominates almost every category?
• Google Cloud vs Azure vs AWS

Best cloud load balancer for multi-cloud

If you're looking for a multi-cloud load balancer then here's where a cloud-agnostic solution really comes into its own.

AWS, Azure and GCP load balancer multi-cloud considerations

Choosing between an AWS, Azure or GCP and cloud-agnostic load balancer for a multi-site deployment depends on whether your 'multi-site' strategy is multi-region (within one provider) or multi-cloud (across different providers).

For most users, cloud-native is better for single-provider multi-region setups, while cloud-agnostic load balancers, such as Loadbalancer.org, are essential for true multi-cloud or hybrid-cloud architectures.

Based on my experience, my suggestion would be to choose cloud-agnostic if...

• High Availability (HA) is the priority: You need your site to stay up even if an entire cloud provider (e.g., all of AWS) goes offline. An increasingly frequent occurrence these days.
• Hybrid cloud: You have some workloads in the cloud and some on-premise.
• Regulatory needs: You're required by law to avoid dependency on a single vendor.

Best cloud load balancer for security

There's no simple answer to this one. Neither approach is 'more secure' as such; instead, they offer different security advantages depending on your team's expertise and the complexity of your environment.

AWS, Azure and GCP load balancer security considerations

AWS, Azure and GCP load balancers come with default security settings. Great for those who just want to plug and play, but not so great for those who know what they're doing and want to customize or enhance their security setup.

In a nutshell:

• Integrated identity and access (IAM): You can control who can modify the load balancer using the same IAM roles you use for the rest of your infrastructure.
• Automated DDoS protection: Most native balancers include basic Layer 3 and 4 DDoS protection (like AWS Shield or Google Cloud Armor) as a built-in feature.
• One-click compliance: They often come with pre-configured WAF (Web Application Firewall) rule sets that satisfy compliance standards (PCI-DSS, SOC2) without manual tuning.
• Managed SSL/TLS: Certificate rotation is handled automatically by the provider (e.g., AWS Certificate Manager), reducing the risk of expired certificates causing downtime or security warnings.

Third-party, cloud-agnostic load balancer security considerations

Third-party, cloud-agnostic load balancers provide centralized security control. Great for those who want to maintain a consistent security posture across different environments.

For example:

• Policy parity: If you use multiple clouds (AWS + Azure), an agnostic balancer allows you to run the exact same WAF rules and security scripts everywhere. This prevents 'security drift' where one cloud is configured more strictly than another.
• Deep packet inspection: Agnostic tools often allow for more granular Layer 7 inspection and custom security logic that native balancers might not support.
• Zero-trust integration: They are often easier to integrate with third-party Zero-Trust Network Access (ZTNA) providers or external identity providers (like Okta or Ping Identity) across hybrid environments.
• Reduced blast radius: Because the balancer is independent of the cloud provider’s control plane, a massive outage or compromise of the provider’s management console is less likely to affect your traffic routing.

My advice?

Based on my experience, I'd recommend:

• Using cloud-native if you want to minimize the risk of human error (misconfigurations) and want the cloud provider to handle the 'heavy lifting' of security maintenance.
• Using cloud-agnostic if you are in a highly regulated industry (like Finance) and need a single, unified security wall that looks and acts the same regardless of which cloud provider is hosting the server. The Loadbalancer Enterprise appliance comes into its own here, offering the same interface across the 'Big Three'.

Best cloud load balancer for cost

There are two contrasting approaches to cloud traffic management that offer vastly different cost structures:

1. Pay-as-you-go
2. Bring Your Own License (BYOL)

The 'best price' depends on what you're measuring. Are you looking at the bottom line on your monthly invoice, or the hidden costs of engineering time and maintenance?

AWS, Azure and GCP load balancer cost considerations

Cloud-native balancers (AWS ALB, Google Cloud LB) use a pay-as-you-go model.

• Monthly billing: This provides a low barrier to entry, with costs scaling linearly with traffic. You pay for Load Balancer Units (LCUs/capacity units), which can become expensive at extreme scales.
• Operational savings: You save money on salaries. There are no servers to patch, no software to update, and no high-availability (HA) architecture to design. The cloud provider handles all undifferentiated heavy lifting.
• Vendor lock-in: One of the hidden costs is that if your provider raises prices or your architecture becomes inefficient on their platform, the cost to migrate to another cloud (refactoring) can reach hundreds of thousands of dollars.
• Break/fix support: Technical support is available, but even with the most comprehensive support package, you're still talking to a generalist who supports hundreds of different services (databases, AI, storage, etc.). So if you have a complex networking issue involving a specific legacy application protocol, they may struggle to provide deep architectural advice. If the load balancer service is 'up' but your traffic isn't flowing because of a complex routing rule you wrote, a hyperscaler support agent might simply point you to their documentation.

Third-party, cloud-agnostic load balancer cost considerations

Cloud-agnostic providers like Loadbalancer.org offer license-based or flat-rate pricing.

• BYOL: Cloud BYOLs allow you to deploy high-performance Enterprise ADC (Application Delivery Controller) software on major cloud platforms like AWS, Azure, and GCP using a license purchased directly from the third-party provider. Unlike pay-as-you-go models where the cloud provider bills you hourly for software, BYOL decouples the software license from the cloud infrastructure. This requires a higher upfront cost (licensing or setup time). However, once the software is running on a Virtual Machine, you can push massive amounts of traffic through it without the 'per-request' fees that cloud providers charge.
• Operational savings: With a user-friendly WebUI, extensive documentation, and industry-leading support mean you don't need to be a load-balancing expert to manage your appliance.
• Arbitrage savings: Because you aren't tied to one vendor, you can move your backend to whichever cloud is currently cheapest without changing your load balancing layer.
• Deep technical support: If you opt for a third-party cloud load balancing provider like Loadbalancer.org, you end up talking to an engineer who lives and breathes a single product. They often act as an extension of your engineering team, helping you solve the "how do I make this work?" rather than just "is the service broken?" They will hop on a call with you at the drop of a hat to help you debug your specific configuration.

My advice?

If you’re after something quick and cheap to start, a load balancer from AWS, Azure, or GCP is the way to go. But if you'd prefer clear, predictable pricing and a team of experts ready to support you, a third-party provider is likely a better fit.

Hang on, what about Cloudflare?

For those who've jumped straight to this section, you’re likely looking for the 'catch'. In other words, why would your team choose NOT to use Cloudflare?!

After all, everyone uses it, and it's cheap and amazing...

Why Cloudflare isn't a local/infrastructure replacement

While Cloudflare is a brilliant leader in global traffic management, it lacks the 'deep roots' required for complex infrastructure management:

1. VPC visibility: Cloudflare sits outside your private network. It cannot see the CPU load of your individual EC2 instances or automatically scale your Kubernetes pods. A local load balancer (like AWS ELB) is infrastructure-aware and reacts to the real-time state of your backend.
2. Middleman risk: Using Cloudflare adds another single point of failure. If Cloudflare has an outage (as they occasionally do), your site goes down even if your backend servers are healthy.
3. Protocol depth: Cloudflare is optimized for web traffic (HTTP/HTTPS). While they offer services like Spectrum for TCP/UDP, it is often more expensive and less flexible than a native Network Load Balancer (NLB) when handling non-web protocols like database replication or proprietary IoT streams.
4. Zero-knowledge limits: For high-compliance industries (like Finance or Healthcare), Cloudflare presents a challenge — to inspect and cache traffic, they usually must decrypt it at the edge. If your security policy requires end-to-end encryption where only your local infrastructure holds the keys, an edge proxy can be a compliance hurdle.
5. Added latency for local traffic: If your users are physically close to your data center, routing them through a Cloudflare 'hop' can actually increase latency rather than reduce it.

Overall takeaways

Do you need a cloud-native or cloud-agnostic load balancer? Well, the chances are, you might need both!

As I’ve hopefully illustrated above, cloud-native and cloud-agnostic load balancers can be complementary, as well as oppositional to the cloud native stack.

The cloud hyperscalers (AWS, Azure, GCP)

The hyperscalers tend to be the ‘go-to’ load balancing solution for:

• Straightforward cloud-native workloads (especially those where IT teams want easy NoOps scaling and tight platform integration).
• Teams already locked into a specific cloud ecosystem who need deep integration.

AWS and Azure’s offerings are fully HA‑capable with appliance pairs integrated into each cloud’s own load‑balancing and zoning constructs.

However, bear in mind that in GCP there are currently HA limitations like zonal-only focus for some tech (Regional PDs), configuration inflexibility (HA VPN gateways are immutable), performance trade-offs (Regional PD write latency/throughput), potential for longer failover times (database recovery), and reliance on user-defined health checks for application-level HA.

Third-party, cloud-agnostic providers (the performance/arbitrage king)

Third-party, cloud-agnostic load balancers, such as Loadbalancer’s Enterprise product, in contrast, act as a strategic load balancing layer for the following workloads:

• Hybrid/multi-cloud estates needing uniform behaviour across environments.
• Use cases needing richer ADC features, WAF, GSLB, or very specific failover and persistence.
• Environments where a dedicated vendor relationship and support model are required.
• High-scale enterprises where LCU fees from cloud providers would reach millions of dollars. Here, you pay for the Virtual Machine, not per request.

Cloudflare (the edge leader)

Cloudflare is best for security-first organizations and those wanting to offload heavy traffic before it even hits their cloud.

The are lots of other third-party, cloud-agnostic load balancers too!

For comparison purposes and simplicity, I've used Loadbalancer.org for the cloud-native/cloud-agnostic comparisons above. But there are of course number of other third party load balancers available on the market, including F5 and Citrix NetScaler which I'd be remiss not to mention.

Ultimately, my main takeaway would be to let your architecture be the starting point to guide your research. But that conclusion's a bit boring, so let me know what you think in the comments below ; ).

If you're from a network background or are of a certain age (or both), you will have come across Access Control Lists or ACLs.  

The term ACL likely brings to mind images of rigid Cisco firewall rules and strict 'permit or deny' gatekeeping. But in the context of HAProxy, an ACL is much more than a simple security list — it’s the engine behind the 'clever stuff.'

While traditional ACLs are about stopping traffic at the door, HAProxy ACLs are about directing that traffic with surgical precision. They are the logic tests that allow your load balancer to think for itself, transforming a basic entry point into a sophisticated traffic controller.

In this blog, I'm going to pull back the curtain on how these rules have evolved and explain why they're the secret sauce of modern web architecture.

What do most people think ACLs are?

Most people think that an ACL is an Access Control List, which are a basic list of simple rules that control access to the network. These are historically associated with CISCO firewalls.

If we cast our minds way back to simpler times, we started out with 'Standard Access Lists'. These lists checked the rules against the source IP address only if there was a permit match against a rule in the ACL, traffic is permitted. Similarly, if the source IP matches against a deny rule, the traffic will be denied.

After a few (or many) years, router hardware and software was upgraded to a point where 'Extended Access Control Lists' became a possibility.

The difference between Standard ACLs and Extended ACLs is that the latter are also able to Evaluate the destination IP, the protocol and source and destination ports.

For example:

!--- Allow Telnet on port 23 to a single host on the network
access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.10.64.1 eq 23
access-list 100 deny tcp any any eq 23  

The point that I'm dancing around is that ACLs have evolved from their origins into something slightly different. And HAProxy ACLs are something entirely different again.

What are HAProxy ACLs?

HAProxy ACLs aren't ACLs in the traditional sense where they're implemented solely to control access to the network/resource. In fact, the rules that we see and implement in HAProxy are rarely used to perform access control (that really should be performed by a next generation firewall in this day and age).

But if HAProxy ACLs aren't doing what their name suggests they should be doing, then what the heck are they doing? The answer to that is "all the clever stuff" i.e. the conditional processing of traffic.

HAProxy Access Control Lists (ACLs) are named rules that define a condition based on an aspect of an incoming request or response. They are essentially a logic test that evaluates to either true or false and are then used to perform a specific action, providing fine-grained control over traffic flow.

They are incredibly powerful and when combined they can do almost everything that F5 iRules can do — but are way easier to understand, and less likely to break!

When do most people need to start implementing HAProxy ACLs?

As soon as you start straying away from run-of-the-mill, vanilla load balancing, you are going to need to start implementing HAProxy ACLs to achieve your goals. Here's a common example...

HAProxy ACLs use case: Microservices

One of the more popular implementations of HAProxy ACLs nowadays is with microservices architectures.

For example, say you have an application that is hosted on https://app.example.com. Your application is based on a microservices architecture so that a single entry point actually sends requests to a number of different locations.

If a picture is worth a thousand words then my highly technical diagrams should save me from writing a couple of paragraphs:

And this is how it looks when you configure all these backends on a Loadbalancer.org appliance:

Here we have a Virtual IP address (203.0.113.50) which corresponds to the FQDN app.example.com.

All the requests that come in for that FQDN hit the MicroServices_App Virtual Service.  Those requests then need to be directed to the correct backend pool of servers that are able to service the request.

What was all that exposition about?
It was the setup for the big reveal...

How can we do this with HAProxy?
Yep (you guessed it) with ACLs!

The HAProxy ACL-friendly microservices load balancer: Enterprise

We've tried to make HAProxy ACLs as easy as possible for you in the Loadbalancer Enterprise web interface:

How does Enterprise work?

Loadbalancer Enterprise simply translates ACL rules from the HAProxy configuration file i.e.

   acl :rule1 path_beg /static
   use_backend be_app_static if :rule1

The ACLs that we have here are directing requests to the correct backend based on the URL path. This is the simplest configuration that achieves the requirements of the proposed microservices architecture.

That is a very broad overview of one of the more prevalent HAProxy ACL use cases.

But, what else can HAProxy ACLs do?

A simpler question might be, "what can't they do?".

When customers have specific needs beyond standard load balancing, an ACL is often the solution. Whether the requirement is directing requests to specific storage servers based on reported object size or denying requests based on the source IP, HAProxy ACLs have got you covered.

The ACL section of the HAProxy documentation is just over 29,000 words. To give you an idea of how much content that is, George Orwell's 'Animal Farm' is 29,966 words... The configuration options and descriptions of HAProxy ACLs could constitute an entire book all on its own but here are some resources well-worth reading:

• HAProxy config tutorials
• HAProxy ACL guide

So, to go back to my original question, When is an ACL not an ACL?

When it's an HAProxy ACL!

Ps. If you are an F5 iRules master, and think that HAProxy ACLs make life too easy for you — then you might want to check out LUA scripting with HAProxy.

The clock is ticking toward the April 15, 2026 EOL deadline for Citrix file-based licensing. Have you started your mandatory transition to the License Activation Service (LAS), only to hit a brick wall because your on-premise NetScalers refuse to talk to the cloud? Then you've come to the right place.

You're not alone. The shift to LAS promises "automatic renewals" and "simplified licensing," but for many administrators managing (OFF/ON)line NetScaler Console connected appliances, the reality is a series of file transfers to avoid any potential outages.

The traditional Citrix License Server isn't the solution, and that looming License Entitlement Expiry date is a source of some serious anxiety.

Let's turn those on-prem LAS headaches into a set-it-and-forget-it (well, almost!) licensing strategy.

What is Citrix LAS?

Citrix LAS, or License Activation Service, represents a modernization and continuation of the existing Citrix License Server components.

The License Activation Service functions by linking your license server directly to Citrix's cloud service, enabling automatic allocation of licenses based on your purchased entitlements.

This is supposed to make it easier than manually assigning licensing and perhaps forgetting to replace expired ones (oops!).

How do I activate Citrix LAS?

You can activate LAS for your Citrix products if your license server is build 51000 or higher.

It's simple to set up, simply:

1. Log in to the Citrix Licensing Manager on your license server.
2. Navigate to Dashboard > License Activation Service tab.
3. Click Register and copy the code displayed.
4. Login to Citrix cloud.
5. Navigate to Licensing > Licensed deployment > License Servers > Add License Server.
6. Paste the code copied earlier.
7. Review the registration details and click Register.

Solving Citrix LAS issues on NetScaler

The licensing structure is applicable to all Citrix products, but here I'll focus on NetScalers, as they can experience some issues if you are not adequately prepared!

What's the issue for File-based Licenses?

Traditionally, Citrix NetScalers support multiple forms of licensing, including File-based, Pooled-Capacity and Flexed licenses.

File-based licensing is still very much used. But this method of applying licenses will reach its official End of Life date on April 15, 2026.

No panic there, right? Wrong!

You still risk becoming unlicensed if you upgrade your firmware with a “Subscription Advantage Date” (SA) that's not future-dated.

Note also that LAS is an added feature in the following firmware versions, meaning you can turn unlicensed when upgrading to either:

• 14.1 build 51.x
• 13.1 build 60.x
• 13.1 build 37.x (FIPS)

And if you have NetScalers in an HA pair and you let the secondary run for 30 days as a secondary, your license will also drop!

Now, if you’re thinking “help, what does that mean?!”, allow me to demonstrate how you can check your licensing type and “SA”, and explain what happens if you do turn unlicensed.

How do I check my NetScaler licensing type and SA?

Luckily, to prevent issues during your upgrade, you can prepare to see what kind of licensing you use!

On the NetScaler, you will find the licensing details in the GUI:

1. Log in to the NetScaler management interface.

2. Navigate to System > Licenses.

3. Here you’ll see an overview of the uploaded and active license(s).

4. If your NetScaler says “Licensing mode: Local” its using File-based Licensing:

5. Download the license file and open it locally.

6. Check for the second date in the file.

The second date tells you how “current” your entitlement is. Think of it as the line in the sand that decides whether your system is allowed to run newer firmware. If the firmware you’re upgrading to was released after your shown date, the NetScaler will probably refuse to apply the license, and you will find yourself in an unlicensed state. This results in your configuration breaking, and I have seen instances where it breaks your access to the GUI too (CLI will still work).

If you are using Pooled Capacity / Flexed Licensing, you should be OK during the upgrade process but you still need to upgrade to LAS licensing before 15-04-2026. This condition is only true if you still have an active subscription with Citrix, of course.

Help! How do I fix a white screen after an upgrade?

• Remove the SSL access (set ns ip <NSIP> -gui enabled) from the management interface via the CLI.

This will allow you to access the GUI again.

DON'T FORGET to turn this on again after your repairs, as it’s an important security setting!

How do I activate Citrix LAS for my NetScalers?

If you want to configure your NetScaler for LAS, the following firmware prerequisites need to be met:

• 14.1 build 51.x
• 13.1 build 60.x
• 13.1 build 37.x (FIPS)

NetScaler instances will also need to utilize the NetScaler Console (or connect directly to the cloud) for LAS licensing to synchronise licences with the cloud.

This means that for those with on-prem NetScalers that aren't connected to the NetScaler Cloud Console, LAS now becomes a lot more complicated.

My on-prem appliances aren't connected to NetScaler Cloud Console, so where does that leave me?

Remember, you must transition to LAS-compatible versions (and by extension, have current maintenance/support) before 15th April 2026 to remain licensed and supported.

NetScaler users currently using File-based Licenses with no NetScaler Cloud Console access must manually do the following well before then...

How do I switch to LAS licensing without connecting to the NetScaler Cloud Console?

To switch to LAS licensing, you must use perform a LAS Offline Activation, which will require you to do the following.

How does LAS Offline Activation work?

1. Navigate to System > Licenses:

2.You will now be met with a button that says: “LAS Offline Activation”:

3.When pressing the button you will see the following and need to perform the following steps:

• Press “Generate” to generate your “activation request” file.
• Press the “Download” button that is now available and save the file somewhere on your computer.
• Upload the activation request in Citrix Cloud to generate the activation file. (Go to Citrix Cloud > Licensing > NetScaler licenses > NetScaler ADC).
• Select the license type that you would like to use in the presented steps (e.g. VPX -> 1GBPS premium). This will differ based on what is available to you.
• Download the newly generated “activation blob” file and upload it to your NetScaler:

• If all went well, you will now be presented with the question if you want to activate your license straight away. Press “Yes”.
• Save your NetScaler config and do a reboot of the appliance. The license should now be applied.

Still having issues?

I hope this helps you set up NetScaler LAS on-premise!

As an aside, I would expect (hope!) LAS to change its ways over time, so keep an eye out for any changes in the Citrix documentation!

In the meantime, if you need help with your NetScalers, simply comment below or reach out to me on LinkedIn.

December is here and, whether you're ready or not, the countdown to Santa's arrival is officially on!

While some may be dreaming of R&R over the festive period, there's no downtime on my watch. No sir. In my household only 100% uptime will do! We've got a mountain of cash to raise for an important charity that means the world to me —and my Christmas display will be the engine driving it all.

So, I thought I'd have a little fun this year and make my Christmas lights Highly Available, using a Loadbalancer.org appliance to give my fundraising efforts a turbo-boost.

Now there are Christmas lights and there are Christmas lights. And my lights are not your normal twinkly lights. Mine are hundreds of individually addressable LED’s synced to music. After all, go big or go home, right?! And, as we know, the more complex things are, the greater the risk of downtime.

So how did I go about using our load balancers to make my light show Highly Available?

Santa's servers: The bare metal config

For this basic setup I needed to load balance the following port and services:

• Web UI: 80/tcp
• DDP: 4048/udp
• sACN/E1.31: 5568/udp
• FPP MultiSync: 32320/udp

Festive functionality: The WebUI

So let's start with the easy bit and work our way up from there...

The WebUI is used for configuring the system and uploading the sequences and music files.

1. Log on to the Loadbalancer appliance WebUI
2. Go to - Cluster Configuration -> Layer 7 - Virtual Services
3. Click “ Add a new Virtual Service “
4. Enter the details for this new Virtual Service [Label: L7-FPP-Webui / IP Address: <Floating ip> / Ports: leave as port 80]
5. Click "Update"
6. Add the real servers: click on Cluster Configuration -> Layer 7 - Real Servers
7. Click on “ Add a new Real Server “ at the end of the L7-FPP-Webui row
8. Enter the details for the Real Server [Label: RIP-FPP-Master1 / Real Server IP Address: <real server IP> / Real Server Port: 80 / Re-Encrypt to Backend: unticked / Redirect URL: Blank / Weight: 100]
9. Click “ Update “
10. Cluster Configuration -> Layer 7 - Virtual Services
11. Click “ Modify “ next to L7-FPP-Webui
12. Scroll down to the Fallback Server section
13. Enter the details for the second real server [IP Address: <secondary Real server IP> / Port: 80 / Click "Update" / Finally click "Reload HAProxy":

Now, if we head back to the System Overview tab you'll see my new service up and running:

But why only 1 Real Server, I hear you ask? Well, in this configuration I've created a service that will only send traffic to the second Real Server when the first one is down.

Jingle bells: Data services

For the last 3 services, I created Layer 4 Virtual Services.

These services are in charge of sending data packet broadcasts to the Light Controllers and also syncing data to Falcon Player like the one’s used on my Matrix.

• Go to - Cluster Configuration -> Layer 4 - Virtual Services
• Click "Add a new Virtual Service"
• Enter the details for this new Virtual Service [Label: L4-FPP-DDP / IP Address: <Floating ip> / Ports: port 4048 / Protocol: UDP / Forwarding Method: SNAT]
• Click "Update"
• Add the real servers - click on Cluster Configuration -> Layer 4 - Real Servers
• Click on “ Add a new Real Server “ at the end of the L4-FPP-DDP row
• Enter the details for the Real Server [Label: RIP-FPP-Master1-4048 / Real Server IP Address: <real server IP> / Real Server Port: 4048 / Weight: 100 / Minimum Connections: 0 / Maximum Connections: 0]
• Click "Update"
• Cluster Configuration -> Layer 4 - Virtual Services
• Click “ Modify “ next to L4-FPP-DDP
• Scroll down to the Fallback Server section
• Enter the details for the second real server [IP Address: <secondary Real server IP> / Port: 4048 ]
• Click "Update"

At this point I just need to do this again for the other two services and then I'm done.

Now if I head back to the System Overview tab you'll see the new services up and running:

Now, similar to the WebUI, I'm utilizing a single Primary Real Server; however, I've configured a service to automatically failover and direct traffic to the Secondary Real Server only if the first one becomes unavailable.

It's Christmas!

Really apart from being a lot of fun, the main takeaway here is that no matter what you're trying to load balance, it's highly likely someone at Loadbalancer.org can help you with the use case you're looking at — no matter how weird and wacky! In fact, the weirder the better...

And if you've got this far and would like to reward my efforts with a donation to a vitally important charity, Bliss, that supported me and my family when my girls were born, you can do so here:

Donate to Bliss: For babies born premature or sick

Every donation, no matter the size, is deeply appreciated, especially during the Christmas season when some families are going through impossibly though times.

Ho, ho, ho and Merrrrry Christmas from all of us here at Loadbalancer!!

While a single MariaDB server might suffice for your application's backend, a MariaDB Galera Cluster offers significant advantages, making it a far superior solution — because it's a true multi-master topology.

And, unlike a traditional MySQL replicated database, you don't have to separate reads from writes at the application layer.

So let's explore how to build one. And more importantly why you need to use a load balancer with it!

A variation of this setup was even part of my technical interview for Loadbalancer.org, so it's a solution close to my heart  ; ).

Table of contents

• What is a MariaDB Galera Cluster
• Why would you need a Galera cluster rather than a simple database
• MariaDB cluster use case
• Bare metal lab configuration
• Prerequisites on all systems
• How to load balance MariaDB with Ldirectord using Layer 4 DR
• How a Loadbalancer appliance can make this process a lot easier

What is a MariaDB Galera Cluster?

MariaDB is an open-source relational database management system (RDBMS), frequently utilized as a high-availability synchronous replication solution. It is also a highly compatible and enhanced fork of MySQL.

At its heart, Galera is a multi-primary cluster for MariaDB, offering features like Active-Active topology, read/write on any node, true parallel replication with automatic membership, and node joining with an emphasis on the native MariaDB experience.

MariaDB Galera Cluster advantages

MariaDB is one of the most popular database servers worldwide for good reason, providing:

1. True multi-master topology
2. No data loss when nodes crash
3. Data replicas remain consistent
4. No complex and time-consuming failovers
5. Parallel transaction execution on all cluster nodes
6. No slave lag
7. No lost transactions
8. Reads/writes scalability
9. Smaller client latencies
10. Support of multi-cloud and multi-region deployments

More information on the MariaDB Galera cluster.

Why would you need a Galera cluster rather than a simple database?

The need for highly available synchronous replication in database servers is paramount for mission critical workloads where data loss is unacceptable.

Unlike asynchronous replication, which confirms a transaction commit before changes are propagated to replicas, synchronous replication ensures that a transaction is only considered complete once it has been successfully written to both the primary server and at least one secondary replica.

This commit-acknowledgment from the replica guarantees zero data loss during a failover event, offering the highest level of data integrity and consistency. While this method can introduce slightly higher latency due to the wait time for replica confirmation, the guarantee of business continuity and data protection is a vital trade-off, making it essential for applications requiring maximum fault tolerance and reliability.

But don't forget that your Galera cluster still needs load balancing!

MariaDB cluster use case

The MariaDB Galera Cluster ensures high availability with built-in disaster recovery through synchronous multi-master replication.

It's ideal for active-active setups, providing strong consistency and automatic failover which makes it perfect for critical applications needing continuous uptime.

And when paired with an HA (High Availability) pair of Loadbalancer appliances, you have a truly impressive setup for data storage.

Bare metal lab configuration

After deploying your Ubuntu 25.04 LTS machines, make sure that these are all up to date:

Prerequisites on all systems

Right! Let's get to it.

Run updates

Make sure the system is up to date:

sudo apt update && sudo apt upgrade -y 

Prepare the data drive

Identify the second drive:

lsblk

In my case the new data drive will be /dev/sdb.

Next create the file system on the new drive, WARNING this will erase the drive.

sudo mkfs.ext4 /dev/sdb

Now create a temporary mount point and mount the drive:

sudo mkdir /data

Get the UUID of the new drive:

sudo blkid /dev/sdb

Configure auto mounting:

sudo nano /etc/fstab

Close nano with Ctrl + X, Y to save the modified buffer and enter to the file name.

Reload the fstab config:

sudo systemctl daemon-reload

Configure the system Firewall

We will now configure the UFW (Ubuntu):

sudo ufw app list        # Find a list of apps that can be allowed thougt the firewall
sudo ufw allow <apps found above> # run this command for each app found
sudo ufw allow 3306/tcp  # MariaDB client connections
sudo ufw allow 4567/tcp  # Galera replication (multicast and unicast)
sudo ufw allow 4567/udp  # Galera replication (multicast)
sudo ufw allow 4568/tcp  # Incremental State Transfer (IST)
sudo ufw allow 4444/tcp  # State Snapshot Transfer (SST)
sudo ufw enable          # If firewall is not already enabled
- Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
sudo ufw reload

Install MariaDB and Galera

If using Ubuntu 24.04 LTS and older ONLY, configure the Ubuntu server for the MariaDB and Galera repo:

sudo apt update

sudo apt install dirmngr software-properties-common apt-transport-https ca-certificates curl -y

curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash

sudo apt update

Install MariaDB and Galera:

sudo apt install mariadb-server mariadb-client galera-4 -y

Secure the MariaDB installation:

 sudo mariadb-secure-installation

For the lab, I will use the following:

• Enter current password for root (enter for none): enter
• Switch to unix_socket authentication [Y/n]: n
• Change the root password? [Y/n]: n
• Remove anonymous users? [Y/n]: y
• Disallow root login remotely? [Y/n]: y
• Remove test database and access to it? [Y/n]: y
• Reload privilege tables now? [Y/n]: y

Allow MariaDB to listen to requests from the network (or Loadbalancer appliance):

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

Edit it with the following:

Find: 
bind-address            = 127.0.0.1
and change it to
bind-address            = 0.0.0.0

Tell MariaDB to use the new data drive

At this point we need to move MariaDB’s file to the new drive.

Copy MariaDB’s file to the new drive:

sudo systemctl stop mariadb
sudo rsync -avP /var/lib/mysql/ /data/mysql

Tell MariaDB to use the new storage location:

sudo nano /etc/mysql/mariadb.conf.d/99-custom-datadir.cnf

And add the following to the file:

[mysqld] 
datadir=/data/mysql

Configure AppArmor for the new MariaDB data drive

Edit the AppArmor config:

sudo nano /etc/apparmor.d/tunables/alias

Add the following to the bottom of the file:

alias /var/lib/mysql/ -> /data/mysql/,

Close nano with Ctrl + X, Y to save the modified buffer and enter to the file name.

Reload AppArmor:

sudo systemctl reload apparmor

Configure each cluster node

The following config needs to be placed in the following location on each node in the cluster: /etc/mysql/conf.d/galera.cnf

[mysqld]
# Basic MariaDB settings
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0 # Binds to all network interfaces. Adjust if you have a specific private IP for cluster traffic.

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so # Adjust path if different (e.g., /usr/lib64/galera-4/libgalera_smm.so)

# Galera Cluster Configuration
wsrep_cluster_name="my_galera_cluster" # A unique name for your cluster

# IP addresses of ALL nodes in the cluster, comma-separated.
# Use private IPs if available for cluster communication.
wsrep_cluster_address="gcomm://node1_ip_address,node2_ip_address,node3_ip_address"

# This node's specific configuration
wsrep_node_name="node1" # Must be unique for each node (e.g., node1, node2, node3)
wsrep_node_address="node1_ip_address" # This node's own IP address

• wsrep_cluster_name = A unique name for your cluster
• wsrep_cluster_address = List the IP addresses of all nodes in the cluster on every node
• wsrep_node_name: Must be unique for each node (e.g., node1, node2, node3)
• wsrep_node_address: Set to the specific IP address of the node you are configuring.

Start or bootstrap the cluster

Node 1: Bootstrap the cluster

sudo galera_new_cluster
sudo systemctl status mariadb

Join Node 2 and 3: Start the other nodes one at a time

sudo systemctl start mariadb
sudo systemctl status mariadb

Test the cluster

Check the cluster size:

sudo mariadb -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

The output should show 3.

Test replication

On node 1 create a test database:

sudo mariadb -e "CREATE DATABASE galera_test;"

On each of the other nodes check that the database now exists:

sudo mariadb -e "SHOW DATABASES LIKE 'galera_test';"

Create a test user with remote access

Login to MariaDB as the root user:

Sudo mariadb -u root -p 

Note, you will be asked for the root user password twice.

Next, create the new remote user — as this is for testing only I've used basic settings and allowed access from every device on the network.

Basic for testing only 
CREATE USER 'testuser'@'%' IDENTIFIED BY 'TestPassword';

A secure way 
CREATE USER '<username or random string>'@'<IP of system connecting in>' IDENTIFIED BY '<Secure Password>';

Grant user permission to the database.

As this is for testing only I've used basic settings and allowed access from every device on the network to every database:

Basic for testing only
GRANT ALL ON *.* TO 'testuser'@'%' IDENTIFIED BY 'TestPassword' WITH GRANT OPTION;

A secure way 
GRANT ALL ON <Database Name>.* TO '<username or random string>'@'<IP of system connecting in>' IDENTIFIED BY '<Secure Password>' WITH GRANT OPTION;

Finally flush the privileges table and close the connection:

FLUSH PRIVILEGES;
EXIT;

Now, you're ready to start load balancing!

How to load balance MariaDB with Ldirectord using Layer 4 DR mode

Why load balance a Maria Galera Cluster?

Before we start configuring the load balancer, I thought it might be worth saying a few words about why we're bothering to load balance a MariaDB Galera Cluster, even though Galera itself offers synchronous multi-master replication (meaning all nodes are technically masters and can accept reads and writes).

The bottom line is that load balancing is essential to translate the cluster's high-availability and multi-master capabilities into a robust, single-point-of-access solution for your application.

To put it another way, while Galera Cluster provides the database backbone for high availability and redundancy, a load balancer provides the necessary intelligence and resilience to manage client connections and traffic flow effectively, ensuring the application can fully benefit from the cluster's capabilities.

Now we've reminded ourselves of the 'why', let's move onto the 'how'...

Load balancing prerequisites

For this section we will use a single Ubuntu 24.04 with LVS kernel based load balancing managed by the Ldirectord daemon, for information on how to do this with the Loadbalancer.org appliance please see the section below: "How a Loadbalancer appliance can make this process a lot easier".

First deploy a Ubuntu 24.04 server with the following spec (Test lab only):

Getting the system ready

Update the system and install the required software:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ldirectord ipvsadm

Configure IP forwarding and make it permanent:

sudo sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/90-ip-forward.conf

Configure Ldirectord for LVS maintenance and health checks

We'll now configure ldirectord to balance the connection to our MariaDB cluster in a Round Robin using Layer 4 DR mode. This mode is built for speed and offers the highest performance and lowest latency compared to other Layer 4 or Layer 7 load balancing methods. See this blog for "Why we love DR mode".

Edit the config file:

sudo nano /etc/ha.d/ldirectord.cf

Add the following to the new file:

#Global settings
checktimeout=3
checkinterval=5
autoreload=yes
logfile="/var/log/ldirectord.log"
quiescent=no

#Virtual Server for MariaDB Galera Cluster
virtual=<Floating IP>:3306 
   #Real servers using Driect Routing (gate)
   real=<Real IP node 1>:3306 gate 100
   real=<Real IP node 2>:3306 gate 100
   real=<Real IP node 3>:3306 gate 100
   scheduler=wrr
   protocol=tcp
   checktype=connect
   checkport=3306

Configuring the floating IP

Get the name of the network adapter:

sudo ip a

In my case, the interface I'll use is ens33.

Add the floating IP to the network adapter:

sudo ip addr add <Floating IP>/24 dev <Adapter Name>

Start Ldirectord and make it autostart:

sudo systemctl start ldirectord
sudo systemctl enable ldirectord

Solving the ARP Problem

As we are using Ubuntu on the real servers, we will solve the ARP Problem on them as follows.

On each node in the MariaDB Galera carry out the following steps.

First SSH to the node, get the name of all network adapter on the system:

sudo ip a

Edit the new conf file:

sudo nano /usr/lib/sysctl.d/50-default.conf

Add the following to the 50-default.conf, updating the interface name to match what your system has:

net.ipv4.conf.all.arp_ignore=1 
net.ipv4.conf.eth0.arp_ignore=1 
net.ipv4.conf.eth1.arp_ignore=1 
net.ipv4.conf.all.arp_announce=2 
net.ipv4.conf.eth0.arp_announce=2 
net.ipv4.conf.eth1.arp_announce=2
net.ipv6.conf.lo.dad_transmits=0 
net.ipv6.conf.lo.accept_dad=0

Apply the setting to the node:

sudo sysctl --system

Add the floating IP to each nodes loopback adapter:

sudo ip addr add dev lo <Floating IP>/32

And confirm that it has been added:

sudo ip a

At this point you should have a working MariaDB Galera Cluster with traffic running through a Pure Ldirectord load balancer in DR mode.

This can be tested by pointing a system that has MariaDB (MYSQL) command line tools, or the MYSQL Workbench Community tool installed at the floating IP address.

However, here’s the good news. There is actually a much simpler way to doing all this!

How a Loadbalancer appliance can make this process a lot easier

You almost certainly want a high-availability pair of load balancers, a graphical interface, and built in monitoring and logging tools.

And, because the Layer 4 component of the Loadbalancer.org appliance is actually based on LVS and Ldirectord, you can even get help migrating your current open source configuration.

Here's how to do it.

First, log in to your active primary node.

Next, navigate to Cluster Configuration -> Layer 4 - Virtual Services
and click “Add a new Virtual Service".

Now we need to give to give the new virtual service some details like:

• Label: make it something meaningful - MariaDBGaleraCluster_VIP
• IP Address: this is the floating IP address - 10.30.89.65
• Ports: this is the MariaDB Port number - 3306
• Protocol: leave this as TCP
• Forwarding Method: set this to Direct Routing

Now click “Update“ to create are new Virtual Service:

Next, let's add some Real Servers. Click on “Layer 4 - Real Servers" in the side menu and then click on “Add a new Real Server“ button next to our newly created Layer 4 service (repeat this step for all the nodes in the MariaDB Galera Cluster).

We then need to give the new Real Server some details like:

• Label: make it something meaningful like the real servers name - MDB-Node-1_RIP
• Real Server IP Address: this is the IP of the real server in the MariaDB Galera cluster
• Weight: can be left at 100
• Minimum Connection: can be left at  0 for not set
• Maximum Connection: can be left at  0 for not set

Now click “Update" to add this Real Server to the new Virtual Service.

After solving the ARP Problem as described above, you should have a working a working MariaDB Galera Cluster with traffic running through our Loadbalancer.org appliance in DR mode.

This can be tested by pointing a system that has MariaDB (MYSQL) Command line tools or MYSQL Workbench Community tool installed at the floating IP address.

Bonus item: Let's make it even better!

Ok, so who doesn't like a bonus item?! Let's make the monitoring of the MariaDB Galera cluster even better with the Loadbalancer.org appliance.

At the moment our Virtual Service is only checking that the nodes in the cluster are switched on and responding to a connection on port 3306.

So let's make the load balancer log in to each node in the cluster and ensure it's accepting the log in (rather than just checking that MariaDB is up and running).

If your cluster is hosting just a single database, then using this database for monitoring would be a good approach. However, if your cluster is hosting multiple databases or you have security concerns, it’s worth setting up a database just for the check to work against — the approach we'll take with this next part of the blog...

Getting the MariaDB Galera Cluster ready

So at this point there are two ways to create the required data and users:

1. You can either do it with the MYSQL Workbench; or
2. (like I will show you here) via the command line.

The first thing you will need to do is SSH to each node in the cluster.

On any node in your cluster login to MariaDB with the root account (or a user that has admin privileges):

sudo mariadb -u root -p
- OR -
mariadb -u <adminuser> -p

Remember, if using the root account you could be asked to login in twice.

Create a new database called “ healthcheckdb “ and check it was created:

CREATE DATABASE healthcheckdb;
SHOW DATABASES;

You should see the new database in the list.

Next we need to create a table that we can use to check and a dummy data in it:

USE healthcheckdb;
CREATE TABLE device_checks ( check_id INT AUTO_INCREMENT PRIMARY KEY, check_device VARCHAR(255) NOT NULL );
INSERT INTO device_checks (check_device) VALUES ('Loadbalancer 1'), ('Loadbalancer 2');
SELECT * FROM device_checks;

Now let's create two new users one for each of our loadbalancer as we are going to restrict access to the load balancer’s base IP address:

CREATE USER 'loadbalancer-hc'@'<IP of system connecting in>' IDENTIFIED BY '<Secure Password>';

Let's check that the new user got created:

SELECT User, Host FROM mysql.user;

Give users access to the database:

GRANT SELECT ON healthcheckdb.* TO 'loadbalancer-hc'@'<IP of system connecting in>' IDENTIFIED BY '<Secure Password>';

Let's check that the new user permissions got set:

SELECT User, Host, Select_priv, Insert_priv, Update_priv, Delete_priv Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Grant_priv, Alter_priv, Super_priv FROM mysql.user WHERE User = 'loadbalancer-hc';

SHOW GRANTS FOR 'loadbalancer-hc'@'<IP of system connecting in>';
SHOW GRANTS FOR 'loadbalancer-hc'@'<IP of system connecting in>';

If you would like to test the other nodes in the cluster to see if what we have done has replicated here are a set of commands you can use:

sudo mariadb -e "SHOW DATABASES;"

sudo mariadb -e "SELECT User, Host FROM mysql.user;"

sudo mariadb -e "SELECT * FROM healthcheckdb.device_checks;"

sudo mariadb -e "SELECT User, Host, Select_priv, Insert_priv, Update_priv, Delete_priv Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Grant_priv, Alter_priv, Super_priv FROM mysql.user WHERE User = 'loadbalancer-hc';"

sudo mariadb -e "SHOW GRANTS FOR 'loadbalancer-hc'@'<IP of system connecting in>';"
sudo mariadb -e "SHOW GRANTS FOR 'loadbalancer-hc'@'<IP of system connecting in>';"

Configure the load balancer

Configure the Loadbalancer.org appliance Layer 4 virtual service to use the new database for health checks.

Go to Cluster Configuration -> Layer 4 - Virtual Services and click "Modify" next to our "MariaDbGaleraCluster" entry:

Next scroll down the page and find the "Health Checks" section change the "Check Type" to "Negotiate":

• Check Port: can be left blank as we are using the default MariaDB port on the real servers
• Protocol: can be left set to - MySQL (IPv4 only)
• Database Name: healthcheckdb
• Login:  loadbalancer-hc
• Password: the secure password created in MariaDB
• Request to send:  SELECT * FROM healthcheckdb.device_checks

But wait. Oh no, my Virtual service is down?!

So after making this change you might find that the "System Overview" page shows your MariaDBGaleraCluster service as being down:

There are two possible reasons this may of happened:

1. MariaDB could be blocking the connection; or
2. A value has been incorrectly used.

To fix this, let's try first of all resetting the block on MariaDB...

On one of the MariaDB Galera nodes run the following command

sudo mariadb-admin flush-hosts

And, if that was the fault, your MariaDBGaleraCluster virtual service will come back online and recover:

If this doesn't work then don't worry, just go back over each step to make sure all the details are correct.

As a final point you will need to failover to the other node and check that the health check is working from there as well.

Log on to your secondary node and click on "[Advanced]", then click on the "Take over" button and OK the popup to take over:

Now we just need to wait a couple of minutes to make sure that the health checks are passing. This is a good time to run some test traffic through the load balancer to the cluster.

Then the final stage is to fail back over to the primary load balancer.

Back on the primary node (you might need to refresh the page) click "[Advanced]", then click on the “Take over “ button and OK the pop-up to take over.

Are LVS and Ldirectord the right solution for an HA MariaDB Galera Cluster?

LVS and Ldirectord are a GREAT solution if you're looking for a high-performing, highly available MariaDB Galera cluster.

But, as with most open source tools, you need to make sure that you design and configure you're environment correctly.

In this brief 'how-to' guide I've covered most of the issues. But what I haven't covered is disaster recovery, backup, or an open source HA solution for the load balancer itself (it needs to be HA because you'll definitely want two of them to avoid a single point of failure)!

If you're only after open source HA and want to take this further yourself, then I recommend you take a look at Keepalived.

However, it's an awful lot easier to achieve the desired solution with the help of a commercial vendor who's not only done this before, but also understands the underlying open source technologies that you've been struggling with.

Either way, you still need a decent load balancer to keep your database cluster working smoothly. And that is something we can definitely help with.

AWS experienced significant challenges this week when a failure in a single US-EAST-1 region triggered a widespread outage, ultimately disrupting a substantial portion of our global digital infrastructure.

But now the dust has settled, what can we actually learn from this disaster so it makes it a little less painful for everyone involved next time round?

The wake-up call

On October 20, 2025, a massive AWS outage disrupted services for millions of users worldwide. It began shortly after 3 am and was caused by an issue with a core database product designed to monitor network load. This failure took down services for a wide array of companies, including Snapchat, Roblox, major banks, and healthcare providers. Services didn't fully recover until Monday evening.

The impact was staggering. Outage monitor Downdetector indicated there had been more than 6.5 million reports globally, with upwards of 1,000 companies affected. Banking apps stopped working, gamers couldn't access their platforms. Even Amazon's own internal systems went dark, leaving warehouse workers standing idle.

But here's the critical question:

Why did businesses that were supposedly using AWS's 'highly available' infrastructure experience downtime?

The myth of cloud infallibility

Many organizations believe that deploying their applications to AWS automatically means they're protected from outages. After all, each AWS region consists of a minimum of three isolated and physically separate availability zones (AZ), each with independent power and connected via redundant, ultra-low-latency networks. Customers are encouraged to design applications to run in multiple AZs.

But during yesterday's outage, even businesses spread across multiple availability zones within the US-East region experienced downtime. Why? Because they were all dependent on centralized services.

The problem is that even if European regions were unaffected in terms of their own availability zones, dependencies on infrastructure or control-plane features located in US-EAST-1 could still cause knock-on impact. Critical services like IAM, account management, and some control APIs are served from US-EAST-1, regardless of where your workloads run.

The hidden single point of failure

The real vulnerability isn't just having resources in one availability zone—it's about having all your eggs in one regional basket. When a foundational service like DynamoDB in a single region experiences issues, the blast radius can be enormous!

And this isn't an isolated incident. Major internet outages are becoming more frequent (and costly), driven by growing reliance on digital infrastructure and the concentration of services among a few dominant cloud providers. The number of significant incidents has surged from just a handful in the 1960s and 1970s to over 80 in the first half of the 2020s.

True multi-AZ architecture: Beyond the basics

This is where proper load balancing architecture becomes critical. It's not enough to simply deploy EC2 instances across multiple availability zones and hope for the best. You need intelligent traffic management that can:

1. Actively monitor service health across all availability zones
2. Automatically reroute traffic when an AZ experiences degradation
3. Maintain session persistence during failover events
4. Provide independent control planes that don't rely on centralized services

The Loadbalancer.org solution

Thankfully, Loadbalancer.org's Enterprise AWS solution offers a sophisticated approach to multi-AZ resilience that goes beyond basic AWS load balancing.

Let's explore how it works.

Dual Availability Zone (AZ) deployment

The Enterprise AWS appliance supports a deployment model specifically designed for true multi-AZ resilience. Like so:

Primary 1 and Primary 2 configuration

• Two load balancer instances are deployed, each in a different availability zone
• Each instance has its own Virtual IP (VIP) that is locally active
• Only one VIP is made available via an associated Elastic IP (EIP) at any given time
• Regular health checks monitor the EIP availability across both zones

What happens during an AZ failure?

• If the availability zone hosting the active EIP association fails, the peer instance in the healthy AZ automatically detects the failure
• The EIP is reassociated with the VIP on the healthy instance
• Traffic continues to flow to available backend servers
• No manual intervention required

Independent backend servers across AZs

The real power of this architecture becomes apparent when you distribute your backend infrastructure:

Primary 1 (AZ-1) → Manages traffic to:
  ├─ Server 1 (AZ-1)
  ├─ Server 2 (AZ-1)
  ├─ Server 3 (AZ-2)
  └─ Server 4 (AZ-2)

Primary 2 (AZ-2) → Manages traffic to:
  ├─ Server 1 (AZ-1)
  ├─ Server 2 (AZ-1)
  ├─ Server 3 (AZ-2)
  └─ Server 4 (AZ-2)

Under normal circumstances, whether the EIP is associated with Primary 1 or Primary 2, all four backend servers remain available. But if AZ-1 completely fails:

• Primary 1 becomes unreachable
• Servers 1 and 2 in AZ-1 become unavailable
• Primary 2 automatically associates the EIP with its VIP
• Services continue via Servers 3 and 4 in AZ-2
• Your application remains online with 50% capacity instead of 0%

Advanced health checking

The health checking mechanism is sophisticated and configurable:

• Check interval: Customizable monitoring frequency (default settings balance responsiveness with stability)
• Failure count: Requires multiple consecutive failures before triggering failover (default: 2) to avoid false positives from transient network issues

This prevents the "flapping" problem where services bounce back and forth between zones due to temporary network hiccups.

Automatic routing table updates

For Layer 4 NAT mode or Layer 7 transparent proxy configurations, the solution can automatically update AWS routing tables during failover. This ensures that return traffic always flows back through the active load balancer, maintaining connection integrity.

The failover script capability allows you to execute AWS CLI commands automatically:

aws ec2 replace-route --route-table-id rtb-xxxxx \
--destination-cidr-block 0.0.0.0/0 \
--instance-id i-xxxxx --region us-east-1

This level of automation means your infrastructure adapts to failures without human intervention.

The control plane advantage

Unlike native AWS load balancing services that can be affected by control plane issues in US-EAST-1, Loadbalancer.org appliances have their own independent control plane. Each appliance operates autonomously, making its own decisions about traffic routing based on local health checks and configurations.

This independence is crucial. During yesterday's outage, Amazon confirmed that the outage impacted AWS customer support operations, meaning customers couldn't even report problems through the automated support system. With an independent control plane, your load balancers continue functioning and making intelligent routing decisions even when AWS's centralized services are degraded.

Beyond AWS: True multi-cloud resilience

For organizations requiring the highest levels of availability, Loadbalancer.org's Global Server Load Balancing (GSLB) capability enables multi-region and even multi-cloud architectures.

With it, you can:

• Balance traffic between AWS regions (e.g., US-EAST and EU-WEST)
• Implement geographic load balancing for performance optimization
• Create failover relationships between AWS and other cloud providers
• Maintain full control over traffic distribution policies

This approach addresses the broader issue identified during the outage: A single cloud is a single point of failure. Spreading workloads across cloud service providers ensures connectivity during an outage.

The cost of downtime vs. the cost of resilience

Let's talk about the elephant in the room: cost. Yes, running resources in multiple availability zones increases your infrastructure spend. But consider the alternative.

The July 2024 CrowdStrike incident cost Fortune 500 companies an estimated $5 billion in direct losses. Yesterday's AWS outage affected banking services, healthcare enrolment systems, airline operations, and countless e-commerce platforms. The financial impact of multi-hour downtime far exceeds the additional monthly cost of true multi-AZ architecture.

And our Enterprise AWS licensing is flexible:

• Pay-As-You-Go (PAYG): Hourly billing for complete cost control
• Annual subscription: 15% savings for long-term deployments
• Bring-Your-Own-License (BYOL): Perpetual licensing with the Freedom License that allows migration between platforms

The investment in proper load balancing infrastructure provides insurance against events like yesterday's outage.

Implementation: Easier than you think

Deploying a multi-AZ resilient architecture with Loadbalancer.org is straightforward:

1. Deploy two Enterprise AWS instances in different availability zones
2. Configure synchronization between Primary 1 and Primary 2 (automated via WebUI)
3. Set up corresponding VIPs on both instances pointing to your backend servers
4. Associate Elastic IPs with both instances using AZ HA mode
5. Configure health check parameters to match your application requirements
6. Test failover to validate the setup

The entire process can be completed in under an hour for most deployments. The WebUI provides clear, intuitive configuration options that don't require deep networking expertise.

Real-world use cases

This architecture is battle-tested across multiple industries:

• Financial services: Banks and payment processors can't afford downtime. Multi-AZ load balancing ensures transaction processing continues even during regional disruptions.
• Healthcare systems: Patient care systems using protocols like DICOM and HL7 require constant availability. Geographic distribution protects against localized failures.
• E-Commerce platforms: Shopping cart abandonment costs are measured in millions. Maintaining uptime during traffic spikes and infrastructure issues directly impacts revenue.
• Gaming platforms: Player experience is paramount. Connection stability across AZs maintains engagement even when individual zones experience issues.

Monitoring and visibility

You can't manage what you can't measure. The Enterprise AWS solution provides comprehensive visibility:

• Real-time EIP status showing which instance currently holds each EIP association
• Health check history revealing patterns in backend server availability
• Traffic statistics across both load balancer instances
• Automated alerts for failover events

This visibility enables proactive management and helps you understand exactly how your infrastructure behaves during normal operations and failure scenarios.

Lessons learned

One AWS expert predicted significant outages in 2024 based on increasing Large Scale Events, though they discounted the power of inertia. The pace of senior AWS departures and increasing complexity makes future outages inevitable.

The question isn't 'if' your cloud provider will experience another major outage—it's 'when', and 'will your business survive it'?

Take action now

Yesterday's outage was a reminder that even the most sophisticated cloud infrastructure has vulnerabilities. Organizations that invested in proper multi-AZ architecture with independent load balancing continued serving their customers while others went dark.

The Enterprise AWS solution from Loadbalancer provides the resilience layer that AWS alone cannot guarantee. With independent control planes, sophisticated health checking, automated failover, and support for multi-region and multi-cloud architectures, it's the insurance policy your business needs.

Don't wait for the next outage to expose gaps in your architecture. The best time to implement true multi-AZ resilience was yesterday. The second-best time is today.

In a nutshell (TL;DR)

1. Single-AZ deployments are unacceptable for production workloads requiring high availability
2. Multi-AZ within a single region isn't enough if centralized control plane services can fail
3. Intelligent load balancing with independent health checking is essential
4. Automated failover must work without relying on potentially affected AWS services
5. Regular testing of failover scenarios ensures your architecture performs when needed

The cybersecurity community was shaken last week when F5 disclosed that a highly sophisticated nation-state threat actor had maintained long-term, persistent access to its network and exfiltrated files containing portions of BIG-IP source code and information about undisclosed vulnerabilities.  

As engineers in the load balancing space, this incident demands our attention—not just because it affects a major competitor, but because it highlights vulnerabilities that could impact the entire infrastructure security ecosystem.

How the F5 breach unfolded

The state-backed hackers broke into F5's systems in late 2023 and remained undetected until being discovered in August 2025—that's more than 12 months. Scary stuff.

F5 themselves learned of the breach on August 9, 2025, but delayed public disclosure at the request of the U.S. Department of Justice for obvious reasons.

The breach has been attributed to state-backed hackers from China, with Bloomberg reporting that the intrusion involved the use of a malware family dubbed BRICKSTORM, which is attributed to a China-nexus cyber espionage group tracked as UNC5221.

What was compromised

The scope of the breach is particularly concerning for a number of reasons:

• Source code theft: Attackers stole source code from F5's BIG-IP suite of products and information about undisclosed vulnerabilities.
• Long-term access: The threat actors had access to F5's product development environment and engineering knowledge management platforms.
• Intelligence advantage: CISA warned that the nation-state affiliated cyber threat actor's exfiltration of BIG-IP proprietary source code and vulnerability information provides the actor with a technical advantage to exploit F5 devices and software.

The immediate response

The severity of this breach triggered an unprecedented government response.

CISA issued Emergency Directive 26-01, requiring Federal Civilian Executive Branch agencies to apply the latest vendor-provided updates for at-risk F5 virtual and physical devices by October 22, 2025. CISA characterized the threat as posing an imminent risk, with the potential for threat actors to exploit vulnerabilities in F5 products. And using them to gain unauthorized access to embedded credentials and API keys, move laterally within organizations' networks, exfiltrate sensitive data, and establish persistent system access.

Scale of the F5 exposure

The numbers paint a sobering picture of the potential attack surface:

• Cortex Xpanse identifies over 600,000 F5 Big-IP instances exposed to the internet.
• Shadowserver Foundation tracked more than 266,000 F5 BIG-IP instances exposed online.
• Figures from Palo Alto Networks suggest that more than 600,000 F5 network security devices running BIG-IP software are unpatched and potentially vulnerable.

F5 critical vulnerabilities disclosed

F5 have subsequently released patches for several high-severity vulnerabilities, including:

• CVE-2025-53868: A BIG-IP SCP and SFTP vulnerability with a CVSS score of 8.7.
• CVE-2025-61955: An F5OS vulnerability with a CVSS score of up to 8.8 in appliance mode.
• CVE-2025-57780: An F5OS vulnerability with a CVSS score of up to 8.8 in appliance mode.

Key lessons for the industry

As infrastructure providers at Loadbalancer.org, this incident reinforces several critical security principles:

1. Defense in depth security is non-negotiable

A year-long breach demonstrates that perimeter security alone is insufficient. Organizations need robust internal segmentation, continuous monitoring, and assume-breach mentality.

2. Supply chain security matters

F5's BIG-IP suite is commonly used by large organizations, primarily in the U.S. but also globally, for availability, access control and security, with government agencies and Fortune 500 companies relying on BIG-IP. When infrastructure providers are compromised, the downstream impact can be catastrophic.

3. The risks of single-vendor dependency

This breach highlights a critical vulnerability that many organizations overlook: single-vendor dependency. When your entire load balancing infrastructure relies on a single vendor's architecture, a compromise of that vendor's systems can expose your entire fleet to coordinated attacks.

The theft of BIG-IP source code means attackers now have intimate knowledge of the platform's inner workings, potentially enabling them to develop zero-day exploits that could compromise entire F5 deployments simultaneously. Organizations running homogeneous F5 environments face a particularly acute risk. If attackers develop an exploit chain, they could potentially compromise the entire infrastructure at once.

4. Zero trust architecture is essential

The year-long breach underscored the need to shift to zero trust adoption. Traditional network perimeters are no longer sufficient against sophisticated nation-state actors.

5. Patch management is critical

The hundreds of thousands of unpatched F5 devices exposed to the internet represent a massive attack surface. Organizations must prioritize timely patching, especially for internet-facing infrastructure.

6. Threat detection capabilities must evolve

The fact that sophisticated attackers maintained access for 12 months undetected highlights the need for advanced threat detection, behavioral analytics, and continuous security monitoring.

The security case for multi-vendor architecture

In cybersecurity, monoculture is dangerous. Just as agricultural monocultures are vulnerable to single diseases that can wipe out entire crops, technology monocultures create systemic risk. When every load balancer in your infrastructure runs the same codebase, a single vulnerability or exploit can compromise your entire application delivery tier.

A mixed-vendor approach provides several security advantages:

• Reduced blast radius: A vulnerability in one vendor's platform doesn't expose your entire infrastructure
• Architectural diversity: Different code bases mean different attack surfaces, making it exponentially harder for attackers to develop universal exploits
• Resilience against vendor compromise: Even if one vendor suffers a breach like F5's, your alternative platforms remain secure
• Defense against zero-days: Attackers would need multiple zero-day exploits to compromise a heterogeneous environment
• Business continuity: If one vendor faces extended security incidents requiring device isolation, you can shift traffic to alternative platforms

How Loadbalancer.org solutions address these challenges

At Loadbalancer.org, we've built our products with these exact scenarios in mind. Two of our solutions are particularly relevant in light of the F5 breach:

The ADC Portal: Unified visibility and vulnerability management

Managing a multi-vendor infrastructure can be complex, but that complexity shouldn't compromise security. The ADC Portal provides centralized management and monitoring across your entire load balancing fleet, including F5 devices alongside Loadbalancer appliances.

Key capabilities for security management

• Unified Dashboard: Monitor all your load balancers from a single pane of glass, regardless of vendor
• Vulnerability Tracking: Stay on top of CVEs and security advisories across your entire fleet with centralized vulnerability management
• Patch Status Monitoring: Quickly identify which devices are running outdated firmware or missing critical security patches

In the wake of the F5 breach, organizations with Portal deployed would have immediate visibility into which F5 devices required patching, their current firmware versions, and could prioritize remediation efforts based on exposure and risk.

Loadbalancer.org Enterprise GSLB: Multi-Vendor Global Load Balancing

One of the most powerful security strategies is architectural diversity. The Loadbalancer Enterprise features advanced Global Server Load Balancing (GSLB) that works seamlessly across multiple vendor platforms, enabling true multi-vendor resilience.

Strategic security benefits

• Vendor-Agnostic Architecture: Deploy GSLB across Loadbalancer.org appliances, F5 devices, and other vendor platforms simultaneously
• Intelligent Traffic Distribution: Automatically route traffic away from compromised or vulnerable platforms during security incidents
• Zero-Trust Traffic Steering: Make real-time load balancing decisions based on security posture, not just performance metrics
• Rapid Incident Response: If a security advisory affects one vendor's platform, instantly shift production traffic to alternative infrastructure
• Geographic Distribution: Spread risk across different vendors in different data centers and cloud regions

A real-world scenario

Imagine CISA issues an emergency directive affecting your F5 fleet (as they just did). With Enterprise GSLB, you can:

1. Immediately shift critical production traffic to your Loadbalancer appliances
2. Take F5 devices offline for emergency patching without service disruption
3. Gradually restore F5 devices to production after verification
4. Maintain full redundancy throughout the incident response

This isn't theoretical. It's exactly the kind of resilience that separates organizations that survive major security incidents, from those that suffer outages and breaches.

Our commitment to security

At Loadbalancer.org, we understand that our customers trust us with their most critical infrastructure. This incident reinforces our commitment to:

• Transparent security practices: Maintaining open communication with customers about security posture and any incidents.
• Rapid response capabilities: Having incident response plans ready to detect and contain threats quickly.
• Secure development lifecycle: Incorporating security at every stage of product development.
• Regular security updates: Providing timely patches and security updates to address emerging threats.
• Interoperability by design: Building solutions that enhance rather than replace your existing infrastructure investments.

Enterprise security recommendations

If you're running load balancing or application delivery infrastructure:

1. Inventory your assets: Know exactly what devices you have exposed to the internet—Portal can automate this discovery.
2. Apply updates immediately: Don't delay critical security patches, and use centralized management to track patch status.
3. Evaluate architectural diversity: Consider whether single-vendor dependency creates unacceptable risk.
4. Implement network segmentation: Limit lateral movement opportunities for attackers.
5. Enable comprehensive logging: Ensure you can detect and investigate suspicious activity across all platforms.
6. Review access controls: Implement least-privilege access and multi-factor authentication.
7. Consider zero trust architecture: Evaluate moving toward a zero-trust security model.
8. Plan for vendor incidents: Develop runbooks for rapidly shifting traffic away from compromised platforms.
9. Deploy multi-vendor GSLB: Build resilience through architectural diversity.
10. Monitor for anomalies: Look for unusual access patterns, especially on management interfaces.

Moving forward: Building resilient infrastructure

The F5 breach serves as a stark reminder that no organization, regardless of size or security focus is immune to sophisticated nation-state attacks. F5's stock dropped 10% following the disclosure, demonstrating that security breaches carry significant business consequences.

But this incident also presents an opportunity. Organizations can emerge stronger by:

• Embracing architectural diversity as a security strategy, not just a redundancy measure.
• Deploying unified management to handle the complexity of multi-vendor environments.
• Implementing intelligent traffic steering that considers security posture in load balancing decisions.
• Building incident response capabilities that leverage multi-vendor flexibility.

The most resilient organizations don't put all their eggs in one basket. They build infrastructure that can withstand not just technical failures, but vendor compromises, supply chain attacks, and coordinated nation-state campaigns.

Conclusion

For the load balancing and infrastructure community, this incident should prompt a thorough review of security practices, patch management processes, detection capabilities, and critically vendor dependency risk.

At Loadbalancer.org, we remain committed to learning from industry incidents, continuously improving our security posture, and providing our customers with infrastructure they can trust.

Our ADC Portal and Enterprise GSLB solutions are designed specifically to help organizations build more secure, more resilient, and more manageable infrastructure. Even in a world where major vendors can be compromised.

The question isn't whether another major vendor will suffer a breach — it's whether your infrastructure can survive it.

Load balancing is a critical component of modern infrastructure, ensuring high availability and optimal performance for your applications.  

While Loadbalancer.org's Enterprise appliance provides an intuitive Web Interface for most common configurations, there are times when you need to dive deeper and implement advanced settings that aren't directly available through the standard interface.

This is where Layer 7 Manual Configuration becomes invaluable. In this comprehensive guide, I'll walk you through the process of setting up a Layer 7 Virtual Service in Manual mode, using VMware vCloud Director (VCD) as example.

Table of contents

• Understanding the architecture
• When to use Manual Configuration
• VMware Cloud Director implementation walkthrough
• The power of Global Configuration settings
• Best practice and considerations
• How to troubleshoot common errors

Understanding the architecture

Loadbalancer.org Enterprise is built on proven open-source technologies including HAProxy, Linux Virtual Server, and Apache. This foundation provides a robust platform for load balancing, content delivery, and application delivery services.

While the Web UI simplifies most configurations, manual configuration gives you access to the full power and flexibility of these underlying technologies.

When to use manual configuration

Manual configuration is particularly useful when you need to:

• Implement advanced HAProxy directives not available in the Web Interface
• Configure complex routing rules
• Set up specialized persistence mechanisms
• Integrate with applications that require specific load balancing behaviours

VMware Cloud Director implementation walkthrough

VMware's Cloud Director (VCD) is a great example to use for a Manual Config, as it presents a unique challenge due to certain configuration that are atypical for most of the HTTP-based applications.

Step 1: Create the initial Layer 7 Virtual Service

Start by creating a basic virtual service using the WebUI. This approach allows you to leverage the interface for standard settings before moving to manual configuration.

Navigation path

• Cluster Configuration → Layer 7 - Virtual Service

Configuration details

• Service Name: Choose a descriptive name like "vCloud Director"
• Virtual IP (VIP): Assign your dedicated IP address
• Port: Set to 80
• Protocol: Select HTTP

This initial setup creates the foundation that you'll later enhance with manual configuration.

Step 2: Configure Your Real Servers

Define the backend servers (VCD cells) that will handle the actual traffic.

In the Real Servers section

• Click "Add New Real Server"
• Enter the IP address of each vCloud Director cell
• Set the port to 443
• Important: Enable re-encryption since vCloud Director requires encrypted backend communication.
• Repeat for all vCloud Director cells in your environment

Step 3: Enable HTTPS and SSL offloading

SSL termination at the load balancer improves performance and simplifies certificate management.

SSL Termination Configuration

• Upload your SSL certificate and private key for the vCloud Director public hostname
• Navigate to the SSL Termination in Cluster Configuration section
• Click Add a new Virtual Service and from the Associated Virtual Service choose your vCloud Director Service
• Make sure to choose the right Certificate from the list
• This setup allows the load balancer to handle encryption/decryption, reducing computational load on your vCloud Director cells

Step 4: Configure your Layer 7 Virtual service

Now we need to make a few changes to the Layer 7 Service in order to work correctly with the vCloud Director. Navigate to Cluster Configuration → Layer 7 - Virtual Service and click “Modify” button by the name of your VIP.

Firstly,  health checking ensures traffic only reaches operational servers.

Health check setup

• Scroll down to Health Checks section
• Configure an HTTP health check targeting /api/server_status
• Leaving the expected response field empty means that we expect a valid response from the URL i.e. 200 OK
• The load balancer automatically removes failed servers from rotation

vCloud Director requires consistent session handling to prevent user disconnections.

Persistence Configuration

• Scroll down to the Persistence section
• Select "Source IP" as the persistence method
• Set Persistence Timeout to 30 minutes (adjust based on your session requirements)
• This ensures all requests from a single user session reach the same vCloud Director cell

X-Forwarded-For and Force to HTTPS (optional)

• Navigate to the Other section and click on [Advanced]
• Make sure the Set X-Forwarded-For header box is ticket
• And Force to HTTPS is set to Yes

Here's a SINGLE all-in-one screenshot which you might find useful, just in case!!!

Step 5: Extract the Current Configuration

Process

• Navigate to View Configuration → Layer 7
• Locate your newly created VIP
• Copy the entire configuration section from the initial listen <VIP name> line through the end of the Real Server definitions
• Save this configuration text for the next step

Step 6: Enable Manual Configuration Mode

Activation process

• Click "Modify" next to your VIP
• Click "[Advanced]" in the Virtual Service section
• Check the "Manual Configuration" checkbox
• Click "Update" to confirm

• Important: Once you enable manual configuration, all future changes must be made through the manual interface, not the WebUI.

Step 7: Add the required Global Configuration

Final implementation

• Navigate to Cluster Configuration → Layer 7 - Manual Configuration
• Add the essential global section at the top of your configuration:

global
    tune.bufsize 65536
    tune.http.maxhdr 256


listen vCloud_Director
    bind 10.11.20.125:80 transparent
    default-server on-marked-up shutdown-backup-sessions
    id 332527946
    mode http
    balance leastconn
    acl src_stunnel src 10.11.20.125
    tcp-request connection expect-proxy layer4 if src_stunnel
    stick on src
    stick-table type ip size 10240k expire 30m peers loadbalancer_replication
    server backup 127.0.0.1:9081 backup  non-stick 
    option httpchk GET /api/server_status HTTP/1.0
    acl :connection_via_termination always_false
    option http-keep-alive
    timeout http-request 5s
    option forwardfor
    timeout tunnel 1h
    option redispatch
    option abortonclose
    maxconn 40000
    acl force fc_rcvd_proxy
    reqadd X-Forwarded-Proto:\ https if force or :connection_via_termination
    redirect scheme https code 301 if !force !:connection_via_termination
    option httplog
    server vcloud_cell01 10.11.20.101:443 id 2  weight 100  check  check-ssl verify none inter 4000  rise 2  fall 2  slowstart 8000 minconn 0  maxconn 0  on-marked-down shutdown-sessions  ssl verify none sni req.hdr(host) sni req.hdr(host) resolve-prefer ipv4
    server vcloud_cell02 10.11.20.102:443 id 2  weight 100  check  check-ssl verify none inter 4000  rise 2  fall 2  slowstart 8000 minconn 0  maxconn 0  on-marked-down shutdown-sessions  ssl verify none sni req.hdr(host) sni req.hdr(host) resolve-prefer ipv4

• Below the global section, paste the VIP configuration copied in Step 6
• Click "Update" to apply the complete configuration

Why these Global Settings matter

• vCloud Director generates large HTTP requests and responses that exceed default HAProxy buffer sizes
• The API-heavy nature of vCloud Director requires support for numerous HTTP headers
• Without these tuning parameters, you may experience connection timeouts or dropped requests

The power of Global Configuration settings

Here's where manual configuration truly shines - adding global HAProxy settings that aren't available through the WebUI. For vCloud Director, specific tuning parameters are required to handle its communication patterns effectively.

The key requirement for vCloud Director is adding a global section with these critical tuning parameters:

global
    tune.bufsize 65536
    tune.http.maxhdr 256

These settings are essential because:

• tune.bufsize 65536: Increases the buffer size to handle vCloud Director's larger HTTP requests and responses
• tune.http.maxhdr 256: Allows for more HTTP headers, which vCloud Director uses extensively for API communications

Best practice and considerations

Before you begin

• Test in Development: Always test manual configurations in a non-production environment first
• Backup Current Config: Save your working WebUI configuration before converting to manual mode
• Plan Your Changes: Document all custom settings you'll implement

During implementation

• Incremental Changes: Make one change at a time and test functionality
• Monitor Logs: Watch HAProxy logs for any configuration errors
• Validate Syntax: Ensure HAProxy configuration syntax is correct before applying

After implementation

• Performance Monitoring: Monitor response times and connection patterns
• Health Check Verification: Confirm health checks are working as expected
• Session Persistence Testing: Verify user sessions maintain consistency

How to troubleshoot common errors

Configuration syntax errors

• Use HAProxy configuration checker tools
• Review logs in /var/log/haproxy.log
• Validate indentation and syntax formatting

Persistence problems

• Verify stick-table configuration
• Check client IP addressing (especially with proxy chains)
• Monitor session distribution patterns

Health check failures

• Confirm endpoint availability on backend servers
• Verify network connectivity between load balancer and real servers
• Check HTTP response codes and content

Conclusion

Manual Layer 7 configuration in Loadbalancer.org Enterprise unlocks powerful capabilities for complex deployment scenarios. While the Web Interface handles most common use cases efficiently, manual configuration provides access to global HAProxy settings that are essential for specific applications like vCloud Director.

The key to success lies in starting with a solid Web Interface foundation, then thoughtfully transitioning to manual mode to add the required global tuning parameters. This approach combines the ease of the graphical interface with the power of direct HAProxy global configuration.

Remember that with great power comes great responsibility – manual configuration requires deeper understanding of load balancing concepts and careful testing to ensure optimal results.

By following this guide, you'll be well-equipped to leverage the full potential of Loadbalancer.org Enterprise for even the most demanding application delivery requirements that need global HAProxy tuning.

In today's security-conscious world, logs are crucial for gaining insight into your systems. But why limit your log storage to the device that creates them?  

Centralized log aggregation allows you to collect logs from multiple sources in a single location, providing a more comprehensive view of your traffic and improving security analysis. This can be particularly beneficial for load-balanced environments, where traffic is distributed across several servers, as it helps you get a complete picture of your network activity and identify potential issues more efficiently.

Table of contents

• Why use Grafana Loki
• The Grafana, Loki and Alloy stack
• How to install Grafana
• How to install Loki
• How to install Alloy
• How to install and configure Rsyslog
• How to connect the Grafana front end to Loki
• How to do all this with a Loadbalancer appliance
• HAProxy log structure

Why use Grafana Loki?

Aggregated logging or centralized logging, is a critical practice for modern IT environments with the core use being to collect, normalize, and centralize log data from every application, server, and network device into a single, searchable platform. This single source of truth provides immense value for various teams and a wide range of operational needs.

The goods news is that we can implement a cost-effective and scalable logging solution using Loki and Grafana, which centralizes logs from all your services into a single platform, drastically reducing the time your teams spend on troubleshooting and debugging.

By using Grafana to visualize this log data, you gain real-time insights into your system's health, helping you proactively identify and fix issues before they impact your customers. In short, this technology stack will improve your operational efficiency, reduce downtime, and save money on traditional logging solutions.

Paired with our other blogs on Prometheus and displaying metrics with Grafana this information will give you a complete picture of the traffic flowing through your Loadbalancer.org appliance.

What is Granfana Loki?

Garafana Loki is a log aggregation system designed to be scalable, highly available and cost effective. It focuses on indexing metadata about log streams rather than the full body content of the logs, making it simpler and cheaper to run when compared to other logging systems. Grafana dashboards and be paired with Loki to visualise your logs and make searching them easier.

It's also worth mentioned Grafana Alloy at this point, as they work so well together.

What is Grafana Alloy?

Grafana Alloy is an open-source vendor neutral distribution of the OpenTelemetry Collector which is designed for collecting and processing metrics, logs, traces and profiles. Grafana Alloy can be deployed anywhere in your IT infrastructure.

The Grafana, Loki and Alloy stack

The Grafana, Loki and Alloy stack can be installed in many different ways, like bare metal, in VM’s, in docker containers, on Kubernetes or in the cloud.

For this tutorial we will be installing on nodes running Ubuntu 24.04 LTS with the bare minimum needed to test the functionality, but for production you should look at Grafana’s sizing guides mainly around Loki as it will be storing the data from HAProxy and the system hosting it, Grafana's sizing guide can be found here.

Bare metal lab configuration

Here are the components needed for a bare metal configuration:

After deploying your Ubuntu 24.04 LTS machines make sure that they are up to date.

Make sure all your other systems are up to date too:

sudo apt update && sudo apt upgrade -y 

How to install Grafana

On the system that's going to be the Grafana front end the following steps need to be taken:

1. Install the needed dependences:

sudo apt install -y apt-transport-https software-properties-common wget curl gpg

2. Add the Grafana APT Repository

sudo mkdir -p /etc/apt/keyrings/

wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null

echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list

sudo apt update

3. Install Grafana:

sudo apt install grafana -y

4. Start, Enable and check the status of the Grafana Server:

sudo systemctl start grafana-server
sudo systemctl enable grafana-server
sudo systemctl status grafana-server

You should see output indicating that the service is active (running).

5. Access the Grafana WebUI

At this point you should have a running Grafana server, Grafana runs on port 3000.

Open a web browser and navigate to:

http://your_server_ip_or_domain:3000

The default login is: admin \ admin

You’ll be prompted to change the default password upon your first login.

How to install Loki

On the system that is going to be the Loki server, the following will be needed:

1. Install the needed dependences:

sudo apt install -y wget unzip

2. Find the latest version of Loki:

LOKI_VERSION=$(curl -s "https://api.github.com/repos/grafana/loki/releases/latest" | grep -Po '"tag_name": "v\K[0-9.]+')
echo "Latest Loki version: v${LOKI_VERSION}"

3. Download the Loki Binary:

wget "https://github.com/grafana/loki/releases/download/v${LOKI_VERSION}/loki-linux-amd64.zip"

4. Unzip and move Loki:

unzip loki-linux-amd64.zip 
sudo mv loki-linux-amd64 /usr/local/bin/loki 
sudo chmod +x /usr/local/bin/loki

5. Verify Loki is installed:

loki --version

6. Create a folder to hold the Loki configuration:

sudo mkdir -p /etc/loki

7. Download the base configuration for Loki:

sudo wget -qO /etc/loki/config.yaml "https://raw.githubusercontent.com/grafana/loki/v${LOKI_VERSION}/cmd/loki/loki-local-config.yaml"

8. If needed you can make configuration changes to Loki, the available configuration options can be found here:

sudo nano /etc/loki/config.yaml

9. Create a Systemd service for Loki:

sudo nano /etc/systemd/system/loki.service

[Unit]
Description=Loki log aggregation system
After=network.target
[Service]
Type=simple
User=loki           # Create this user if it doesn't exist
ExecStart=/usr/local/bin/loki -config.file /etc/loki/config.yaml
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target

10. Create the Loki Daemon user account:

sudo useradd --system --no-create-home --shell /bin/false loki

11. Make sure that the new user can read the Loki config:

sudo chown -R loki:loki /etc/loki # Ensure Loki user can read config

12. Reload Systemd, start and enable Loki and check it's running:

sudo systemctl daemon-reload
sudo systemctl start loki
sudo systemctl enable loki
sudo systemctl status loki

You should see output indicating that the service is active (running).

13. Check Loki metrics endpoint:

curl http://your_server_ip_or_domain:3100/metrics

How to install Alloy

On the system that is going to be the Alloy, the following will be needed:

1. Install the required dependences:

sudo apt install -y apt-transport-https software-properties-common wget curl gpg

2. Add the Grafana APT Repository:

sudo mkdir -p /etc/apt/keyrings/

wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null

echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list

sudo apt update

3. Install Grafana Alloy:

sudo apt install alloy -y

4. Configure Alloy to be a Syslog server:

sudo nano /etc/alloy/config.alloy

loki.source.syslog "syslog_tcp" {
  listener {
    address = "0.0.0.0:51893"
    labels  = { component = "loki.source.syslog", protocol = "tcp" }
  }
  relabel_rules = loki.relabel.syslog_01.rules
  forward_to = [loki.write.default.receiver]
}

loki.source.syslog "syslog_udp" {
  listener {
    address  = "0.0.0.0:51898"
    protocol = "udp"
    labels   = { component = "loki.source.syslog", protocol = "udp" }
  }
  relabel_rules = loki.relabel.syslog_01.rules
  forward_to = [loki.write.default.receiver]
}

loki.relabel "syslog_01" {
  forward_to = []
  rule {
    action = "labelmap"
    regex  = "__syslog_(.+)"
  }
}


 loki.write "default" {
   endpoint {
     url = "http://<Loki_IP>:3100/loki/api/v1/push"
   }
 }

5. Modify Alloy service to expose the front end UI:

sudo vi /usr/lib/systemd/system/alloy.service

6. Edit the ExecStart line:

Original

ExecStart=/usr/bin/alloy run $CUSTOM_ARGS --storage.path=/var/lib/alloy/data $CONFIG_FILE

New

ExecStart=/usr/bin/alloy run $CUSTOM_ARGS --server.http.listen-addr=0.0.0.0:12345 --storage.path=/var/lib/alloy/data $CONFIG_FILE

7. Reload Systemd, start and enable Alloy and check it is running:

sudo systemctl daemon-reload
sudo systemctl start alloy
sudo systemctl enable alloy
sudo systemctl status alloy

You should see output indicating that the service is active (running).

8. Check the WebUI:

On another system open a browser and navigate to:

 http://your_server_ip_or_domain:12345

This will show you a graphical representation of your Alloy configuration:

The install of Grafana, Loki and Alloy is now complete and we can move on to configuring HAProxy to send its access logs to Loki.

On the machine that's running HAProxy we need to make sure that Rsyslog service is installed and running and then configure it to send HAProxy access logs to Loki via Alloy.

How to install and configure Rsyslog

If you're looking to do this on a Loadbalancer.org appliance please see the section at the end of this blog ('How to do all this with a Loadbalancer appliance').

The Rsyslog install

1. Make sure that your machine is up to date:

sudo apt update

2. Install Rsyslog on to the system:

sudo apt install rsyslog

3. Check Rsyslog has started:

sudo systemctl status rsyslog

The Rsyslog configuration

1. Create a custom configuration file for Rsyslog to hold Alloy config - we will call it 30-alloy.conf so that it gets loaded before the default config for Rsyslog:

sudo nano /etc/rsyslog.d/30-alloy.conf

2. Copy the following config into the new config file and save:

template(name="MyForwardFormat" type="string"
         string="<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n")

# Send all messages to the Alloy endpoint
*.* @<alloy_server_IP>:51898;MyForwardFormat

• <%PRI%>1 = The priority of the syslog message set by the sending application
• %TIMESTAMP:::date-rfc3339% = The time and date stamp formated to the RFC3339 standard
• %HOSTNAME% = The sending systems host name, in our case the load balancer
• %APP-NAME% = The application on the load balancer creating the entry
• %PROCID% = The Process ID of the sending application on the loadbalancer
• %MSGID% = The Message Identifier, a field within the message header that provides a specific, identifying tag for the type of message being logged.
• %STRUCTURED-DATA% = A message component that provides structured, interpretable, and decomposable data elements
• %msg%\n = Contains the actual content of the log message, including the event details

3. Restart Rsyslog to pick up the changes:

sudo systemctl restart rsyslog

4. Check Rsyslog has started:

sudo systemctl status rsyslog

How to connect the Grafana front end to Loki

1. Login to Grafana:

2. In the side menu expand Connections and click on Add new connection:

3. Search for Loki (it should say Installed; if not then click on it and then click the install button):

4. In the side menu, under Connections, click on Data source:

5. Click Add new data source button in the top right corner:

6. Search for Loki and click on it in the search results

7. Under Connection add the Loki server address, remembering to add the protocol and port:

8. Scroll to the bottom and click Save & test, if everything works you should get a green message:

9. In the side menu if you now navigate to Drilldown and then logs, you should see Loki.source.syslog:

You should now be able to browse your data from HAProxy and write queries to extract an event of interest. This can then be used to create dashboard and configure Grafana Alert manager.

How to do all this with a Loadbalancer appliance

1. Login to your load balancer, click on Local Configuration and then Physical - Advanced Configuration:

2. Scroll down to the logging configuration section:

3. Select Remote syslog Server or Both (note, if you select Remote syslog Server, then all logs will be sent to your syslog server and the load balancer will stop logging locally (***Be aware, when a TSD is requested it will be emptier and cause delays in support!***):

4. Set the IP address to the IP of the Alloy server, set the port to 51898 and leave the protocol set to UDP:

5. Place the following in the Remote syslog Server Template box:

<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n

• <%PRI%>1 = The priority of the syslog message set by the sending application
• %TIMESTAMP:::date-rfc3339% = The time and date stamp formated to the RFC3339 standard
• %HOSTNAME% = The sending systems host name, in are case the loadbalancer
• %APP-NAME% = The application on the loadbalancer creating the entery
• %PROCID% = The Process ID of the sending application on the loadbalancer
• %MSGID% = The Message Identifier, a field within the message header that provides a specific, identifying tag for the type of message being logged.
• %STRUCTURED-DATA% = A message component that provides structured, interpretable, and decomposable data elements
• %msg%\n = Contains the actual content of the log message, including the event details

6. Click Update

7. If you want to see HAProxy logs in Grafana then go to Cluster Configuration, Layer7 - Advanced Configuration and set the appropriate Logging level. After clicking Update make sure to restart HAProxy:

At this point you have configured remote sysloging for your Loadbalancer.org appliance! Remember, if you're running an HA pair make sure to repeat steps 1 - 7 on the secondary appliance.

Bonus resource: HAProxy log structure

If you get stuck at any point, the below table might be helpful when trying to troubleshoot:

These logs provide detailed information about each request and response, which is essential for maintaining a healthy and secure system.

Conclusion

By leveraging the power of Grafana, Loki, and Alloy, you can build a powerful, cost-effective, and scalable log aggregation system that centralizes your data for enhanced visibility and operational efficiency.

This integrated approach allows you to quickly troubleshoot issues, monitor system health, and gain deeper insights into your network traffic, ultimately saving your time and resources.

For many of you, Layer 7 will become your go-to load balancing method. It's become more and more popular for web applications because of its powerful features and the complex way modern internet traffic works.

In this guide, I'll walk you through everything you need to know about Layer 7 load balancing, from understanding what it is to finally getting it configured.

Table of contents

• What is Layer 7 load balancing?
• Is Layer 7 the same thing as reverse proxy?
• Layer 7 load balancing protocols
• How Layer 7 load balancing works
• Benefits of Layer 7 load balancing
• Common Layer 7 use cases
• How to configure Layer 7 load balancing
• Using Layer 7 and GSLB in tandem

What is Layer 7 load balancing

Understanding Layer 7 application load balancing

Layer 7 load balancing intelligently routes traffic at the Application Layer of the OSI (Open Systems Interconnection) model, examining the content being delivered, and routing it accordingly.

It is the most flexible method of load balancing, providing high availability and scale for applications, while being easy to implement.

Other names for Layer 7 load balancing include Application Layer load balancing, and HTTP Load balancing.

What’s the difference between Layer 7 and Layer 4 load balancing?

Layer 7 load balancers are content aware, whereas Layer 4 load balancers operate at the Transport Layer of the OSI model, forwarding traffic without inspecting its contents.

For more on the different load balancing methods check out this blog: Compare Layer 4, Layer 7, and GSLB.

What’s the difference between an API gateway and a Layer 7 load balancer?

While a Layer 7 load balancer and an API gateway both manage and route traffic at the Application Layer, they have distinct feature sets and serve different purposes.

A Layer 7 load balancer distributes network traffic efficiently across a group of backend servers to optimize performance and ensure high availability. An API gateway is a dedicated management tool for API requests. While it can include L7 load balancing capabilities as a feature, its core purpose is to act as a single point of entry for all API calls.

Is Layer 7 the same thing as reverse proxy?

Layer 7 load balancing is NOT the same thing as Reverse Proxy but they are very closely related!

A reverse proxy is a general type of server that handles incoming requests and sends them to the right web server.

A Layer 7 load balancer is a more specialized kind of reverse proxy. Its key job is to distribute traffic across a group of servers to ensure high performance and availability.

So, think of a Layer 7 load balancer as an upgraded, more intelligent version of a reverse proxy, designed specifically to manage heavy traffic.

What is a reverse proxy?

A reverse proxy is what handles all incoming requests before they ever reach your servers. It acts as an intermediary, receiving a request from a user and then forwarding it to one of your backend servers.

Reverse proxy acts as a helpful middleman, and that comes with a lot of perks. It can give you:

• Better security: It hides your actual servers from the outside world, keeping them safe from direct attacks.
• SSL/TLS termination: It handles all the heavy lifting of encrypting and decrypting traffic, freeing up your servers to focus on their main job.
• Faster performance: It can cache static files like images and CSS, which means less work for your servers and quicker load times for your users.
• URL rewriting: It can change the URL of a request before it even gets to your servers, giving you more control over your traffic flow.

What is a Layer 7 load balancer?

A Layer 7 load balancer works at the Application Layer of the OSI model, which is a fancy way of saying it reads the actual content of a request. It can examine things like the URL, HTTP headers, or even a cookie to make a smart decision about where to send the traffic.

For example, it can send an image request to a server that's great at serving static files. At the same time, it can route a request to a user's shopping cart to a completely different server that handles that kind of work.

Because it's reading the request's content, a Layer 7 load balancer is naturally a specific type of reverse proxy. It receives and forwards requests, but with the added responsibility of distributing traffic based on application-level logic.

So, while a Layer 7 load balancer is a reverse proxy, the reverse isn't always true. Not all reverse proxies are Layer 7 load balancers. A reverse proxy can be a simple intermediary for a single server or could be configured for tasks like SSL termination or caching without ever needing to distribute traffic across multiple servers.

Layer 7 load balancing protocols

Layer 7 load balancing operates at the application layer of the OSI model, using the HTTP protocol.

This is the protocol that gets web pages and other content from a server to your browser. HTTPS is just the secure, encrypted version.

For more on HTTP, check out our beginner's guide:

How Layer 7 load balancing works

Layer 7 load balancing uses a proxy at the application layer. Inbound requests are terminated on the load balancer and HAProxy generates a new corresponding request to the chosen Real Server. As a result, Layer 7 is typically not as fast as the Layer 4 methods. Layer 7 is typically chosen when either enhanced options such as SSL termination, cookie based persistence, URL rewriting, header insertion/deletion etc. are required, or when the network topology prohibits the use of the Layer 4 methods.

The image below shows how Layer 7 load balancing works:

Since Layer 7 load balancing acts as a full proxy, your backend servers can be located anywhere on the network—even across the internet or a WAN.

By default, Layer 7 load balancing isn't transparent. This means your servers won't see the client's real IP address. Instead, they'll see the load balancer's IP address (or another local appliance's IP, if you've set it up that way).

You can actually change this setting for each Layer 7 VIP. If you need to, the load balancer can be configured to send the real client's IP address to your servers in one of two ways. It can either:

• Add a new header with the client's IP address inside.
• Or, it can change the IP address of the traffic itself, replacing its own address with the client's.

Benefits of Layer 7 load balancing

Layer 7 load balancing can improve application performance in the following ways:

Intelligent routing

Layer 7 load balancing is smart because it looks at the actual content of a request—things like the URL, headers, or even cookies. This lets it make intelligent decisions about where to send traffic.

For instance, it can send requests for images and CSS files to one set of servers, while directing API calls to a completely different group. This level of control ensures every request goes to the best possible server, which makes everything run more efficiently and gives the user a better experience.

Improved performance

Layer 7 load balancing boosts your app's performance in a couple of ways, for example through SSL offloading and caching.

It handles the demanding job of encrypting and decrypting traffic, which frees up your web servers to focus on their main tasks.

This whole process makes it much easier to scale your application, as you can add or remove servers from the pool without affecting the system's performance.

Enhanced security

Because it inspects the application layer, a Layer 7 load balancer can provide powerful security features that aren't possible at other levels.

It acts as a full proxy, shielding your backend servers from direct exposure to the internet. This lets it handle the heavy lifting of SSL/TLS termination, which decrypts and encrypts traffic before it ever reaches your servers. It can also filter out malicious requests, block common attacks, and prevent direct exploits.

Common Layer 7 use cases

I would definitely recommend considering Layer 7 load balancing when you want to implement any of the following:

1.Content switching

Because Layer 7 load balancing is content-aware, this allows for:

• URL-based routing: A Layer 7 load balancer can look at the URL to send traffic to the right place. For example, it can send requests for /images to servers that are great at handling static content, while sending API requests to a different group of servers.
• Cookie-based persistence: This is a huge benefit for keeping a user's session consistent. The load balancer can use a cookie to make sure a user's requests always go to the same server, which is essential for things like shopping carts where the session state is stored on a specific server.
• Device-specific routing: It can send traffic from mobile devices to servers optimized for mobile apps, while routing desktop traffic to your main web application servers. This helps ensure everyone gets a smooth experience no matter what device they're on.

2.Security and protocol handling

Layer 7 load balancing can also provide a security buffer e.g.

• Acts as a full proxy: A Layer 7 load balancer acts like a shield. It ends the connection from the client and creates a new one to the backend server. This hides your servers from the internet, so attackers can't target them directly. All threats are handled by the load balancer first.
• SSL/TLS termination: In this scenario the load balancer handles all the heavy lifting of encrypting and decrypting traffic. This not only frees up your web servers to focus on their main jobs but also allows the load balancer to inspect the content for threats before it's sent to your application.
• Content and header filtering with WAF: A Layer 7 load balancer with a Web Application Firewall can be configured to filter traffic based on a set of specific rules you create. For instance, you can use a Core Rules Set (CRS), which is a collection of pre-made rules that can detect and block known malicious content, like SQL injection attacks or suspicious headers. This gives your application an extra layer of defense against common threats.

3.Performance optimization

Layer 7 load balancing can also be used to accelerate application performance.

For example, the load balancer can compress responses before sending them to the client. This reduces the amount of data that needs to be transferred, which in turn helps your web pages load faster.

In high-traffic situations, the load balancer can also prioritize certain kinds of requests. For example, it can make sure that API calls are handled before requests for less important content, ensuring a smooth and consistent experience for your users.

How to configure Layer 7 load balancing

The configuration steps will vary depending on the mode used and the application being load balanced, but here are some example use cases with step-by-step configuration and deployment instructions.

How to configure Layer 7 load balancing

Here are some example applications that could benefit from Layer 7 load balancing and individual guides to explain how to configure the load balancer in each scenario:

• How to load balance AGFA Healthcare Enterprise Imaging with Layer 7
• How to load balance Boomi Blueprint with Layer 7
• How to load balance Ceph Object Gateways with Layer 7
• How to load balance Citrix StoreFront with Layer 7
• How to load balance Cloudian HyperFile with Layer 7
• How to load balance Cribl Stream with Layer 7
• How to load balance CTERA Portal with Layer 7
• How to load balance Ellucian Banner with Layer 7
• How to load balance EMIS Symphony with Layer 7
• How to load balance Epicor ERP 10 with Layer 7
• How to load balance Epicor Kinetic ERP 11 with Layer 7
• How to load balance Hitachi Content Platform with Layer 7
• How to load balance HPE Ezmeral with Layer 7
• How to load balance Huawei OceanStor with Layer 7
• How to load balance Hyland OnBase with Layer 7
• How to load balance Konica Minolta Dispatcher with Layer 7
• How to load balance Mach7 Technologies with Layer 7
• How to load balance Meditech RESTful API with Layer 7
• How to load balance Microsoft Remote Desktop Services with Layer 7
• How to load balance Microsoft SQL Server with Layer 7
• How to load balance Nutanix Object Storage with Layer 7
• How to load balance Oracle PeopleSoft with Layer 7
• How to load balance Oracle JD Edwards EnterpriseOne with Layer 7
• How to load balance Panzura CloudFS with Layer 7
• How to load balance Powerschool eSchoolPlus SIS with Layer 7
• How to load balance RedHat OpenShift with Layer 7
• How to load balance RedHat OpenStack with Layer 7
• How to load balance SMTP Servers with Layer 7
• How to load balance Storage Made Easy File Fabric with Layer 7
• How to load balance YSoft SafeQ with Layer 7

Using Layer 7 and GSLB in tandem

Layer 7 load balancing is often used in combination with GSLB to create multi-site resilience.

Global Server Load Balancing (GSLB) provides traffic distribution across server resources located in multiple locations, for example, multiple data centers or a single disaster recovery (DR) site for redundancy. It passes the traffic straight to the load balancer which does more granular balancing and health checking.

GSLB active-active load balancing example:

Demand for GSLB has grown significantly in the last three years, as large numbers of organizations have migrated away from traditional on-premise systems and have instead created hybrid cloud and hosted environments. Many have also made the strategic decision to split their data resources across multiple locations to improve business resilience and reduce costs.

What are the pros of GSLB for multi-site resilience?

• Flexible health checks to ensure application uptime.
• Topology based routing ensures that internal traffic uses the local data center, avoiding the cost and performance issues of over-using WAN links.
• It can detect users’ locations and automatically route their traffic to the best available server in the nearest data center.

What are the cons of GSLB for multi-site resilience?

• Sometimes applications do not support DNS and therefore can’t failover using GSLB (we do however have a solution for that).

Conclusion

Layer 7 load balancing has become a crucial tool for modern applications, offering a powerful way to manage complex internet traffic.

By inspecting the content of requests, it provides intelligent routing, enhanced security, and improved performance through features like SSL offloading and caching. As this guide has shown, Layer 7 load balancing is a highly specialized type of reverse proxy, acting as an advanced traffic manager that can optimize your entire application stack. It's also often used in tandem with Global Server Load Balancing (GSLB) for multi-site resilience, creating a robust and highly available architecture. As the web continues to evolve, so too will the load balancers that power it, ensuring applications remain fast, secure, and resilient.

If you’re thinking of implementing Layer 7 and need to establish a Proof of Concept, feel free to reach out for a free consultation with one of our technical experts.

More on other load balancing methods

• Layer 4 load balancing guide
• When and how to use Global Server Load Balancing (GSLB)
• Compare Layer 4, 7, and GSLB techniques

When it comes to data storage, we're often obsessed with chasing higher and higher throughput speeds to handle massive workloads (think AI and high-performance computing) — trying to transfer as much data as possible in the shortest amount of time.

But what if I told you the small stuff can sometimes cause an even bigger headache? Yep, I know, it seems counterintuitive, but small workloads can sometimes create a unique set of problems that are harder to solve. This is especially true for workloads with a large number of very small data packets or a high rate of small HTTP requests.

Here I'll break down why small objects can be troublesome, and explain how to route your S3 traffic by traffic size for more efficient data storage and management.

The problem: Bigger isn't always better when it comes to objects

The 'small objects problem'

When it comes to data storage, small objects can create BIG problems. It's not that there's something inherently wrong with little objects — they're just trickier to deal with. I'm going to call this the 'small objects problem'.

This can cause a number of issues. Specifically:

1. Network congestion: High network traffic made of many small packets can overwhelm a network, especially since each packet needs to be processed individually, which adds a lot of overhead.
2. High overheads: Using small packets is inefficient because the header information required for routing and delivery (like addresses and protocols) can take up more space than the actual data you're sending, which wastes a lot of bandwidth.

In contrast, large objects are simpler to handle because once the connection is established, the entire file can be transferred in one go. The systems then work together to sort out a window size and send as much data as possible. Compared to the file transfer the connection setup for large objects is a very small portion of all the data that is sent.

But with small objects the connection setup becomes a large part (or even the largest part) of the entire request. This means small objects are actually harder to deal with than larger objects.

So if your workload requires a lot of concurrent access to small objects as well as access to large objects, you are going to want to optimize where you store and access the items from. To do that, you need to make fast friends with IOPs...

Operations Per Second (IOPs)

Input/Output Operations Per Second (IOP) is a crucial performance metric used to measure how quickly a storage device, like a hard disk drive (HDD) or solid-state drive (SSD), can read and write data.

IOPs, or Input/Output Operations Per Second, is a key metric that measures a storage device's performance by counting the total number of individual read or write requests it can process in one second. Unlike throughput, which measures the volume of data transferred (e.g., megabytes per second), IOPs focuses on the frequency of these data access requests. This makes it a crucial indicator for workloads that involve a high number of small, random operations, such as those found in databases or virtualized environments, where the speed of processing each individual request is more important than the total amount of data being moved.

The table below nicely illustrates the vast differences in speed for Hard Disk Drives (HDD), Solid-State Drives (SSD), and Non-Volatile Memory Express (NVMe) SSDs, based on their Input/Output Operations Per Second (IOPS):

Make sense?

What's the difference between IOPS and GBs?

It's easy to confuse IOPs with throughput, but they measure different things.

While IOPs measure the number of items moved per second (IOP) throughput measures the amount of data transferred (GB).

So if you're dealing with lots of small, random requests for small objects you'll be much more interested in IOP. Conversely, if you're streaming or transferring large files in sequence, you'll be more interested in throughput.

It's not an either-or, they're simply different problems to solve. Hence you can have a storage device with high IOPS but low throughput, or a storage device with low IOPs but high throughput. So both metrics are important, but the one we're focused on here is IOP.  

With me so far? Excellent! So let's assume you have a high number of small files that are overwhelming your system's ability to process individual I/O operations. How do you fix it? Here's how...

Solution: Implement a content-length header

Implementing a Content-Length header rule can help overcome the small object problem by allowing your system to inspect the size of a file before it's fully received. This allows it to make smarter routing and storage decisions i.e. send small objects (>1-2MB) to NVMe nodes and large objects (<2MB) to HDD nodes.

The Content-Length rule requires the Virtual Service to be moved away from Layer 7 TCP mode and instead be set as Layer 7 HTTP mode.

How to set up a content-length header on a Loadbalancer.org appliance

Follow the steps outlined in this Deployment Guide, then make the following adjustments/changes:

1. Go to the S3 Virtual Service
2. Change the "Layer 7 Protocol" to be "HTTP Mode"
3. Add these ACL Rules to your S3 service:

4. Create backend only Virtual Service(s). You could just add one and then only use it if both ACL rules (http_put && large_object) match. Or, you can create it in the way that I did in this example. You will then need to add Real Servers to the backend(s).

And that's it!

Sometimes simple changes can make a BIG difference to performance!

Following the steps above should help you overcome the 'small objects problem'; allowing you to more effectively manage small objects by analyzing the PUT operations and payload size of your S3 traffic, determining the optimal nodes for data placement.

This will allow you to more effectively manage and optimize your data storage.

And for those times when you just need raw power, you can always use smart load balancing for 100x faster throughput!

Remember when IPv4 addresses seemed confusing? Those were simpler times, my friend. Back then, we only had to remember four numbers separated by dots. Easy-peasy. Then IPv6 came along with addresses that look like someone let a toddler loose on a hexadecimal keyboard:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

But fear not! Today we're going to show you how Loadbalancer.org makes IPv6 configuration so simple, even your network switch would be impressed.

IPv6: The protocol that's finally having its moment

IPv6 has been around for over 25 years, patiently waiting in the wings like an understudy who's finally getting their big break. With 2^128 possible addresses (that's roughly 340 undecillion, or enough addresses to give every grain of sand on Earth about 3 billion IP addresses each), IPv6 is basically the networking equivalent of having infinite closet space.

And yes, those addresses look intimidating. But here's the thing: IPv6 addresses are like that really smart friend who looks complicated but is actually quite logical once you get to know them. Plus, you can compress them! That monster address:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

becomes the much more manageable:

2001:db8:85a3::8a2e:370:7334

See? IPv6 has a sense of style.

Configuring IPv6 on Loadbalancer.org: Easier than explaining why we ran out of IPv4 addresses

Let's get down to business. Configuring IPv6 on your Loadbalancer.org appliance is so straightforward, you'll wonder why you've been putting it off.

Step 1: Give your appliance an IPv6 Identity

Navigate to Local Configuration → Network Interface Configuration and select your interface. It's like picking a name tag at a networking event, except this name tag has colons and hexadecimal digits.

Enter your IPv6 address with its prefix length:

2001:db8:85a3::8a2e:370:7334/64

And click Configure Interfaces button.

Pro tip!  If you're running a cluster (and who isn't these days?), remember that each node needs its own unique address. Think of it like assigning parking spaces – everyone gets their own spot:

• Primary node:

2001:db8:85a3::8a2e:370:7334/64

• Secondary node:

2001:db8:85a3::8a2e:370:7335/64

And yes, IPv6 addresses are case-insensitive, but we recommend lowercase because SHOUTING IN IPv6 IS JUST AS ANNOYING AS SHOUTING IN EMAILS.

Load Balancing IPv6 traffic: Layer 4 edition

Now for the fun part – actually load balancing some traffic! We'll start with a Layer 4 NAT configuration because, let's face it, sometimes you just want to keep things simple.

Step Two: Create your virtual service

Head over to Cluster Configuration → Layer 4 - Virtual Services and create a new service:

• Label: Something memorable (like "MyAwesomeIPv6Service")
• IPv6 Address:

2001:db8:85a3::8a2e:370:7336

• Port: 80 (because port 80 is the networking equivalent of a comfortable pair of jeans)
• Protocol: TCP
• Forwarding Method: NAT

Click Update and pat yourself on the back – you're officially load balancing IPv6 traffic!

Step Three: Adding Real Servers

Now add your real servers via Cluster Configuration → Layer 4 - Real Servers. Give them labels and IPv6 addresses, because every server deserves a proper introduction.

Important note: Since we're using NAT mode, your servers need to know how to get back home. Set their default gateway to your Loadbalancer.org appliance's IPv6 address. If you're using a cluster (and you should be, because redundancy is like having a backup generator for your backup generator), make sure you're using a Floating IP.

Voilà! Your IPv6 load balancing setup is ready to handle traffic like a seasoned maître'D, directing customers to tables.

Layer 7 HTTP load balancing: The plot twist

But wait, there's more! (I promise this isn't a late-night infomercial.) Layer 7 load balancing with IPv6 is where things get fascinating – and by interesting, I mean "surprisingly easy".

Step Four: IPv6 to IPv4 Translation: The Universal Translator

Create a new Virtual Service under Cluster Configuration → Layer 7 - Virtual Services:

• IPv6 Address:

2001:db8:85a3::8a2e:370:7336

• Port: 80
• Protocol: HTTP

Here's the magic: your real servers can use IPv4 addresses! That's right – your shiny new IPv6 frontend can talk to your legacy IPv4 backend servers. It's like having a translator at a United Nations meeting, except less formal and more reliable.

Add your real servers with their IPv4 addresses under Layer 7 - Real Servers, and since Layer 7 is a full proxy, your backend servers don't need to know anything changed. They'll just keep doing their thing while your load balancer handles all the IPv6 magic behind the scenes.

Step Five: Going the Other Way: IPv4 to IPv6

Because Loadbalancer.org believes in equal opportunity networking, you can also do this in reverse:

• Virtual Service: IPv4 address (like 192.168.1.1)
• Real Servers: IPv6 addresses
• Result: Your IPv4 clients can seamlessly access IPv6 services

It's networking diplomacy at its finest.

The bottom line: IPv6 doesn't have to be scary

Look, we get it. IPv6 addresses look like someone sneezed while typing hexadecimal. But with Loadbalancer.org, configuring IPv6 load balancing is about as complicated as making toast – and significantly more useful for your network infrastructure.

Whether you're doing Layer 4 NAT configuration or Layer 7 HTTP load balancing with IP translation, Loadbalancer.org makes it simple enough that you can set it up during your coffee break. And with 340 undecillion IPv6 addresses at your disposal, you'll never have to worry about running out of IP space again.

So go ahead, embrace the future of networking. Your IPv6 addresses might look intimidating, but they're just waiting to be part of your beautifully load-balanced infrastructure.

After all, if we can figure out how to make IPv6 work seamlessly with IPv4, surely we can figure out anything. Right?

Now, if someone could just explain to me why we need 340 undecillion addresses when there are only about 8 billion people on the planet...but that's a blog post for another day ; )

Ready to give IPv6 a try with Loadbalancer.org? Your network (and your future self) will thank you. Plus, you'll finally have something interesting to talk about at networking meetups.