Two ISPs, One Mail Server, Three Symptoms
Contoso Manufacturing has a two-member ClusterXL cluster at HQ with two ISP connections: 203.0.113.10 on ISP-A, which carries the default route, and 198.51.100.20 on ISP-B, which is used only by Policy Based Routing for traffic sourced from 10.10.30.0/24. The mail server 10.10.20.25 is published to 198.51.100.25 and must be reachable from the internet on 25 and 443; external senders deliver mail to it without problems. Three symptoms are open. (1) Internal users typing https://mail.contoso.com time out, although the same URL works over a mobile connection. (2) The SMTP relay 10.10.30.40 delivers to a partner that allowlists 198.51.100.20, but the partner logs show 203.0.113.10 and rejects the session with a 550. (3) A new web store 10.10.20.60 must accept inbound 443 on ISP-B only, and the security team does not want its outbound traffic to appear as 198.51.100.x. All NAT currently in use is automatic.
1. Diagnose why internal users cannot reach the mail server through its public address, and give two different fixes with their trade-offs.
Read the worked answer
Diagnosis. Internal clients resolve mail.contoso.com to 198.51.100.25. Their SYN is routed to the cluster on the internal interface, the destination is translated to 10.10.20.25, and the packet is forwarded to the server. The server's SYN-ACK replies directly to the internal client, bypassing the cluster, so the cluster never sees the reverse direction. The client's ACK then arrives at the cluster as an out-of-state packet and is dropped. Symptom fingerprint: TCP handshake partially visible in fw monitor, out-of-state drops in SmartLog, and works fine from outside. Confirm before changing anything.
Fix 1 – Split-horizon DNS. Publish an internal A record for mail.contoso.com pointing to 10.10.20.25. Zero NAT complexity, no cluster hairpin, but requires control of internal DNS and does not help clients that use external resolvers.
Fix 2 – Manual hairpin NAT. Above the automatic rules, add a manual rule: original source = internal networks, original destination = 198.51.100.25, translated source = an internal address that forces the server's reply back through the cluster, translated destination = 10.10.20.25. This works without DNS changes but adds state on the cluster and, on ClusterXL, must be checked so that both directions of the flow land on the same member. Prefer Fix 1 unless DNS is out of your control.
2. Why does the partner see 203.0.113.10 instead of 198.51.100.20, and how would you correct it without breaking the ISP-B failover path?
Read the worked answer
Why. Automatic hide NAT on a cluster translates behind a single address taken from the cluster object's NAT configuration, typically the primary external address 203.0.113.10 regardless of which interface Policy Based Routing selects. PBR chooses the egress path; it does not change the NAT decision. So traffic leaves through the ISP-B interface but is still source-translated to the ISP-A address, and the partner's allowlist rejects it.
Correction. Add a manual hide NAT rule above the automatic rules:
- Original: source 10.10.30.40 (or 10.10.30.0/24), destination = partner host object.
- Translated: source 198.51.100.20. Keep the destination specific so you do not accidentally source-NAT all of 10.10.30.0/24 behind ISP-B and lose return-path symmetry for other destinations.
Checks before install.
- 198.51.100.20 must be a cluster interface VIP that answers on ISP-B; verify ARP/proxy ARP.
- Confirm the return path for the partner's replies: ISP-B must route back to 198.51.100.20, and the cluster must not have an asymmetric flow.
- Verify the PBR rule for 10.10.30.0/24 still sends that traffic out ISP-B; a NAT change alone does not fix a routing mismatch.
- Test with a telnet to port 25 from the relay and confirm the observed source address on both ends.
3. Design the NAT for the new web store: inbound 443 on ISP-B only, outbound not appearing as 198.51.100.x. Explain rule placement and why automatic NAT is a poor fit here.
Read the worked answer
Why automatic NAT fails the requirement. Automatic static NAT is bidirectional: publishing 10.10.20.60 as 198.51.100.60 creates both a destination translation for inbound traffic and a source translation for the server's outbound sessions. The store would then appear to the internet as 198.51.100.60, which the security team has explicitly ruled out.
Design with manual rules, placed above the automatic rules.
- Rule A (inbound): original source Any, original destination 198.51.100.60, service https; translated destination 10.10.20.60, service https; install on the HQ cluster. Keep the service narrow so the rule cannot be reused for unintended ports.
- Rule B (outbound): original source 10.10.20.60, destination Any, translated source = the ISP-A external address (hide). Place it above the automatic rules so it wins.
Placement notes. NAT is first-match, top-down, so Rule A must sit above any generic hide rule that would otherwise translate the inbound session's source. Because 198.51.100.60 is not configured on the interface, add a manual ARP entry on the cluster object for that address, otherwise inbound connections never reach the gateway.
Validation. Test inbound 443 from an external host, confirm the log shows the translated destination, then test outbound from the store and confirm the far end sees the ISP-A address. Finally verify the ISP-B routing still prefers ISP-A for the store's outbound path.