Network Engineering
F5 BIG-IP Active-Standby HA
A two-node F5 BIG-IP Active-Standby pair in the DMZ, built to replace an internet-facing Windows HA proxy and load-balance an on-premises application.
Overview
This project replaces an internet-facing Windows HA proxy with a two-node F5 BIG-IP Active-Standby pair. The appliances are virtual editions on the VMware hosts already in the DMZ. Local Traffic Manager (LTM) is the only module in use.
Outside traffic hits one virtual address. BIG-IP sends it to the on-premises application servers. The application then talks to its own backend directly, past the load balancer.
Why replace the Windows proxy
The old proxy was a single public address with a Windows failover pair behind it. It worked, and every client and upstream service already pointed at that address. Replacing it had to keep that address, or the cutover would turn into a retargeting project.
A clean Active-Standby BIG-IP pair gives the same shape: one address, a spare that can step in, and a configuration that is synced instead of rebuilt by hand on the second box.
What we built
The pair
Both units were rebuilt into a fresh Active-Standby device group:
- Config sync between the two BIG-IPs
- Floating addresses for the traffic interfaces
- Failover so the standby unit can own the virtual servers
The platform is a pair of 200 Mb virtual editions. Scope stays on LTM. Access policy, a web application firewall, and global traffic management are separate work if they are needed later.
The test virtual server
The first build used a testing address, not the production IP.
- Routes into the application network
- SNAT Automap, so return traffic comes back through BIG-IP
- An HTTP pool with the application servers
- TLS termination on port 443, with HTTP on port 80
We checked the path from inside the network, failed the pair over, and checked it again. We then checked HTTP and HTTPS from the internet to the testing public address. That was the gate before any production cutover.
Development virtual server
A later change added a development virtual server on the same pair. It has its own pool member, its own certificate, and its own public name. The development application proxies onward to its own app server. That app server is not an F5 pool member.
Production virtual servers were not changed. No new route was required, because the development server sits on the same subnet as the internal self IPs. The pair reported In Sync after the change, and the team confirmed the full development path.
Cutover
Production cutover is a same-IP move. BIG-IP takes the address the Windows proxy already used, so browsers and the upstream service keep their current target.
The order is deliberate: discovery, a clean HA rebuild, a tested virtual server, a separate development path, then the production address. Day-one support and a short handover sit with the cutover, not months later.
Scope
In this engagement:
- BIG-IP high availability and LTM for this application
- Functional tests and failover tests
- Cutover support and day-one documentation
Left with the teams that already own them: the VMware design, the DMZ and firewall, application changes, certificate-authority buildout, and ongoing 24x7 operations after the handover.
Current status
In progress. The pair is built. The test path has been validated, including failover and WAN checks. The development virtual server is live on the same devices. The remaining step is the production same-IP cutover.
- Active-Standby, LTM only. Two BIG-IP virtual editions on the existing VMware DMZ, synced with Device Service Clustering. One unit owns the traffic. The other stays current and can take over.
- Proved on a test address first. HTTP pool, SNAT, and TLS termination were checked locally, after failover, and from the WAN, before anyone touched the production IP.
- Development on the same pair. A separate development virtual server and pool were added later. Production objects were left alone, and the pair stayed in sync.