Anypoint VPN or Transit Gateway NAT: Where to Translate
Anypoint VPN does not translate addresses itself. Decide between a firewall PAT design, an AWS prefix map or a different attachment before you promise NAT.
A NAT requirement is not a requirement until it names the addresses that change and the component allowed to change them. On MuleSoft connectivity that decision has three inputs: whether the backend needs many-to-one port translation or a one-to-one prefix alias, whether the AWS attachment you actually own can perform that mapping, and whether the whole path stays inside a combination the vendor supports. Get those wrong and you build a working lab that fails review.
The one fixed point is that Anypoint VPN itself is not a translation device. CloudHub 2.0 documentation lists NAT as unsupported there, so any design that assumes the tunnel will hide your worker addresses is already broken.
Decide what the translation has to do
If many application workers must appear to the backend as a single address, the requirement is shared source translation, usually stateful SNAT or PAT on a firewall you control. That element has to sit on an approved path, keep its state for the life of the flow, and see the return traffic for every connection it rewrote. Losing state mid-session does not degrade the connection; it ends it. A firewall pair that refuses to share translation state will drop every session that lands on the standby member after failover. Size that element for concurrent flows, not for throughput.
If instead two networks overlap and each host needs a distinct alias, the requirement is a one-to-one address plan with unambiguous mapped prefixes, matching routes and name resolution that agrees with the mapping. Hiding every worker behind one address is not a cheaper version of that, and swapping one for the other in a design review is how projects lose a quarter.
Record the decision in concrete terms before you pick a product: original source, original destination, translated value, direction of initiation, translator owner and expected reply route. Add what identity the backend logs will retain, because a design that hides all sources also destroys per-client audit.
Check whether AWS can do the mapping for you
AWS now documents managed one-to-one NAT on Transit Gateway and Cloud WAN attachments, announced in late October 2026, so the old blanket claim that a transit gateway can never translate is out of date. The Transit Gateway NAT documentation describes a stateless IPv4 prefix mapping: original and translated prefixes keep the same length, and host bits and transport ports survive the translation. Read the ingress and egress directions as separate design decisions, because they are configured separately and one can be ready while the other is not. Nothing in that description implies per-flow state, so do not expect the mapping to track connections for you.
That means 10.80.0.0/16 mapped to 172.28.0.0/16 turns 10.80.10.23 into 172.28.10.23. It does not collapse the /16 into one address, and it does not replace a PAT requirement. It also covers selected attachment types, VPC and Site-to-Site VPN among them, but not Client VPN attachments, and the configuration lives with the transit gateway owner rather than with the Anypoint side.
Treat the feature as one more possible control point, not as proof that your deployment can use it. CloudHub 2.0 documents private-space attachments to a transit gateway in the customer's own AWS account, with regional and entitlement conditions attached, so confirm the real attachment type, its owner and the vendor support position before designing around the new option.
Keep the path inside a supported boundary
For a firewall translator, use that product's supported VPN, translation and routing model instead of pasting a generic NAT rule into a working tunnel. The backend's reply has to come back through the same translation element, and a healthy outbound tunnel says nothing about that reverse path.
For the transit gateway route, inventory the private-space attachment, the relevant route tables, the on-premises attachment and the pieces the customer can actually configure. It is a different connectivity architecture, not a NAT checkbox bolted onto an existing Anypoint VPN connection, and the support boundary moves with it.
Compare the three options in one table
Most teams only need to answer two questions: many-to-one or one-to-one, and who owns the attachment. The table below turns those answers into a starting option.
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
Read the third column as the review question, not as an afterthought. A prefix map that is allowed on paper but configured on an attachment you do not own is still a blocked project, and a PAT rule that passes traffic but breaks per-client logging fails the audit that follows.
Validate the mapping before you promise it
Send one fresh application operation through the path and confirm the reply, not just the request. Ask the backend owner which source address their logs recorded, check that address-family handling matches the plan on both directions, and verify one path that should be denied still is. A stale connection proves nothing about the mapping you just changed.
Keep backend authentication independent of whatever translated address satisfies its allowlist, because the mapping is network plumbing and not an access-control decision. The moment a password reset depends on a NAT prefix, every future range change becomes an outage.
Before sign-off, write down the three answers: translation type, translator owner, and the supported attachment or product path that carries it. If any one of them is still a guess, the design is not ready for a change window.