pull-filter matches text, not subnets: read it as a prefix
The filter compares the start of each pushed option with your text. A missing space, a broad earlier rule and the wrong action produce different faults.
The intent was to drop one pushed route. After the change another routing option is missing, or the client reconnects in a loop. Both outcomes come from reading the filter as a subnet rule when it compares text. The client checks whether a pushed option begins with the characters you supplied, and no address logic is involved at any point.
What the filter actually compares
Each pushed option arrives as a line made of a name and its arguments. The filter compares your characters against the start of that line, before any address is parsed and before any route is installed. So a rule written for a name catches every option that begins with those letters, not only the one you were looking at. That is why a filter can look correct in isolation and still remove something unrelated.
A string that looks like a network range is still just characters. It selects no prefix, performs no arithmetic on network bits, and cannot express a set of destinations. When such a rule seems to work and later stops, the pushed text usually changed shape.
One space changes the match set
The same option name with and without a trailing separator selects different lines. Without the separator the match stays open-ended, while with it the option name has to end exactly there before the arguments begin.
pull-filter ignore "route"
pull-filter ignore "route "The open-ended form also catches options that merely start with the same letters, which is how unrelated routing behaviour disappears along with the route you meant to drop. Copy the pushed line from the log before writing the filter. Keep an unmodified copy of the profile beside the edited one, because reversing a broad match is easier from a file than from memory.
Order and action produce different symptoms
Rules are evaluated in order and the first match decides the outcome, so a broad rule placed early makes every later specific rule unreachable. The action changes the failure as well: ignoring a match drops the option and the session continues, while rejecting raises an error that restarts the connection. A repeatedly pushed line combined with the rejecting action therefore produces a reconnect cycle. That cycle is easy to misread as a network fault, and the log line naming the matched option is what separates the two.
| Action | Effect on the session | How it gets reported |
|---|---|---|
| Ignore | Option dropped, session continues | Something is missing afterwards |
| Reject | Error raised, connection restarts | The VPN keeps dropping |
Record which line matched and which action ran. A dropped route and a restart loop need different repairs, and the note should say which one happened rather than leaving both open.
Check what the host installed
Read the applied routes after reconnecting, and test the destination you meant to preserve as well as the one you meant to remove. Dropping a pushed route supplies no replacement, so a resource can become unreachable by another path while the unwanted route is gone. If a name now resolves elsewhere, check whether the pushed resolver option was caught by the same broad prefix. A change that passes the test you ran and fails the one you meant is the normal outcome here.
Keep that difference in the ticket: the route you removed, the route you expected to keep, and what the table shows now. The next change will be judged against that record.
Do not treat it as a trust boundary
A filter over text is a configuration convenience, not a control against a server you do not trust. Formatting variations alone defeat it, which is why the manual limits that claim. When the server belongs to your organisation, correcting the push policy is clearer than accumulating local exceptions.
Write down why the local filter exists at all, so the next person can decide whether it is still needed. Filters accumulate long after the reason for them is gone.