Which RRAS site interface does an incoming tunnel pick?
RRAS picks an incoming site interface by peer address, username or certificate subject, so read that key separately from its enabled and connected states.
On a Windows server with several site-to-site interfaces, a console label is not just a note for humans. RRAS uses a specific field from the incoming connection to decide which logical interface answers it, and that field changes with the authentication method. Get the key wrong and you will rename interfaces until something connects by luck. The selection rule, the administrative state and the session state are three separate facts, and only one of them is about naming.
The myth: a renamed interface will match anything
The tempting fix when a branch cannot connect is to create or rename a site interface until it looks like the caller. That works for one authentication method and quietly fails for the others, which is why the same procedure gets passed around with contradictory results. A site interface is a logical connection object with its own destination, protected prefixes and state. It is not the physical adapter carrying the encrypted packets, so looking at network adapters tells you nothing about which site object was selected.
Selection also has nothing to do with ordinary remote-access users. If employee VPN clients dial in, they are a different role, and their usernames never participate in this mapping. Confirm which role the caller belongs to before reading anything into a familiar name.
Three authentication shapes, three selection keys
With a pre-shared key, the configured destination address of the interface is matched against the address of the incoming peer. The label can be anything, because the address carries the decision. With username-based authentication, the interface name is matched against the username presented by the caller. Here the label is the key, which is exactly why a rename can appear to fix one site and break another.
With certificates, the interface name is matched against the subject name in the presented certificate. The name has to correspond to that subject, and a pretty label invented by an operator will not do.
Two consequences follow. In the pre-shared-key arrangement only one interface can be enabled for a given destination, so two branches sharing one observed public address cannot both be served by duplicate entries. And whichever method you actually configured is the one that governs, no matter what the console suggests.
| Authentication in use | The field RRAS compares | Symptom when the two disagree |
|---|---|---|
| Pre-shared key | The peer address in the incoming connection against the interface destination | Renaming the interface changes nothing; a destination that does not match the caller stays unused |
| Username | The caller login against the interface name | A site with a friendly label never answers, while a differently named site may answer instead |
| Certificate | The subject name in the presented certificate against the interface name | An interface named after the office rather than the subject CN is never selected |
Enabled is not connected
Administrative status says whether the logical interface is allowed to operate. Connection state says whether a session exists right now. An enabled interface with no session is a normal resting state for a demand-dial link, and reporting it as a fault sends people chasing an outage that is not there.
Use a named lookup or the documented routing-domain lookup, but not both parameters together, and run it in the intended server context. If the interface you expect is absent from the first listing, the problem is upstream of state: nothing was selected at all.
Read the pair together rather than in isolation. A link that is meant to stay established and shows disconnected deserves investigation, while an idle demand-dial link that connects on demand is behaving as designed. Meanwhile an administratively disabled interface will stay dark no matter how many times the remote side reboots its router.
Neither value proves that authentication succeeded, that the negotiated protection matches, that routes were installed, or that the private application is permitted. Those are four different questions with four different answers.
Get-VpnS2SInterface | Select-Object Name, Destination, AdminStatus, ConnectionState
Get-VpnS2SInterface -Name 'Branch-A' | Format-List Name, Destination, AdminStatus, ConnectionStateRead the identity transaction before enabling anything
When an incoming caller maps to an interface you did not expect, the useful evidence is the identity it presented, not the list of disabled interfaces. Pull the recent remote access events and read the caller address, the authentication outcome and the selected interface name. A disabled interface may be a deliberately retired site or a prohibited partner. Enabling it to see whether one login error clears is a configuration change with routing and access consequences, so route the decision through the owner of that site relationship, along with its destination, protected prefixes and policy.
If the mapping really is wrong, correct the key rather than the symptom: fix the certificate subject or the interface name in the username case, and fix the destination in the pre-shared-key case. Then reconnect once and confirm the same caller now selects the intended object.
Get-WinEvent -LogName Application -MaxEvents 50 | Where-Object { $_.ProviderName -like '*RemoteAccess*' }Close the loop with a permitted operation
A green state is not acceptance. Once the right interface is selected, generate traffic that the design permits, from a host in one protected prefix to a host in the other, and confirm the reply returns through the same path. Run the same attempt from a host that should be refused, using Test-NetConnection -ComputerName 10.44.2.10 -Port 445 against a service the design excludes, and read the remote access events again. A site link that carries more than its intended prefixes, or that answers for a service the policy excludes, is a routing mistake that no amount of state checking will reveal.
Record the authentication method, the selection key and the permitted prefixes together in the site's runbook. The next engineer will meet the same three-value table, and the naming convention only makes sense once that context is written down.