Your IPv4 VPN rule says nothing about IPv6 traffic

An audit finds the tunnel filtered tightly for IPv4 and wide open for IPv6 on the same interface. Nothing was misconfigured in the sense of a typo; the rule set simply described one family and everybody assumed the other followed. It rarely does. Three conditions decide whether your rule actually covers both, and the first one is about the platform rather than the policy.

Condition one: does the platform have one table or two

Some packet filters keep IPv4 and IPv6 in completely separate rule sets, so a rule added to one has no effect on the other until somebody duplicates it. Others offer a family that matches both and translates the addresses per packet. A third group keeps one policy language but stores separate objects per family behind it.

Read the documentation for the filter you actually run, then list which tables exist and which one your change touched. Counting the rules in the IPv4 table answers a question nobody asked. Then list which tables exist and which one your change touched.

Condition two: where does the policy apply

Three places get confused with each other: the listener that accepts the tunnel, the path that forwards traffic onward, and the ordinary interface the client uses when the tunnel is not carrying a flow. A gateway can accept a session while dropping everything forwarded from it, and that looks like a broken tunnel rather than a filter. Remove that confusion before writing anything, because the three locations have different owners and different logs. Naming them in the change record is what stops a fix landing one layer away from the fault.

Write down which of the three your rule is meant to govern. A rule that protects the listener does not protect the forwarded path, and neither one closes the client's direct route. Note who owns each location, because the answer is a different team in most organisations.

Condition three: what should IPv6 do

Decide whether IPv6 travels through the tunnel, is blocked while protection is unavailable, or follows a documented exception. Each answer produces a different rule set, and leaving the question open is how a client with native IPv6 ends up reaching destinations outside the tunnel that it reaches inside it over IPv4.

Say the answer out loud before writing rules. Blocking is a legitimate choice for a tunnel that carries no IPv6, as long as it is deliberate and tested rather than the accidental result of an empty table. Anything undocumented will be re-decided by whoever touches the rules next, and usually in a hurry.

ICMPv6 is control traffic

Neighbour discovery and path feedback both ride on ICMPv6, so a blanket drop copied from an IPv4 habit breaks addressing and large transfers at the same time. A blanket allow is not the answer either, because it hands over a channel nobody is watching.

Follow the filtering guidance for the message types that matter and reject the rest with a reason. The failure that gets misdiagnosed most often is a missing Packet Too Big message, which shows up as a connection that opens and then stalls.

Proving it, one family at a time

Test an authorised request over each family separately, then repeat after a reconnect if the policy is supposed to survive the session. A test on an IPv4-only network cannot exercise an IPv6 route, so the pass tells you nothing about the leak you are trying to close. Watch the counters while the test runs, since a rule that never matches is not doing what its comment claims.

Change one scoped rule per attempt and keep the previous configuration to hand. Where a managed profile owns the policy, involve its administrator before editing locally, because the next check-in will overwrite a local fix and restore the leak.