What is WireGuard?

WireGuard is an open-source Layer 3 VPN tunnel protocol that creates encrypted IP connections between peers over UDP. Instead of negotiating a large menu of algorithms, WireGuard deliberately uses a compact set of modern cryptographic primitives and identifies peers by public keys. It is designed to make secure tunnels simpler to configure, audit and run efficiently on everything from phones and laptops to Linux servers and compatible routers.

The most important distinction is that WireGuard is a VPN protocol, not a VPN provider. WireGuard defines how peers establish and use an encrypted tunnel; the privacy, logging, exit location, DNS handling and internet access you receive depend on the service or network running the other end of that tunnel.

How does WireGuard work?

A WireGuard interface has a private key and can have one or more peers. Each peer is identified by a public key and is associated with AllowedIPs. When the operating system sends an IP packet to the WireGuard interface, WireGuard uses those AllowedIPs to decide which peer should receive it, encrypts the packet for that peer, and transports the encrypted packet inside UDP to the peer's current endpoint.

On receipt, WireGuard authenticates and decrypts the packet, then checks that its source address is permitted for that peer. This combination of public-key identity and IP routing policy is what WireGuard calls cryptokey routing. It is one of the protocol's defining ideas: routing and peer identity are deliberately connected rather than treated as unrelated configuration.

WireGuard can also update a peer's endpoint after receiving correctly authenticated traffic from a new source address. That roaming behaviour is useful when a phone moves between WiFi and mobile data or when a peer's NAT mapping changes.

What is inside a WireGuard configuration?

• PrivateKey: the private key belonging to the local WireGuard interface. It must be kept secret.

• PublicKey: identifies a remote peer. Public keys can be distributed; private keys cannot.

• Endpoint: the remote IP address or hostname and UDP port used to reach a peer. It can be learned dynamically in some peer-to-peer scenarios.

• AllowedIPs: determines which destination addresses are routed to a peer and which source addresses that peer is permitted to send through the tunnel.

• ListenPort: the UDP port on which a WireGuard interface listens when it needs to receive unsolicited traffic.

• PersistentKeepalive: an optional periodic authenticated packet, commonly useful when a peer behind NAT needs its mapping kept alive.

What does AllowedIPs actually do?

AllowedIPs is easy to misunderstand because it serves two related purposes. For outgoing traffic it acts as a routing selector: a destination matching a peer's AllowedIPs is encrypted for that peer. For incoming traffic it acts as a source-address check: decrypted packets are accepted only when their source address is permitted for the authenticated peer.

Practical example: if Peer A has AllowedIPs 10.20.0.0/24, traffic for that subnet can be sent to Peer A, and packets received from Peer A are expected to use addresses that match its permitted ranges. A full-tunnel client commonly uses 0.0.0.0/0 and, where IPv6 is also tunneled, ::/0 so default-route traffic can be sent through the VPN.

Does WireGuard use UDP port 51820?

WireGuard transports tunnel packets over UDP. Port 51820 is widely used as a conventional example and default in common tooling, but WireGuard is not technically restricted to that port. An administrator can choose another UDP port. The important requirement is that the remote peer can reach the listening endpoint.

If you run a WireGuard server behind a home router, you may need port forwarding for the selected UDP port unless the router itself is the WireGuard endpoint. Our port guide explains what the port number represents.

WireGuard, NAT, dynamic IP addresses and CGNAT

A peer that initiates an outbound WireGuard connection usually works through ordinary home NAT because the router creates a UDP mapping. Hosting a directly reachable WireGuard endpoint is different: unsolicited inbound traffic must be able to reach the server.

A changing public address can be handled with Dynamic DNS (DDNS) so a client can use a hostname rather than repeatedly editing an endpoint IP. Understanding the difference between a public IP address and a private IP address is especially useful when diagnosing inbound WireGuard access.

