Why the vpnc Route-Flush Warning Fires in a Container

Fresh container logs often end on a Read-only file system complaint about /proc/sys/net/ipv4/route/flush, and that line gets blamed for a tunnel that may be perfectly healthy. The write behind it targets a kernel entry that no longer does anything useful now that the IPv4 route cache is gone. Inside a container /proc/sys is mounted read-only, so the redirection is refused before any value lands and the shell prints that refusal. A working tunnel can print this warning for as long as the old line stays in the script, and --privileged never makes the write meaningful.

What the Script Was Trying to Flush

Older connection scripts finished with a cache cleanup: write a value into a kernel control file and ask the IPv4 stack to drop its routing cache, so a new tunnel route would be selected without waiting for stale entries to age out. The file was addressed under /proc/sys/net/ipv4/, which made the operation a shell redirection rather than a routing command. Kernel 3.6 removed that cache, and with it the reason the flush existed. Nothing in the current data path depends on that write.

The entry itself survived as a legacy write-only file, so a script that still writes to it reaches a real path and a real permission check. On a host the write returns success and changes nothing. In a container the same redirect hits a read-only /proc/sys and fails with EROFS, which the shell prints as the read-only filesystem message. On kernels where the path really is absent the wording becomes No such file or directory, and the conclusion does not change.

The two errors say different things, and the difference is worth keeping straight. Read-only file system means the kernel reached an entry and refused the write; No such file or directory means the entry is gone. Neither message reports on the tunnel device, the routes or name resolution, so neither one can justify more privilege.

Ordering is what makes the message look causal. A connection script installs routes, changes interface state and rewrites name resolution before it reaches the cleanup at the end, so the last line printed is the line people quote even when every step that mattered returned success. A tunnel that establishes and carries traffic while printing this warning fits the mechanism above exactly.

Check the Mount and the Route Before Adding Privilege

Three reads separate a cosmetic warning from a real failure: whether the installed script still carries the line, how /proc/sys is mounted, and where the application's traffic actually goes. Run them in the same container namespace or on the host where the warning appeared, since a check on an unrelated machine answers a different question.

grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10

The grep answer is weaker than it looks, because a hit proves the line is present and not that it runs unguarded; a maintained script can carry the write inside a guard that skips it. findmnt -no OPTIONS /proc/sys settles the mount directly, and ro in that output means every write below that point is refused whatever the script does. The route lookup then shows whether the destination the application needs resolves through the tunnel interface or through the container's default gateway. A lookup that picks the default gateway means the tunnel came up and nothing routes into it, which is a routing problem and not a privilege problem.

Where the Fix Actually Ships

The maintained fix lives in the script rather than the container flags. The upstream vpnc-script has changed how it handles this operation, so compare the copy inside the image with the current upstream and update through the package or image build that supplies it. A hand-edited file inside a running container is not reviewable and will not survive the next build.

--privileged is documented as granting all capabilities plus broad device access, a large concession for a message that changes nothing, so name the missing capability instead if one is genuinely absent. After the update, repeat the route lookup and let an application use the tunnel, because a quiet log and a working connection are separate results.