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 <VIP IP>
nc -vz <VIP IP> 8443
curl -vk https://<VIP IP>: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 <VM IP> 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
- 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
- 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.