Why a VPN rule cannot stop one file being uploaded
Reaching a service and controlling which files leave it are two requirements. Put the rule where the file is visible: mail, application or endpoint agent.
A small team asks for remote access to its work systems, and in the same breath asks that certain attachments stop leaving the company. Both requests sound like one VPN change. They are two requirements with different enforcement points, and a rule that satisfies the first does nothing for the second. Start by naming the action and the data, then pick the component that can actually see them.
One request, two requirements
The first requirement is about reachability: which users and devices may open a connection to which service. The second is about behaviour after that connection exists: which documents may be attached, pasted or uploaded. A tunnel operates on the first and is blind to the second by design.
An IP-level control forwards packets. It does not parse a multipart upload, inspect a PDF or decide whether a spreadsheet contains account numbers. Expecting it to do so is not a configuration mistake; it is a category mistake.
Say the requirement out loud in that shape before shopping for a product. "Users may reach the file portal" and "users may not upload customer lists to the file portal" are different sentences, and only the second one describes a content policy.
Choose the component that can see the file
Enforcement has to happen where the file is legible. For email, that is usually the mail platform or gateway, which already handles attachments and can evaluate them before delivery. For browser uploads to a sanctioned service, the application itself may be the only party that sees the content. For a managed laptop copying files to removable media, an endpoint agent sees the operation.
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
Some commercial remote-access suites bundle an endpoint agent, a web control and a data-loss prevention module. Those components may well enforce content policy, but the capability belongs to the module rather than to tunnelling. Read what the suite actually includes before promising the outcome.
Microsoft's Purview data loss prevention overview is a useful model to compare against: it describes policies in terms of sensitive information types, locations and activities. That vocabulary is about content and actions, not about IP prefixes.
TLS survives the tunnel, so plan for that
Application encryption is negotiated between the client and the service, and a VPN tunnel carries those bytes without opening them. A gateway on the path therefore does not automatically gain the ability to classify an attachment, however much of the route it owns.
To inspect content in transit you need a component that terminates TLS with a trusted certificate, which is a substantial architectural decision with its own privacy and operational consequences. It is not a checkbox on the VPN profile. Clients have to trust the inspecting certificate, applications that pin certificates will break, and the operator gains the ability to read traffic it previously could not. Those are the reasons this decision belongs to a security owner rather than to whoever runs the tunnel.
That is why the honest answer to "can the VPN block this upload" is usually no, followed by a concrete alternative. The alternative may be application-level restrictions, a mail rule, or an endpoint policy, and each of them has an owner who can change it.
Write the acceptance test before the rule
A content rule needs two examples, not one: a permitted action that must keep working, and a prohibited action that must be stopped. Test both from the applications and devices in scope, because a policy that only works in one browser is not the policy anyone asked for.
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadThe first request should be refused by whichever component owns the rule, and the second should succeed. If both succeed, the control is not in the path. If both fail, you have broken the service rather than protected it, which is the more common outcome of a rule written without a permitted example.
Decide in advance what the user sees, who can grant an exception and where an administrator confirms the decision afterwards. A blocked upload with no message produces a support ticket, and a rule nobody can audit produces an argument. Both are avoidable with a sentence of documentation written before the policy goes live.
Finally, keep the two requirements in separate tickets with separate owners. Bundling them under "VPN" guarantees that the network team will be asked to solve a content problem, and that the content problem will be declared solved when the tunnel comes up.