If your broadband connection is behind carrier-grade NAT, conventional IPv4 port forwarding on your own router cannot create a path through the ISP's upstream NAT. Possible alternatives include usable public IPv6, obtaining a public/static IPv4 service, using an externally reachable relay or VPS, or choosing an overlay VPN product designed to traverse NAT. The correct option depends on the ISP, access network, product and location.

WireGuard vs a commercial VPN service

WireGuard supplies the tunnel protocol. A commercial VPN service supplies infrastructure and operational policy around it: servers, exit IP addresses, DNS, apps, authentication, account systems and usually multiple locations. A self-hosted WireGuard server at home gives you encrypted remote access to your home network, but internet traffic exiting through that home connection still uses your home public IP.

WireGuard vs OpenVPN and IPsec

• WireGuard has a deliberately small protocol surface and fixed modern cryptographic choices rather than broad algorithm negotiation.

• OpenVPN typically runs in user space and supports a much wider range of configuration and authentication options; performance depends heavily on implementation, cipher, hardware and operating system.

• IPsec is a suite of standards with multiple modes and key-management options. It is deeply supported across enterprise networking equipment but is operationally different from WireGuard's compact peer model.

• No protocol is automatically fastest in every deployment. CPU, kernel support, packet size, MTU, routing, server load, broadband speed and distance to the endpoint can all become the bottleneck.

How much overhead does WireGuard add?

Techie Broadband calculation: a typical WireGuard data packet adds protocol overhead around the original IP packet. The exact on-wire overhead depends on whether the outer transport is IPv4 or IPv6 and on lower-layer framing, so there is no single universal percentage. As an illustration, adding roughly 60 bytes of outer IPv4/UDP/WireGuard overhead to a 1,500-byte packet is about 4% relative to the original packet size; smaller packets experience a higher percentage overhead. This is an explanatory calculation, not a guaranteed throughput penalty.

Real-world VPN speed loss can be much larger or smaller than that packet-size example because encryption processing, endpoint capacity, route changes, congestion, MTU and the underlying broadband connection matter. WireGuard being efficient does not make the tunnel faster than the slowest relevant part of the end-to-end path.

What MTU should WireGuard use?

The tunnel MTU must leave room for WireGuard and outer IP/UDP headers. A value that is too large can lead to fragmentation or path-MTU problems; a value that is unnecessarily small increases packet overhead. Many implementations choose a sensible MTU automatically, so manual tuning should be driven by evidence such as broken large transfers, specific path constraints or encapsulation layers rather than guesswork.

What WireGuard does not guarantee

• Anonymity: encryption between peers does not by itself define who operates the endpoint, what is logged or what identifying information an application sends.

• Faster broadband: a VPN cannot increase the physical capacity of your FTTP, FTTC, cable, mobile or fixed-wireless access connection.

• Protection after the tunnel endpoint: traffic leaving a VPN server continues towards its destination; HTTPS and other end-to-end encryption remain important.

• Automatic DNS privacy: DNS behaviour depends on client configuration and the VPN deployment.

• Inbound reachability: a home WireGuard server still needs a reachable path through public IPv4, IPv6, NAT and firewall policy.

Where is WireGuard useful on UK broadband?

• Remote access to a NAS, home server, router administration interface or other private service without exposing each service directly to the internet.

• A site-to-site tunnel between two homes, offices or lab networks.

• A commercial VPN connection from a compatible router so selected household devices use the tunnel without installing an app individually.

• Secure access back to a home network while travelling, provided the home endpoint is reachable.

• Connecting cloud servers, VPS instances and private subnets with a compact encrypted Layer 3 tunnel.

WireGuard performance on a UK full-fibre connection is not determined by the access technology alone. A 1 Gbps or multi-gigabit FTTP service can expose limits in the router CPU, VPN endpoint, NIC, operating system or remote server. On slower connections the broadband line may remain the limiting component. Always consider the complete path.

