OpenVPN AF_INET Warning: Harmless Fallback or Failed Socket?

Two OpenVPN log lines open with the same words, and only one of them reports a problem. Could not determine IPv4/IPv6 protocol. Using AF_INET is a fallback notice: the profile left the address family open, so the daemon picked one and carried on. The failure branch reports that no socket was created and asks for a restart. Everything after the shared prefix separates them, so read past it before you change anything.

What the fallback notice reports

OpenVPN accepts an explicit family through proto udp4 or proto udp6, and accepts proto udp when the family should be derived at startup. In the second case the daemon inspects the local bind information and chooses.

When that derivation works, the warning states which way it went and the process proceeds to create the socket. A server with proto udp on a dual-stack host lands on IPv4 this way quite often. Nothing in that path is an error, and nothing in it hints at an attack, a missing web server or a rejected account. The line is useful only because later checks should compare against the family it names.

Treat it as an answer to one question, not a diagnosis. It tells you which family this process chose, and nothing at all about why a client cannot connect.

What the failure branch looks like

Later in the same socket code there is a branch where no socket exists at all. It logs the shorter address-family message and requests a restart, because there is nothing left to continue with. The opening words match the fallback; the outcome does not.

Tell them apart by what follows. If the daemon keeps running and reports its listener, the line was information. If it exits or restarts in a loop, the conversation is now about the bind.

A grep hit is not a branch identification either. The phrase turns up in rotated summaries, in wrapped lines and in log excerpts people paste second-hand, so read the neighbouring lines and the timestamp order rather than the single match.

Check the listener instead of the warning

A running server answers the family question directly, without inference from log text.

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

Match the family, address and port against the profile. A 0.0.0.0:1194 row is IPv4 only, while a [::]:1194 row on a dual-stack host may accept both families depending on the bindv6only setting. If the profile says udp and the socket is IPv4, clients whose resolver returns only an AAAA record will fail before the tunnel is ever negotiated.

Then test from a client that resembles your users: same resolver path, same kind of network. A local connection from the server proves very little about traffic that crosses a NAT device or a firewall rule written for the other family.

When forcing a family is right

Pinning proto udp4 suits an IPv4-only deployment: an A-only DNS name, firewall rules for one v4 address, clients behind carriers that hand out v4 addresses only. It removes ambiguity and makes the next set of log lines predictable.

The same argument runs the other way for an IPv6-first estate, and udp6 in front of an A-only client base is a self-inflicted outage. Forcing a family just to silence a harmless warning is the classic version of this mistake, because you have changed who can connect in exchange for a calmer log.

Choose from the endpoints and the clients that must reach them. The OpenVPN 2.6 manual documents the transport forms, and the message is the output of that choice rather than an input to it.

Keep the record narrow

Write down the exact line with its timestamp, the effective transport setting from the running profile, the socket as the kernel reports it, and the next stage that failed. Those four items settle almost every question the message raises, and none of them needs a guess about unrelated services. They also survive a handover, which a screenshot of a grep does not.

Package suggestions that arrive alongside this warning are unrelated until an error names a missing executable.

If ifconfig is genuinely absent, the daemon says so by name when a script calls it, and that deserves its own investigation. The AF_INET line and a missing utility are different failures, and installing things to see whether the warning changes is how a clean host turns into a messy one.