Which interface gets NAT inside and outside on an IOS VPN exit
Follow the decrypted client packet from the virtual interface to the uplink. Translation belongs on that inner flow, not on the tunnel's outer transport.
Routers providing a full-tunnel internet exit do two jobs that look like one. It terminates the tunnel, and it forwards the decrypted client packet out to the internet. Only the second job needs translation, and the translation has to match the inner flow. That distinction decides which interfaces carry the NAT roles and which address range appears in the rule.
Follow one packet through the router
Take a client at 10.90.0.25 opening a public HTTPS service. Whether that destination even enters the tunnel is the client's own policy decision. Once it does, the router decrypts the packet and delivers it to a virtual interface, from where it is routed to the public uplink.
That virtual interface is the inside of the translation. The public uplink is the outside. If the roles are inverted or missing, the packet either leaves with a private source or is dropped before it is translated.
| Stage | Question to answer |
|---|---|
| VPN client | Does the client's policy put this destination inside the tunnel? |
| Decrypted ingress | Which virtual interface receives the inner packet? |
| Internet egress | Which route, access policy and source translation apply? |
| Reply | Is the client's flow translated back before it is delivered over the tunnel? |
Match the translation policy to the client pool
The NAT rule has to name the range the clients actually receive, not the office LAN that happens to share the uplink. A rule covering only the local subnet misses remote clients even when both leave through the same interface.
ip access-list extended NAT-TUNNEL
permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overloadKeep private-site exceptions separate. Traffic to internal destinations must retain its original source, or the destination will reply to an address it cannot reach and the return leg will fail in a way that looks like a routing loop.
Apply the roles to the actual interfaces in the deployed design. A Virtual-Template fragment copied from an old Easy VPN answer is not a complete current configuration, and the tunnel type in use determines which interface receives the decrypted packet.
Keep outer transport and inner translation apart
Translating a decrypted application source is not the same operation as pushing IKE or protected packets through a NAT device upstream. The first changes what the internet sees as the source of the client's request; the second keeps a tunnel alive across a middlebox.
Confusing them produces two classic failures. A router that translates its own tunnel transport breaks the peer relationship, while a router that never translates the inner flow forwards private addresses to the internet. Read which flow you are looking at before editing a rule, and check whether the tunnel stayed up after the change. A rule that fixes browsing while dropping the tunnel has moved the problem rather than solved it.
Neither failure is fixed by changing the other. Read which flow you are looking at before editing a rule.
Verify at both boundaries
Read the application source at the internet boundary, and the restored destination on the return leg. The first tells you whether translation happened; the second tells you whether the reverse mapping came back to the right client.
Then test a client that uses an approved split-tunnel path. That client never exercises this router's internet translation, so it should behave differently, and the difference confirms which path the traffic took.
If both clients behave identically, the split-tunnel policy is not doing what the design says. Fix that before adding more translation rules, because a rule written for a path that is not in use hides the real problem.