Can one WAN interface serve site-to-site and remote VPN?

One public address can front a branch tunnel and a pool of roaming users at the same time. It cannot front one shared admission rule. The branch peer and the roaming user differ in who they prove they are, how that proof is checked, what addresses they receive, and which prefixes may answer them. Once you treat the outside address as a transport detail rather than an identity, the design gets much simpler.

A quick sanity test: try to write both admission records before you touch the router. If a single match condition has to cover both, the policy is already ambiguous, and the first symptom will look like a routing or firewall fault when it is really an identity fault.

Two records before any configuration

The branch record is short and stable. It lists the peer address or certificate name, the pre-shared key or certificate trustpoint, the protected subnets on both sides, the tunnel interface, and the static route that sends branch-bound traffic into that tunnel. Every field is about one known peer and a fixed set of prefixes.

The roaming record is broader and more personal. It lists the client protocol and port, how a user or device authenticates, the address pool handed out on connect, the resources that pool may reach, split-tunnel prefixes, DNS servers pushed to the client, and any second factor. Each field answers a question about an unknown number of users rather than one gateway.

That difference in granularity is the whole reason the two roles diverge. A branch profile can safely trust a single key because the key belongs to one device at one site. A roaming profile that trusts one group key for everybody collapses per-user accountability, which is usually discovered later, during an incident review rather than during the rollout.

Where peer matching and authentication diverge

On IOS XE the IKEv2 profile carries the parameters that cannot be negotiated and the conditions used to select the peer. That means the branch side and the roaming side each need their own profile even when they terminate on the same interface and even when they share a crypto PKI. Cisco documents the profile, authentication and matching roles in its IKEv2 configuration guide for IOS XE 17.

The branch profile usually matches a narrow identity: a remote address, an FQDN, or a certificate subject. Something like match identity remote address 198.51.100.10 255.255.255.255 pins one peer, and authentication remote pre-share with a key that is stored per site is enough. Keep the match as specific as the peer inventory allows, because an overlapping wildcard higher in the selection order can pull branch traffic into the wrong profile.

The roaming profile cannot pin an address, so it matches a group, a key-id, or a certificate field, then hands the real user check to AAA or to the authorization policy attached to the profile. That separation matters: peer authentication answers whether the client is allowed to build a tunnel, and per-user authorization answers which pool and which resources it gets. Using the branch key as a universal login throws away the second answer.

Forwarding and translation need the same split

Admission and reachability are separate problems. A successful IKE and IPsec exchange proves the peers agree on keys; it does not create a route to the pool the client received. Remote-access pools therefore need a return path, either a static route pointing at the tunnel interface or a routing protocol that injects the pool summary. Branch prefixes usually arrive through the same routing process that serves the rest of the site.

Translation is where the two roles most often collide. Site-to-site traffic that must keep its private addresses needs a NAT exemption scoped to those two prefixes, in both directions. Roaming clients usually need their tunneled traffic exempted as well, but their internet-bound traffic either bypasses the tunnel through split tunneling or exits at the hub after NAT. Exempting everything that arrives from a tunnel is the classic mistake, because it also removes translation from traffic that genuinely needs it.

Keep the exemption rules as narrow as the admission rules. If a pool summary and a branch prefix overlap, the return path becomes ambiguous long before any packet is dropped, and the symptom shows up as one site intermittently losing a subnet rather than as a clean tunnel failure.

Acceptance cases that expose a crossed policy

Build four cases and run them in order. A branch host reaches a branch-only resource. A roaming client reaches the same resource through its pool address. A roaming client tries a branch-only prefix it should not touch. A branch peer tries to obtain an address from the remote-access pool. The last two are the ones that catch a shared profile, because they fail silently in normal monitoring.

Then confirm the data plane rather than the configuration. show crypto ikev2 sa and show crypto ipsec sa tell you which profile and selectors carried each flow, while show ip nat translations and the tunnel counters show whether the return path and exemption actually matched. A tracer or packet capture on the tunnel interface closes the loop.

Write the observed identity, pool address, and selected policy next to each result. The run is finished when every case maps to exactly one record, and no case needs a temporary exception to pass.