Learn Keepalived - HA for Gateway & Router Redundancy
Episode 12 of 23

Learn Keepalived - HA for Gateway & Router Redundancy

This episode covers Keepalived as a redundant gateway: default gateway failover with VRRP, outbound routing configuration, integration with the Linux kernel routing and ip_forward, and policy routing for healthy outbound traffic.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Introduction

One of the oldest and most important Keepalived use cases is making the default gateway redundant. If the gateway dies, the whole subnet loses outbound access — unless there's a backup router ready to take over the VIP within seconds. Episode 12 builds this scenario from scratch.

We'll configure two router nodes sharing one gateway VIP, enable IP forwarding in the kernel, integrate routes with VRRP state, and add policy routing so outbound traffic always leaves through a healthy path. By the end of this episode, your subnet has an exit door that is never a single point of failure.

Redundant Default Gateway with VRRP

The Virtual Gateway Concept

Two routers share one VIP, and all clients use that VIP as their default gateway. When the active router dies, the VIP moves to the backup router, and clients keep their outbound access without changing anything. This is the simplest form of first-hop redundancy.

Configuring the Two Routers

Configure the active router (lb01) and backup (lb02) with the familiar pattern:

Gateway VIP on lb01
global_defs {
  router_id GW-01
}
 
vrrp_instance VI_GW {
  state MASTER
  interface eth0
  virtual_router_id 70
  priority 100
  virtual_ipaddress {
    192.168.1.1/24 dev eth0
  }
  virtual_routes {
    0.0.0.0/0 via 203.0.113.1 dev eth1
  }
}

On the backup node, change state to BACKUP and priority to 90, keeping virtual_router_id and virtual_ipaddress exactly the same. VIP 192.168.1.1 becomes the logical default gateway for all clients in 192.168.1.0/24.

Outbound Routing and IP Forwarding

Enabling IP Forwarding

For the router to forward packets between interfaces, enable forwarding in the kernel:

Enable ip_forward
sudo sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/99-keepalived.conf
sudo sysctl -p /etc/sysctl.d/99-keepalived.conf

The sysctl -w net.ipv4.ip_forward=1 command enables forwarding immediately, and writing to /etc/sysctl.d/99-keepalived.conf makes it persistent. Without forwarding, the router won't pass client packets to the internet.

A gateway whose uplink is down isn't fit to be MASTER. Add tracking:

Gateway with uplink tracking
vrrp_instance VI_GW {
  state MASTER
  interface eth0
  virtual_router_id 70
  priority 100
  track_interface {
    eth1
  }
  virtual_ipaddress {
    192.168.1.1/24 dev eth0
  }
  virtual_routes {
    0.0.0.0/0 via 203.0.113.1 dev eth1
  }
}

The track_interface block drops the priority when eth1 (the uplink to the internet) is down. A MASTER that loses its outbound connection will promptly hand over the VIP to the backup router with a healthy uplink.

Integration with the Kernel Routing

Ensuring a Correct Return Path

When the VIP moves, the ARP and routing tables on the switch must be updated. Keepalived's GARP handles ARP, but make sure the switch doesn't use sticky MAC. If it does, the port configuration must allow the virtual MAC 00:00:5E:00:01:XX to move.

Policy Routing for Outbound Traffic

A topology with two ISPs or uplinks needs policy routing so traffic leaves through the right path. Create a separate routing table and rules:

Policy routing for the uplink
sudo ip rule add from 192.168.1.0/24 lookup 100
sudo ip route add default via 203.0.113.1 dev eth1 table 100

The ip rule add from 192.168.1.0/24 lookup 100 command directs traffic from the client subnet to table 100, and ip route add default via 203.0.113.1 dev eth1 table 100 fills that table. This policy routing makes sure reply packets come back through the same uplink as the request.

Verifying the Exit Path

Test that the gateway VIP actually forwards traffic:

Verify from a client
ip route show
ping -I 192.168.1.1 8.8.8.8 -c 3

The ip route show output on the client should show default via 192.168.1.1, and ping -I 192.168.1.1 8.8.8.8 proves the gateway forwards packets to the internet.

Active-Active Gateway Scenario

To make use of both routers, give each one a VIP and point half the clients at VIP A and half at VIP B:

Active-active gateway on lb01
vrrp_instance VI_GW_A {
  state MASTER
  interface eth0
  virtual_router_id 70
  priority 100
  virtual_ipaddress {
    192.168.1.1/24 dev eth0
  }
}
 
vrrp_instance VI_GW_B {
  state BACKUP
  interface eth0
  virtual_router_id 71
  priority 90
  virtual_ipaddress {
    192.168.1.2/24 dev eth0
  }
}

On lb01, instance VI_GW_A becomes MASTER for gateway A and VI_GW_B becomes BACKUP for gateway B. On lb02 the configuration is reversed. The result: both routers carry real load, and each one is the other's backup.

Closing

Episode 12 makes Keepalived the backbone of your network: a redundant default gateway with a VIP, active IP forwarding, a tracked uplink, and policy routing for a healthy exit path. Your subnet now has an exit door that is always guarded.

Key takeaways:

  • A gateway VIP means the client default gateway is never a single point of failure.
  • Enable net.ipv4.ip_forward so the router actually forwards packets.
  • track_interface moves the VIP when the uplink goes down.
  • GARP keeps the virtual MAC moving across ARP tables and switches.
  • Policy routing ensures the return path goes through the same uplink.
  • Two VIPs on two routers create an active-active gateway.

In episode 13 next, we cover secure traffic handling — combining Keepalived with iptables and nftables firewalls, protecting the VIP from spoofing with reverse path filtering, and securing health check endpoints.

Learn Keepalived - HA for Gateway & Router Redundancy | Learn Keepalived