Publishing an internal service over an ASA site-to-site VPN

Publishing a service that lives behind a site-to-site VPN is one task with five failure points, and they fail in a fixed order. The tunnel comes up, the translation matches, the branch answers, and the reply comes back through the same path. When any one of those is wrong the browser shows the same thing: a connect that hangs or resets. Work the list top to bottom and stop at the first check that fails.

Check 1: the tunnel protects the origin address

Start from a tunnel that already passes traffic, then confirm the address you plan to publish sits inside the protected range. On an ASA that range comes from the crypto ACL or from the routes of a VTI, and it has to cover the origin's real address rather than the subnet the branch uses for management. A selector that misses the origin gives you a tunnel that is up and a flow that never enters it.

Confirm with the tunnel counters and the route table before you touch translation. If the origin is not reachable from the hub across the tunnel, nothing later in this list can repair it.

Stop here if the protected range and the origin address disagree.

Check 2: decide what source the branch will see

The branch sees either the original client address or a translated one, and that choice decides the return path. Preserving the client address reads cleaner in the origin logs, but the branch must then send replies for public clients back through the tunnel; an ordinary internet default sends them the other way and the connection dies in one direction. Translating the source to an address the branch already routes over the tunnel removes that requirement.

Translation also changes what the origin can log and what source-based rules can match. If the application needs to know the human behind a request, that belongs in an authenticated reverse proxy, not in a NAT decision.

Check 3: write the translation against the real interfaces

An ASA evaluates translation rules in order and reports which one matched, so the interface pair inside the rule is not cosmetic. A rule written for an outside-to-inside path will not match a flow whose ingress and egress differ from the ones you assumed.

The path you are building has four legs, and all four have to agree:

Treat the ranges in that table as placeholders. What matters is that the tuple after translation is an address the branch accepts over the tunnel, and that the reverse mapping exists in the NAT state so the reply gets restored on the way out.

Check 4: scope the access rule to the published port

Publish the port, not the host. A rule that permits the origin on every service turns one published application into a path to everything the origin runs, including the management interface you kept off the internet on purpose. Permit the published port from the translated source to the origin, and leave administrative services on their VPN-only path.

Check rule order at the same time. A broad permit sitting above your specific rule makes the specific rule invisible.

Check 5: trace one request and its reply

Do not start with a browser, because a browser hides which leg failed. Trace the flow on the hub and read the result before you change anything.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

The trace names the translation that matched, the access rule that allowed or denied the flow, and whether the packet was routed into the tunnel. If it shows the flow leaving an interface you did not expect, the interface pair in the NAT rule is wrong. If it shows a deny, the rule order is wrong. If it reaches the tunnel but the origin never answers, the branch return path is the problem.

Then send one real request from outside and confirm the reply comes back through the same tunnel. Record the published entry, the translation, the protected address pair and the return route as the publication record.