Network error messages explained
Error messages from routers, VPNs, DNS servers and Linux, as they actually appear, with what each one means and what to check first. Every message here was produced in one of this site's labs; the link under each goes to the lesson that reproduces it, with the full output.
BGP
NOTIFICATION 2/2 (OPEN Message Error/Bad Peer AS)
The TCP session came up, but the AS number in the neighbour's OPEN message isn't the remote-as configured for it. The NOTIFICATION is sent by the side with the wrong configuration, so check remote-as on the router that logs sent. The session then cycles through Idle. Reproduced in Debugging BGP.
NOTIFICATION 4/0 (Hold Timer Expired)
No KEEPALIVE or UPDATE arrived for the whole hold time (180 seconds by default in FRR, and so in VyOS), so the router gave up. The session was up, so the configuration is fine: keepalives are being lost. Look for a link that fails without going down, a congested or policed path, an MTU problem, or a control plane too busy to send them. A session that drops every few minutes with this message is the classic sign. Reproduced in Debugging BGP; for faster detection, see BFD.
NOTIFICATION 6/1 (Cease/Maximum Number of Prefixes Reached)
The neighbour sent more prefixes than its maximum-prefix limit, so the router closed the session and holds it in Idle. Usually a leak on the neighbour's side, sometimes a limit set too low. Find out why before clearing it. Reproduced in Debugging BGP.
NOTIFICATION 6/10 (Cease/BFD Down), or "BFD down initiated"
BFD detected that the path to the neighbour failed, and took the BGP session down with it, usually within a second. This is BFD doing its job: look for the failed link. Shown in BFD on VyOS.
NOTIFICATION 6/7 (Cease/Connection Collision Resolution)
Both routers opened a TCP connection to each other at the same moment, and one of the two duplicate connections was closed. Harmless: the other one carries the session. Seen in Debugging BGP.
OpenVPN
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
The client's TLS handshake with the server never completed. On its own it says little: check the server's log. If the server logged nothing, the packets aren't arriving (firewall, wrong remote, UDP blocked). If it logged a tls-crypt error, the client's key is wrong. Reproduced in OpenVPN on Debian.
TLS Error: tls-crypt unwrapping failed from [AF_INET]…
On the server: a packet arrived that wasn't encrypted with the server's tls-crypt key. The client has an old or wrong .ovpn file; issue a new one. Reproduced in OpenVPN on Debian.
VERIFY ERROR: depth=0, error=certificate revoked
The user's certificate is in the server's certificate revocation list (CRL). Working as intended, if you revoked them. Reproduced in OpenVPN on Debian.
CRL: cannot read: crl.pem, then VERIFY ERROR: CRL not loaded
The server can't read its CRL file, usually because it runs as nobody and the file isn't world-readable after being regenerated. Every user is then rejected. chmod 644 the CRL. An expired CRL has the same effect. Reproduced in OpenVPN on Debian.
DNS
status: REFUSED
The server won't answer this question. From an authoritative server, it means the name isn't in a zone it hosts (it doesn't recurse); point clients at a resolver instead. With PowerDNS, a brand-new zone made with pdnsutil is also REFUSED until the zone cache refreshes or the server restarts. Reproduced in PowerDNS on Debian.
status: SERVFAIL
The resolver tried and failed. Read the Extended DNS Error (EDE) that dig prints with it: No Reachable Authority means it couldn't reach the authoritative servers; DNSKEY Missing or RRSIGs Missing means DNSSEC validation failed. If dig +cd (validation off) answers and a plain query doesn't, it's DNSSEC. Reproduced in PowerDNS on Debian.
AXFR chunk error: Server Not Authoritative for zone / Not Authorized
A secondary tried to transfer a zone and the primary refused, because the secondary's address isn't in the primary's list of allowed transfer clients (allow-axfr-ips in PowerDNS). The primary's log says client IP has no permission. Reproduced in PowerDNS on Debian.
WireGuard
No "latest handshake" in wg show, and 0 B received
WireGuard has no error message for this: it silently ignores packets it can't authenticate, and the server logs nothing. The keys don't match (wrong server public key on the client, or the client's public key isn't on the server), or UDP 51820 isn't getting through. Reproduced in WireGuard on Debian.
Linux and the network path
ping: sendmsg: Message too long
The packet is bigger than the outgoing interface's MTU and don't-fragment is set (ping -M do), so the kernel refuses to send it. Inside a tunnel this is expected for large packets: WireGuard's default MTU is 1420. Reproduced in WireGuard on Debian.
ICMP unreachable - need to frag (mtu 1400)
A router on the path can't forward a packet that large, and says so with the MTU it can handle. If the sender never adapts (because a firewall drops these ICMP messages), small requests work but large transfers hang: an MTU black hole. Never block this ICMP type (or IPv6's packet too big). Reproduced in Packets That Never Come Back.
From 192.0.2.10 icmp_seq=1 Destination Host Unreachable
The message comes from your own machine (or the last router): it asked for the target's MAC address with ARP and got no answer, so the host is down or not on that network. Reproduced in Linux Network Connectivity.
RTNETLINK answers: Network is unreachable
There's no route to that destination at all, not even a default route. Add the route, or check why it's missing. In a VPN setup this is often the office router without a return route to the VPN subnet. Reproduced in OpenVPN on Debian.
Connection refused
The packet reached the host, and nothing is listening on that port (the host sent a TCP reset). The network is fine: check the service. Reproduced in Linux Network Connectivity.
Connection timed out, or timed out: Operation now in progress
No answer at all: the packets, or the replies, are being dropped. Usually a firewall (which drops silently), a missing route back, or a host that's down. Compare with Connection refused, which proves the host is reachable. Reproduced in Linux Network Connectivity and, as a firewall lock-out, in nftables on Debian.