IPS Blocked a Database Over VPN: Scope the Exception
A VPN does not exempt inner database traffic from inspection. Compare signature suppression, source exclusion and category disabling before you choose.
Database connections inside a VPN still get blocked by the IPS, the event log names the cause, and the fastest repair looks like an exclusion. Before that, note what the tunnel actually changes. It protects traffic between its endpoints and then hands plain inner packets to whatever inspects the inside of the network, which is exactly where the signature fired. The tunnel is not an exemption, and the detection is not automatically wrong.
Decapsulation is where inspection resumes
Traffic leaving a tunnel arrives as ordinary IP packets addressed to the database host. Any intrusion-prevention device on that path evaluates them under its own policy, which is why a connection that crossed an encrypted link can still be dropped by a rule written for the inside network.
End-to-end TLS is the limit on that visibility. When the client verifies the database server's certificate, the inspection device processes the connection but cannot read the application payload, so a detection there matches metadata rather than query text. Skip that detail and every blocked connection looks like proof of deep inspection. Both facts matter: the device is not blind, and it is not reading everything either.
A detection is not a false positive by default
The signature exists to catch a pattern, and expected business traffic can still exercise a genuinely vulnerable code path. Match the recorded event to the application operation first: timestamp, inner source and destination, ports, signature identifier and the action taken. Those six fields also tell you whether the alert belongs to the connection that failed or to a neighbour that happened to be busy.
A few packets reaching the server does not identify the IPS as the cause, and a matching signature does not prove the client is legitimate. Both readings are guesses until the event is correlated with the client's own report. The correlated event is the evidence, and the database version is part of the judgement.
Three exception scopes and what each removes
The options differ in how much inspection they switch off, and the difference is larger than the interface of the setting suggests. Signature suppression removes one rule for the traffic it matches. Source exclusion removes inspection of everything from that address. Disabling a category removes a family of rules, sometimes across the whole policy.
| Scope | What it stops | What you give up |
|---|---|---|
| Suppress one signature | That rule, for the matching flow | One detection, reviewed against a version |
| Exclude a source address | All rules for that address | Every signature that address would have triggered |
| Disable a category | A rule family across the policy | Protection for unrelated hosts and services |
Prefer the first row whenever the product can express it. When it cannot, escalate the limitation rather than presenting a broad exclusion as a precise one; the person who approves it should see the difference in writing.
The scope you think you set
Translation changes what an exclusion covers. When several VPN clients appear behind one translated address, excluding that address exempts all of them, which is far wider than the single finding that started the investigation.
Check the effective scope rather than the form you filled in, and record the incident identifier beside the rule. An exclusion without a reason becomes permanent policy, and the next reviewer has no way to tell whether it still applies.
Re-test the operation and the boundary
Repeat the same harmless database operation and confirm the connection completes, then confirm that unrelated detections still fire on a test that should trigger them. Restoring connectivity is one acceptance criterion; keeping the intended boundary is the other.
nc -vz 10.40.7.25 5432
psql -h 10.40.7.25 -U app -d appdb -c "select 1"Write down what was excepted, why, and when to revisit it after the next signature update or application upgrade. A suppression that is re-read on a schedule is an engineering decision; one that nobody remembers is a slow expansion of the trust boundary.