F5 Load Balancing

VMs located in different Data Centre ┌──────────────────────────┐ │ Client │ └────────────┬─────────────┘ │ ▼ DNS Request: pmpcn.com │ ▼ ┌────────────────────┐ │ F5 GTM (DNS) │ └───────┬────────────┘ │ ┌────────────────────┴────────────────────┐ ▼ ▼ ┌────────────────────┐ ┌────────────────────┐ │ F5 LTM - DC1 │ │ F5 LTM - DC2 │ │ VIP: 10.0.0.100:8443│ │ VIP: 10.0.1.100:8443│ └─────────┬──────────┘ └─────────┬──────────┘ │ │ ┌──────┴──────┐ ┌──────┴──────┐ ▼ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ VM1 │ │ VM2 │ │ VM3 │ │ VM4 │ │ Java │ │ Java │ │ Java │ │ Java │ │ App │ │ App │ │ App │ │ App │ │ :8443 │ │ :8443 │ │ :8443 │ │ :8443 │ └────────┘ └────────┘ └────────┘ └────────┘ VMs in same Data Center ┌──────────────────────────┐ │ Client │ └────────────┬─────────────┘ │ DNS Request: pmpcn.com │ ▼ ┌────────────────────┐ │ F5 LTM (VIP) │ │ 10.0.0.100:8443 │ └─────────┬──────────┘ │ ┌────────────┴────────────┐ ▼ ▼ ┌────────────┐ ┌────────────┐ │ VM1 │ │ VM2 │ │ Java App │ │ Java App │ │ :8443 │ │ :8443 │ └────────────┘ └────────────┘ Client ↓ DNS request (pmpcn.com) ↓ F5 GTM (optional, DNS-level routing) ↓ F5 LTM (VIP: 10.0.0.100:8443) | +--> VM1 (Java App 1:8443) | +--> VM2 (Java App 2:8443) Flow from Client to App for VMs in different DCs User accesses: https://api.pmpcn.com ↓ DNS lookup: api.pmpcn.com (CNAME → gtm.pmpcn.com) ↓ F5 GTM resolves → dc1-ltm.pmpcn.com or dc2-ltm.pmpcn.com ↓ VIP: 10.0.0.100:8443 (DC1) or 10.1.0.100:8443 (DC2) ↓ Load balanced to: VM1 or VM2 in that DC on port 8443 Testing Setup Test DNS resolving to GTM # DNS Resolution dig api.pmpcn.com OR # CNAME Resolution nslookup api.pmpcn.com api.pmpcn.com should resolve to gtm.pmpcn.com (CNAME) Test GTM resolving to LTMs dig gtm.pmpcn.com Test LTM connectivity ping nc -vz 8443 curl -vk https://:8443/actuator/health Summary of Commands Purpose Command Example DNS Resolution dig api.pmpcn.com CNAME Resolution nslookup api.pmpcn.com GTM FQDN Test dig gtm.pmpcn.com LTM FQDN Test dig dc1-ltm.pmpcn.com Port Test to VIP nc -vz api.pmpcn.com 8443 SSL Cert Validation openssl s_client -connect api.pmpcn.com:8443 Backend Health API curl -vk https://api.pmpcn.com/actuator/health Trace Route traceroute api.pmpcn.com Direct Backend Check telnet 8443 Telnet (for basic port check only) This tests TCP connectivity to a host and port, it doesn’t understand HTTP or HTTPS: telnet api.pmpcn.com 8443 Curl (for actual HTTPS request) This checks the HTTP response from your app, including TLS handshake: curl -vk https://api.pmpcn.com:8443 -v: verbose (shows headers) -k: skip SSL certificate validation (useful if self-signed cert) Summary Action Use This Command Check if port 8443 is open telnet api.pmpcn.com 8443 Send HTTPS request curl -vk https://api.pmpcn.com:8443 Check specific API health curl -vk https://api.pmpcn.com:8443/actuator/health Configuring SSL Certs Component SSL Cert Needed? Details GTM Usually No GTM mainly handles DNS, not SSL termination. LTM VIP Yes LTM usually terminates SSL for your public-facing service. Backend VMs Optional (Yes or No) Depends if LTM does SSL termination or passes through. Client URL Yes (on LTM VIP) The cert must match the public FQDN clients use (e.g., api.pmpcn.com) What to secure How to name it Cert procurement method LTM VIP SSL certificate Use FQDN, not IP Public CA for domain cert Public service domain FQDN (e.g., api.pmpcn.com) Public CA or internal

May 18, 2025 - 10:56

VMs located in different Data Centre

                    ┌──────────────────────────┐
                    │        Client            │
                    └────────────┬─────────────┘
                                 │
                                 ▼
                    DNS Request: pmpcn.com
                                 │
                                 ▼
                      ┌────────────────────┐
                      │   F5 GTM (DNS)     │
                      └───────┬────────────┘
                              │
         ┌────────────────────┴────────────────────┐
         ▼                                         ▼
┌────────────────────┐                   ┌────────────────────┐
│ F5 LTM - DC1       │                   │ F5 LTM - DC2       │
│ VIP: 10.0.0.100:8443│                   │ VIP: 10.0.1.100:8443│
└─────────┬──────────┘                   └─────────┬──────────┘
          │                                        │
   ┌──────┴──────┐                          ┌──────┴──────┐
   ▼             ▼                          ▼             ▼
