RDP Changes the Client: Why the Database Sees Another Host

Your VPN rule denies the database and the ticket gets closed as a firewall fault, while the same user opens a published desktop and queries that database without trouble. Both statements are true. The desktop is a different client, with its own address on a segment the rules already trust, and its own identity when it connects onward. What looks like a contradictory rule is usually a second request that no one put in the review.

The second request has its own client address

When an application inside the session opens a connection to the database, the TCP handshake starts at the session host. Its source address belongs to that host's network, so every router and database firewall along the path evaluates the desktop's segment rather than the tunnel pool your laptop came from. The VPN address never appears in that flow. That is why a source-based deny rule can be both correct and irrelevant at the same time.

Read the origin from inside the session rather than from the laptop, then test the onward path from the same place. The two answers should agree about which host is making the request.

whoami
ipconfig /all
Test-NetConnection db01.corp.internal -Port 5432

Compare what the session reports with the address the database recorded for the same timestamp. When the server log shows the desktop subnet instead of the tunnel pool, the question stops being whether the rule fired and becomes which host made the request. That is a different investigation with a different owner.

Identity changes as well as addressing

The onward connection usually authenticates as the session's token, a stored credential or an application service account, and the resource records whichever of those it was given. An audit trail showing a service account on the database therefore does not prove that a human ran the query. It does not identify the human either. Only the desktop's own session log ties those two records together.

Authorization happens twice, and the second decision is made with different inputs. The first grants a desktop sign-in for a named user, while the second grants whatever that user's token or the application's account can do to the resource. A helpdesk group that may open a desktop is not automatically a group that may read a customer table.

Look at the token and the delegation path before you write the access note. Both are visible from inside the session, which is the only place where the answer is not a guess.

whoami /groups
klist
query session

If the application uses a service account, its rights are the ones that matter downstream. Rotating that credential belongs in the access review, not in an operational afterthought.

Why the direct path is still blocked, correctly

The deny rule is not wrong just because the destination is reachable another way. Segmentation is evaluated per source, and the desktop sits on a segment that was allowed long before anyone thought of it as a route to the database. Nothing bypassed the policy. The policy simply describes two different sources with two different outcomes.

What the review has to answer is what every authorized session on that host can start. Browsers with saved sessions, mapped drives, agents holding credentials and locally listening services all extend the desktop's reach, and none of them appear in the ticket that granted the sign-in. That inventory is the real permission surface.

Enumerate it from inside a test session, not from a spreadsheet. A handful of commands covers most of the surface.

Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
net use
Get-ChildItem Env: | Where-Object Name -match 'PROXY|DATABASE|API'

Choose the boundary deliberately

Three shapes fit different tasks, and the choice should follow the task rather than the tool that happens to exist. A published application exposes one program with its own permissions, a full desktop exposes everything the user's profile can do, and a scoped database account with a source restriction exposes one resource without a desktop at all. The narrowest shape that still completes the work is the one to document. Anything wider needs a reason written next to it.

For a single report, a published application or a restricted account is a smaller grant than a general desktop. For maintenance that genuinely needs several tools, the desktop may be right, but then the approval describes the whole host rather than one application. Ask the resource owner which of those they are agreeing to.

Data movement is a separate switch. Clipboard, drive redirection and downloads can carry company data to the client, and running an application remotely does not keep data remote by itself.

Check both approvals and the removal path

Two approvals belong in the record: the right to reach and open the desktop, and the right to use resources from inside it. Name an owner for each of them and keep the second visible to whoever reviews the resource. That second entry is the one an auditor will ask about, because it describes reach rather than entry. Write both before the change is approved, not after the first incident.

Then test the removal, since a disconnected session can outlive the reason for it. The session table is the quickest place to see what is still running.

query session
query user
qwinsta /server:rdsh01.corp.internal

Disconnecting the client leaves the remote session running, and its network connections and cached credentials can stay usable until that session ends. Sign out, or end the session explicitly, and confirm that the downstream counter stops advancing afterwards. A removal test that only closes the laptop lid proves nothing. Run the same test once with the account disabled and once with the desktop permission removed, then record what the resource logged in each case.