Fail2ban on a VPN Gateway: What It Does and Does Not Fix

Every exposed service gets the same advice: put fail2ban on it. For a VPN gateway that advice is neither wrong nor sufficient, and treating it as a hardening checkbox is how people end up with a jail that blocks nothing useful. Fail2ban reads the failure records you point it at and asks an enforcement backend to ban matching sources. Its entire value depends on which authentication surface produced the record, whether the address in it is the real client, and what happens to everyone else behind that address.

What fail2ban is, mechanically

A filter matches lines in a log, a jail counts matches per source, and an action applies a ban through a firewall backend. Three moving parts, each of which can be wrong independently.

None of the three touches the authentication path: fail2ban reacts to evidence after the fact and never validates a credential itself. A jail can therefore run cleanly while the surface it names stays exactly as exposed as before.

The tunnel listener is not a login form

An OpenVPN listener protected with tls-auth or tls-crypt drops packets lacking the control-channel protection before ordinary TLS processing begins. A scanner that never has the key generates nothing your filter can count. Certificate authentication adds another gate, because there is no password to guess. The Fail2ban project documents a general log-driven model, and a generic VPN filter does not turn an unauthenticated packet into a meaningful failure event.

If the gateway accepts only certificates, the brute-force story you are defending against may not exist on that port at all.

So which surface are you protecting?

The same host often exposes three different things: the tunnel listener, a client-profile or self-service portal, and an administration page. The portal and the admin page have password forms and produce log lines a filter can count. The tunnel may produce only handshake errors that mean something else entirely. Match the jail to the surface rather than to the product name.

One jail watching the wrong log is worse than none, because it creates confidence without coverage. Point a login filter at tunnel handshake errors and the counter fires on scanners that never had a key, while a password attack against the portal goes uncounted. Read the log line the filter matches before you trust the jail's number.

Source attribution is the weak link

A ban is only as good as the address it targets. When the service sits behind a local reverse proxy, the client address in the log may be the proxy, and banning it removes everyone. Trusting a forwarded header from an untrusted source hands an attacker the ability to ban arbitrary addresses. On UDP, source addresses can be spoofed, so counting them deserves more care than counting a completed TCP login.

Record the source-attribution method in the jail's README, because a forwarded header from an untrusted hop turns a ban into a weapon.

The collateral cost is other people

Several employees behind one office NAT share an address, so a single stale saved password can lock out the whole site once the threshold is crossed. The log shows one source and one account that failed, not a site-wide outage.

Short bans and modest thresholds reduce that, and a documented unban path reduces the support load when it happens anyway. The address is a coarse signal rather than an identity, and the person who files the ticket will describe the outage, not the threshold.

When to adopt it, and when to fix something else

Adopt it when there is a real, attributable, repeated online login failure on a surface you control, and when the enforcement backend actually covers that surface. Fix something else when the problem is a weak credential policy, a management page exposed to the internet, or an account that logs in successfully because it was compromised. A ban cannot repair any of those, and it cannot absorb traffic that already saturated your uplink. That last problem belongs upstream, with someone who can filter before the packets reach you.

Keep every jail tied to one surface, review false positives, and measure the authentication work avoided rather than the number of banned addresses.