┌────────┐   ┌────────┐                ┌────────┐     ┌────────┐
│ VM1    │   │ VM2    │                │ VM3    │     │ VM4    │
│ Java   │   │ Java   │                │ Java   │     │ Java   │
│ App    │   │ App    │                │ App    │     │ App    │
│ :8443  │   │ :8443  │                │ :8443  │     │ :8443  │
└────────┘   └────────┘                └────────┘     └────────┘

VMs in same Data Center

                    ┌──────────────────────────┐
                    │        Client            │
                    └────────────┬─────────────┘
                                 │
                      DNS Request: pmpcn.com
                                 │
                                 ▼
                      ┌────────────────────┐
                      │   F5 LTM (VIP)     │
                      │  10.0.0.100:8443   │
                      └─────────┬──────────┘
                                │
                   ┌────────────┴────────────┐
                   ▼                         ▼
            ┌────────────┐           ┌────────────┐
            │   VM1      │           │    VM2     │
            │ Java App   │           │ Java App   │
            │  :8443     │           │  :8443     │
            └────────────┘           └────────────┘

Client
  ↓
DNS request (pmpcn.com)
  ↓
F5 GTM (optional, DNS-level routing)
  ↓
F5 LTM (VIP: 10.0.0.100:8443)
  |
  +--> VM1 (Java App 1:8443)
  |
  +--> VM2 (Java App 2:8443)

Flow from Client to App for VMs in different DCs

User accesses: https://api.pmpcn.com
     ↓
DNS lookup: api.pmpcn.com (CNAME → gtm.pmpcn.com)
     ↓
F5 GTM resolves → dc1-ltm.pmpcn.com or dc2-ltm.pmpcn.com
     ↓
VIP: 10.0.0.100:8443 (DC1) or 10.1.0.100:8443 (DC2)
     ↓
Load balanced to: VM1 or VM2 in that DC on port 8443

Testing Setup

Test DNS resolving to GTM

# DNS Resolution
dig api.pmpcn.com
OR
# CNAME Resolution
nslookup api.pmpcn.com

api.pmpcn.com should resolve to gtm.pmpcn.com (CNAME)

Test GTM resolving to LTMs

dig gtm.pmpcn.com

Test LTM connectivity

ping 
nc -vz  8443
curl -vk https://:8443/actuator/health

Summary of Commands

Purpose	Command Example
DNS Resolution	`dig api.pmpcn.com`
CNAME Resolution	`nslookup api.pmpcn.com`
GTM FQDN Test	`dig gtm.pmpcn.com`
LTM FQDN Test	`dig dc1-ltm.pmpcn.com`
Port Test to VIP	`nc -vz api.pmpcn.com 8443`
SSL Cert Validation	`openssl s_client -connect api.pmpcn.com:8443`
Backend Health API	`curl -vk https://api.pmpcn.com/actuator/health`
Trace Route	`traceroute api.pmpcn.com`
Direct Backend Check	`telnet 8443`

Telnet (for basic port check only)

This tests TCP connectivity to a host and port, it doesn’t understand HTTP or HTTPS:

telnet api.pmpcn.com 8443

Curl (for actual HTTPS request)

This checks the HTTP response from your app, including TLS handshake:

curl -vk https://api.pmpcn.com:8443

-v: verbose (shows headers)
-k: skip SSL certificate validation (useful if self-signed cert)

Summary

Action	Use This Command
Check if port 8443 is open	`telnet api.pmpcn.com 8443`
Send HTTPS request	`curl -vk https://api.pmpcn.com:8443`
Check specific API health	`curl -vk https://api.pmpcn.com:8443/actuator/health`

Configuring SSL Certs

Component	SSL Cert Needed?	Details
GTM	Usually No	GTM mainly handles DNS, not SSL termination.
LTM VIP	Yes	LTM usually terminates SSL for your public-facing service.
Backend VMs	Optional (Yes or No)	Depends if LTM does SSL termination or passes through.
Client URL	Yes (on LTM VIP)	The cert must match the public FQDN clients use (e.g., `api.pmpcn.com`)

What to secure	How to name it	Cert procurement method
LTM VIP SSL certificate	Use FQDN, not IP	Public CA for domain cert
Public service domain	FQDN (e.g., api.pmpcn.com)	Public CA or internal CA
Backend VMs (optional)	Depends on your architecture	Internal CA or self-signed cert

Steps to setup SSL for LTM (VIPs)

Create DNS A records pointing FQDNs to your VIP IPs

Hostname	Type	Value (VIP IP)
`dc1-ltm.pmpcn.com`	A	10.0.0.100
`dc2-ltm.pmpcn.com`	A	10.0.0.101

Get SSL certificates for these FQDNs from a trusted CA.
Configure your LTM VIPs to use these FQDN certs for SSL termination.

Your public service URL (e.g., api.pmpcn.com) should be a CNAME that ultimately resolves to your GTM, which then routes to the LTM VIP FQDNs/IPs.

SSL Termination at LTM (Backend VMs do not need SSL)

LTM VIP has the SSL cert for your public FQDN (api.pmpcn.com).
LTM decrypts SSL, forwards plain HTTP (or HTTPS) to backend VMs.
Backend VMs don’t need certs if traffic is HTTP, or can have self-signed certs if HTTPS is used internally.

SSL Passthrough (Backend VMS must have SSL)

LTM passes encrypted SSL traffic to backend VMs without decrypting.
Backend VMs must have SSL certs matching the FQDN (usually their own hostname).
GTM still doesn’t handle SSL, just DNS.