ASA: VPN Port and DMZ Static PAT on One Public IP

Two services, one public address, and a DNS name that feels like it reserves a port. It does not. Before you publish a DMZ server beside the VPN entry on an ASA, write down the entry tuples and check them in order; the first field that matches an existing service is where the plan stops. Everything below assumes the VPN terminates on the appliance itself, not on an inside server.

Write the five fields before you write the command

For every public entry, record the address family, the public address, the transport, the public port, and the owner. The owner is either an ASA-local service or a translated inside server. Two entries may share an address and still be different tuples, and two entries may look different in a diagram while colliding on the appliance.

Keep a second column for the real port, the one the inside server actually listens on. The public port and the real port are independent choices, and the moment you collapse them into one column you lose the ability to read your own translation later.

Read the real and mapped positions correctly

Start from the tuple you already have, not from the server you want to add. An illustrative split keeps the approved VPN entry on public TCP 443 and publishes a DMZ HTTPS server on public TCP 8443 while that server keeps listening on 443:

Public TCP 443  -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443

In the deployed command, the real service and the mapped service sit in fixed positions, and reversing them describes a different mapping rather than a broken one. That is the most common way a working translation turns into a puzzle: the configuration is valid, it simply points somewhere else.

Cisco's ASA 9.16 NAT guide documents static PAT, interface-address use and the real versus mapped port meanings. Read the section for the release you actually run; a command remembered from an older platform is not a complete current configuration.

Count transport as part of the reservation

TCP 443 and UDP 443 are different tuples, and that difference does not hand you the UDP one for free. A VPN may have separate TLS and DTLS listeners, and other configured services may already hold the transport you want. Inventory the effective listeners and the access policy instead of assuming the web page is the whole VPN entry.

A second hostname that resolves to the same address does not resolve a transport-level collision either. DNS is a name-to-address mapping, not a port broker, and publishing a server through PAT is not the same operation as moving the VPN listener to another port.

If the VPN entry genuinely has to move, four things change together: the client profile, the public URL, the upstream filtering and every transport the deployment uses. Do them in one window instead of one at a time. Keep a separate management path to the appliance open before you touch the service you use to reach it. Without a second path, the move is a change you cannot back out of from outside.

Verify from outside with fresh connections

Permit only the intended DMZ application under the effective access policy, then check the matching translation order, the server's return path, and the hostname on the certificate. PAT changes the network destination; it does not grant application access and it does not repair a certificate that names a different host.

Test both services with new connections from an authorized outside host: the VPN should still establish, and the DMZ request should reach its intended listener. An established session can keep earlier state, so it proves nothing about a mapping you changed a minute ago.

Close the loop by updating the entry inventory with what you deployed, including any listener you discovered rather than created. The next person to publish a service on that address will start from your table, and a wrong row there costs more than a wrong command here.