How to troubleshoot a WireGuard tunnel

1. Confirm both peers have the correct public keys and that the private keys have not been swapped, exposed or copied incorrectly.

2. Check that the endpoint hostname or IP address resolves to the intended public address and that the UDP port is correct.

3. If hosting behind a router, verify the UDP port-forwarding rule and local firewall policy. If the connection uses CGNAT, establish whether inbound IPv4 is possible at all.

4. Check AllowedIPs on both peers. Incorrect or overlapping routes are a common cause of a tunnel that handshakes but cannot reach the intended network.

5. Inspect the latest handshake and transfer counters. No handshake points towards reachability, keys, endpoint or firewall issues; a handshake with one-way traffic points more towards routing, firewall, NAT or AllowedIPs.

6. Test the tunnel IP address first, then the remote private subnet, then DNS, then internet routing if the configuration is intended to be full tunnel.

7. If only some sites or large transfers fail, investigate MTU and path-MTU behaviour rather than immediately blaming the ISP.

8. Test with wired Ethernet where practical so WiFi instability is not confused with VPN behaviour.

WireGuard security and key handling

A WireGuard private key is effectively an identity credential for that interface. Treat configuration files containing private keys as secrets. If a private key is exposed, generate a replacement key pair and update the affected peers. Public keys are designed to be shared with the peers that need them.

WireGuard uses a deliberately opinionated suite of modern cryptographic constructions rather than allowing arbitrary cipher negotiation. The official protocol documentation specifies Curve25519 for elliptic-curve Diffie-Hellman, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing, SipHash24 for hashtable keys and HKDF for key derivation.

Authoritative WireGuard documentation

The primary technical reference is the official WireGuard protocol documentation and the project's WireGuard whitepaper. These describe cryptokey routing, peer identity, endpoints, roaming and the protocol's cryptographic design.

WireGuard FAQs

Is WireGuard a VPN?

WireGuard is a VPN tunnel protocol. It can be used to build a self-hosted VPN, site-to-site VPN or commercial VPN service, but it is not itself a subscription VPN provider.

Is WireGuard TCP or UDP?

WireGuard transports its encrypted tunnel packets over UDP. Applications inside the tunnel can still use TCP, UDP or other IP protocols normally.

Does WireGuard hide my IP address?

If your internet traffic exits through a remote WireGuard peer, websites normally see the public IP address of that exit path rather than your local broadband public IP. That outcome depends on routing and deployment; WireGuard itself does not promise anonymity.

Does WireGuard work with IPv6?

Yes. WireGuard carries IPv4 and IPv6 packets. Whether your particular VPN deployment routes IPv6 correctly depends on its addressing, AllowedIPs, routes, DNS and endpoint configuration.

Can WireGuard work behind NAT?

Yes for many client-initiated connections. Hosting a directly reachable server behind NAT may require port forwarding, and CGNAT can prevent ordinary inbound IPv4 unless another reachable path or relay is used.

Is WireGuard always faster than OpenVPN?

No. WireGuard is designed for efficiency and can perform very well, but actual throughput depends on hardware, implementation, route, endpoint capacity, MTU and broadband conditions.

Do I need port forwarding for WireGuard?

Not always. A client initiating a connection usually does not need a manual forward. A WireGuard server behind a NAT router generally needs the selected UDP port forwarded unless the router itself terminates the tunnel or another traversal method is used.

Key takeaway

WireGuard is a compact modern VPN protocol for creating encrypted Layer 3 tunnels between peers. Its public-key peer model, UDP transport and AllowedIPs-based cryptokey routing make the configuration conceptually different from older VPN stacks. For UK broadband users, the practical questions are not just whether a device supports WireGuard, but whether the endpoint is reachable, whether routing and DNS are correct, and whether the router and remote peer can process traffic fast enough for the broadband tier.

To explore the related technical concepts used in this WireGuard guide, visit our broadband terminology guide.