Overlapping RFC1918 Subnets on a Shared ADC Platform
A managed service provider runs one MPX 8905 with six admin partitions, one per customer. Two new tenants are being onboarded and both use 10.20.0.0/16 for their web and application tiers. Tenant A runs a legacy Java application that writes the connecting TCP source address into an audit table and cannot be modified; today the ADC source-NATs to a SNIP and the audit trail shows the SNIP, which the auditor has flagged. Tenant B's servers use the customer's core router as their default gateway, and the customer will not add static routes or policy-based routing. Tenant C runs a latency-sensitive custom TCP service on port 8443 and has asked for direct server return so the ADC stays out of the return path. The platform team proposes solving all three with admin partitions and 'just enabling Use Source IP'. The data centre has one pair of core switches, client VLAN 100 and server VLAN 200; the ADC is not the default gateway for any server VLAN. Change windows are monthly.
1. Can admin partitions solve the overlapping 10.20.0.0/16 problem on this appliance? Justify the design you would propose.
Read the worked answer
No. Admin partitions isolate objects, policies, and administrator scope, but they do not give each partition its own routing table or its own IP address space. The appliance has one network stack, and the same subnet cannot be configured in two partitions on the same appliance; even if the configuration were accepted, return traffic for 10.20.0.0/16 would be ambiguous.
Options, worst to best:
Double NAT inside partitions. Workable in theory, but the tenant's application would see translated addresses, which breaks Tenant A's audit requirement in a different way, and it adds a translation layer nobody will remember during an incident.
One appliance per overlapping tenant. Two VPX instances on an SDX, or dedicated VPX/MPX appliances, each with its own IP space and default route. This is the clean answer: partitions stay for the tenants that do not collide, and the two colliding tenants get their own instance. Capacity is fine on an 8905 platform, but confirm the SDX or appliance licensing and the per-instance throughput and SSL budget before committing.
Re-IP one tenant. Sometimes politically easier than it looks, and always cheaper to operate than translation.
Whichever route is taken, record the limitation in the tenant onboarding checklist so the next 10.20.0.0/16 request is caught at design time rather than at cutover.
2. Tenant A needs the real client IP in the TCP source. What are the options, and which do you recommend given the customer will not change routing?
Read the worked answer
The application reads the TCP source address, so header-based solutions (an HTTP profile client IP header, or the PROXY protocol) are only viable if the application is changed to read the header. It cannot be, so the only mechanism that satisfies the requirement is Use Source IP (USIP), where the ADC opens the back-end connection sourced from the client's address.
USIP has a hard dependency: the server's reply goes to the client address, so the ADC must be in the return path. If the core router is the server's default gateway, replies bypass the ADC and the client receives packets from an address it has no session with. The requirement, as stated, is therefore not achievable without a routing change.
Options to put in front of the customer:
- Narrow PBR on the two application servers for the client ranges, pointing to an ADC SNIP. This is the least invasive: two hosts, an auditable rule, no core change. Recommend this.
- Move the server VLAN gateway to the ADC, which is cleaner architecturally but affects every host on the VLAN.
- Accept the SNIP in the audit log and compensate with application-side logging from the load balancer, which the auditor may or may not accept.
Also flag the side effects of USIP: connection multiplexing and reuse stop working, back-end connection counts rise, and the ADC must be able to route to all client addresses. Do not enable it globally on the appliance; bind it per service so other tenants are unaffected.
3. Tenant C wants direct server return for the port 8443 service. What does that require, and what does the tenant lose?
Read the worked answer
DSR means the ADC processes only the client-to-server direction, so both the configuration and the monitoring model change.
Requirements: the VIP must also exist on the server, typically on a loopback interface with ARP disabled; the ADC must forward at layer 2 (MAC-based forwarding, L2 mode or a VLAN with the servers) so the destination MAC is rewritten to the server while the destination IP stays the VIP; no source NAT on that service; and the ADC must have an ARP entry or static binding for the servers.
What is lost:
- No SSL termination. DSR cannot work with SSL offload, because the ADC never sees the server's response bytes.
- No return-path visibility. No AppFlow for that service, no response-time metrics, no server-side error codes, and TCP-level troubleshooting is one-directional.
- No HTTP intelligence. No content switching, no header rewrites, no compression, no caching.
- Persistence is ingress-only, and health checks need care: a monitor sourced from the ADC that the server answers via the core router may take an asymmetric path, so test the monitor explicitly or bind a monitor that targets the server's real address.
Verdict: acceptable for exactly this one latency-sensitive, non-HTTP service, provided the tenant signs off on the loss of visibility and the service stays out of any SSL-offload or content-switching policy. It cannot coexist with Tenant A's client-IP audit requirement in the same flow, and it must be documented as an exception in the platform standard.