WireGuard AllowedIPs: Routing, Examples, and Common Mistakes

Every WireGuard tunnel lives or dies by one line in the config file: AllowedIPs. Get it right and traffic flows exactly where you want it. Get it wrong and you end up with a handshake that completes perfectly while every ping times out, or a “full tunnel” that quietly leaks your printer and NAS traffic onto the internet.

AllowedIPs controls two things at once: which destinations get routed into a WireGuard peer, and which source addresses are accepted from that peer, and most routing problems trace back to confusing those two roles. This matters whether you’re building a site-to-site link, setting up remote access to a home lab, or just trying to understand what happens behind the scenes when you connect through a service like VPNSoEasy.

We spend a lot of time explaining WireGuard® basics to people who just want private browsing without touching a config file, and AllowedIPs is usually where the questions start. If you want the full picture of how the protocol works before diving into routing specifics, our guide on what WireGuard is is a solid starting point. From here, we’ll walk through how AllowedIPs actually decides where your packets go, how to write full and split tunnel configs correctly, how to exclude a local network without breaking everything else, and how to track down traffic that mysteriously refuses to follow the route you set.

How Does AllowedIPs Decide Which Traffic a Peer Can Carry?

AllowedIPs works as a routing table for outbound packets and an access control list for inbound ones, and both jobs run off the same list of CIDR ranges. A WireGuard interface has no separate routing daemon. The addresses sitting in each peer’s AllowedIPs field are the only information WireGuard uses to decide where a packet goes and whether an incoming packet is legitimate.

Outbound Destination Matching vs. Inbound Source Validation

When an application sends a packet, the WireGuard interface checks its destination address against every peer’s AllowedIPs list. Whichever peer’s list contains that destination gets the encrypted packet, tagged for delivery using that peer’s public key.

Inbound works in reverse. After decrypting a packet, WireGuard checks the packet’s source address against the sending peer’s AllowedIPs. If the source doesn’t fall inside that peer’s allowed range, the packet gets dropped, even though the handshake and encryption were valid. This is why a server peer entry with the wrong tunnel address silently blocks a client that otherwise connects fine.

How System Routes and WireGuard Peer Selection Work Together

AllowedIPs entries also populate the operating system’s routing table. On Linux, wg-quick adds a kernel route for every AllowedIPs prefix you list, pointing it at the WireGuard interface. The OS routing table decides whether a packet reaches the WireGuard interface at all; peer selection inside WireGuard then decides which peer’s key encrypts it. A packet with no matching route never reaches the tunnel, and a packet that reaches the tunnel but matches no peer’s AllowedIPs gets dropped with a “no peer has allowed IPs” error in the kernel log.

Why the Most Specific Prefix Wins When Peers Overlap

When two peers have overlapping prefixes, the longer (more specific) prefix wins for any address inside it. A peer with 192.168.20.0/24 and another with 192.168.20.5/32 will send traffic to 192.168.20.5 through the second peer, while the rest of that /24 goes to the first. Two peers can’t claim the exact same prefix on one interface; that configuration produces undefined behavior and should be treated as a mistake to fix rather than a quirk to work around.

Which Addresses Should You Use for Full and Split Tunnels?

The AllowedIPs entry on a client peer decides whether you get a full tunnel or a split tunnel, and the two setups use almost opposite address strategies. A full tunnel routes everything through the VPN; a split tunnel routes only the specific destinations you name.

Client Full-Tunnel Example: 0.0.0.0/0 and ::/0

A full-tunnel client peer config looks like this:

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0

0.0.0.0/0 covers every IPv4 address and ::/0 covers every IPv6 address. Both need to be present for a genuine full tunnel; leaving out ::/0 means IPv6 traffic bypasses the VPN entirely while IPv4 stays protected.

Client Split-Tunnel Examples: One Host or Multiple Subnets

A split tunnel lists only the destinations you actually want inside the VPN. For a single remote host:

AllowedIPs = 10.20.0.1/32

For several internal subnets:

AllowedIPs = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

Everything outside those ranges continues to use the normal internet connection. Our IPv4 split tunneling guide covers how WireGuard’s approach to routing compares with other VPN protocols if you’re deciding what to build on.

Server Peer Example: a Client Tunnel Address and Its Routed LAN

On the server side, each client’s AllowedIPs entry should list only addresses that live behind that client, typically its own tunnel address plus any LAN it routes:

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.7.0.2/32

Copying a client’s full-tunnel or split-tunnel destination list into the server’s peer entry for that client is a common error. The server peer entry answers “what can this client send from,” not “what does this client want to reach.”

How IPv6 and DNS Can Bypass an Incomplete Tunnel

A tunnel that only covers 0.0.0.0/0 leaves IPv6 traffic free to leave through the regular network interface, which defeats the purpose of a privacy-focused VPN. The same applies to DNS: if your DNS server’s address isn’t included in AllowedIPs, queries can leave through the untunneled path even while other traffic is protected. Check the DNS = line against your AllowedIPs list every time you edit either one.

How Can You Exclude a Local Network From the Tunnel?

Excluding a subnet from a full tunnel means subtracting that subnet’s addresses from 0.0.0.0/0, because WireGuard has no built-in exclude syntax. This trips up almost everyone who wants a full tunnel but still needs to reach a printer or NAS on their home network.

Using an AllowedIPs Calculator to Subtract CIDR Blocks

Subtracting one CIDR block from a larger one by hand produces a long list of smaller blocks. Removing 192.168.1.0/24 from 0.0.0.0/0, for instance, yields a sprawling list of prefixes covering everything except that one subnet. An AllowedIPs calculator automates this subtraction and outputs the exact comma-separated list to paste into the peer config. This is the only practical option on platforms, like phones, where you can’t add OS-level routes after the tunnel comes up.

When a More Specific Route Can Preserve Local Access

On Linux and similar systems, there’s a simpler option: keep the broad AllowedIPs entry (even 0.0.0.0/0) and add a separate, more specific route for the excluded subnet pointing out the physical network interface instead of the WireGuard interface. Because routing tables favor the longest matching prefix, that explicit route wins for the local subnet while everything else still goes through the tunnel. Many desktop Linux setups already handle this automatically through wg-quick’s policy routing, so check the existing routing table with ip route before assuming you need to add anything.

Why DisallowedIPs Is Not a WireGuard Configuration Option

WireGuard’s configuration format has no DisallowedIPs field. Any workflow that talks about “disallowed IPs” is describing the subtraction math that happens before you write the config, not a setting you type into the [Peer] block. If a guide or tool shows you a DisallowedIPs line going straight into a .conf file, that output needs to be converted into the resulting AllowedIPs list first.

How Do You Check Routes and Fix Unexpected Traffic Paths?

A completed handshake confirms the two peers can exchange encrypted packets and nothing more; routing, forwarding, and firewall rules are separate layers that need separate checks. Most “WireGuard connects but nothing works” reports trace back to one of these layers rather than the tunnel itself.

Inspecting wg, ip route, and Policy Routing on Linux

wg show displays each peer’s AllowedIPs, endpoint, and last handshake time, which confirms whether the tunnel sees traffic at all. ip route shows which routes actually point at the WireGuard interface, which is useful for catching a route that didn’t get added or one that’s being shadowed by a more specific entry elsewhere. For full-tunnel setups, also check ip rule output, since wg-quick uses policy routing rules to keep the encrypted UDP packets destined for the VPN endpoint from looping back into the tunnel.

What wg-quick Adds and How MikroTik RouterOS Differs

wg-quick handles more than the interface. It adds kernel routes for every AllowedIPs prefix, sets up the policy routing needed for full tunnels, and runs any PreUp or PostDown scripts defined in the config, which is where NAT or firewall rules commonly get applied. MikroTik RouterOS takes a different approach: AllowedIPs still governs peer selection and filtering, but routes have to be added explicitly through RouterOS’s own routing table rather than being generated automatically the way wg-quick does it. Anyone moving a config from a Linux box to a MikroTik router should expect to add those routes by hand.

Checking Return Routes, Forwarding, NAT, and PersistentKeepalive

A client reaching a server’s LAN needs more than a correct AllowedIPs entry. The server needs IP forwarding enabled, a firewall rule permitting the forwarded traffic, and the LAN needs a return route back to the tunnel subnet, either through a static route on the LAN router or NAT/masquerading on the WireGuard server. Clients behind NAT or a restrictive firewall often need PersistentKeepalive = 25 to keep the NAT mapping alive between bursts of traffic; without it, the tunnel can appear to work, then stop responding until new outbound traffic revives it.

Connecting With VPNSoEasy Without Editing Peer Settings

VPNSoEasy handles all of this routing configuration on the server side. Customers install the VPNClient app from the dashboard, sign in with the VPN username and password shown there, pick a server location, and connect with one tap, with no AllowedIPs, config files, or peer settings to edit. That one-tap setup is part of why we built VPNSoEasy around WireGuard® in the first place: the underlying protocol is fast and lean, but most people don’t want to manage its config syntax themselves.

Matching Tunnel Routes to Your Privacy Needs

AllowedIPs is the setting that decides how much of your traffic a VPN actually protects, whether you’re running your own WireGuard server or connecting through a managed provider. A full-tunnel setup with 0.0.0.0/0, ::/0 protects every connection leaving the device, which suits public Wi-Fi and travel. A split tunnel limits the VPN to specific destinations, which suits accessing a home network or office resources without routing unrelated browsing through a remote server.

Running your own WireGuard server means you’re responsible for getting these ranges right on every peer, checking for overlaps, and keeping server and client entries from mirroring each other incorrectly. VPNSoEasy takes that configuration off your plate: the service applies full-tunnel routing automatically, encrypts the connection with WireGuard®, and backs it with a no-logs policy and unlimited bandwidth for $5 a month, with no long-term contract. If you’d rather not manage AllowedIPs lists and routing tables yourself, our pricing page has the details, and the plan includes a 7-day refund if it’s not the right fit.

Frequently Asked Questions

Does AllowedIPs automatically add routes to my operating system?

On Linux, wg-quick adds a kernel route for every prefix listed in AllowedIPs when the interface comes up. Raw wg commands without wg-quick don’t add routes automatically, so you’d need ip route add separately, and platforms like MikroTik RouterOS require routes to be configured independently of the peer’s AllowedIPs entry.

Can I put multiple subnets in one peer’s AllowedIPs?

Yes, list them separated by commas, such as AllowedIPs = 10.0.0.0/24, 10.5.0.0/24, 172.16.50.0/24. Each subnet can also go on its own line in the config file if that’s easier to read and maintain.

How do I exclude my local network from a full tunnel?

WireGuard has no exclude syntax, so you either subtract the excluded subnet mathematically using an AllowedIPs calculator and paste in the resulting block list, or add a more specific route for that subnet pointing out your physical network interface. The second approach works well on Linux, where wg-quick’s policy routing often already keeps local traffic out of the tunnel.

Why does my WireGuard handshake succeed but traffic still fail?

A handshake only confirms the two peers can exchange encrypted packets; it says nothing about forwarding, firewall rules, or return routes. Check that IP forwarding is enabled on the server, that the LAN has a route back to the tunnel subnet, and that AllowedIPs on both sides matches the actual tunnel and LAN addresses in use.

How do I allow WireGuard clients to access my local network?

Add the LAN’s subnet to the client’s AllowedIPs on the client side, enable IP forwarding on the gateway peer, and make sure the firewall permits traffic between the WireGuard interface and the LAN interface. The LAN also needs a return route to the tunnel subnet, either as a static route on the router or through NAT on the WireGuard server.

Can I edit AllowedIPs or configure split tunneling with VPNSoEasy?

VPNSoEasy is built for one-tap connection through the VPNClient app: you sign in with your VPN credentials from the dashboard, choose a server, and connect, with no peer configuration files to edit. The service covers up to 10 devices on a single $5-per-month plan with WireGuard® encryption and a no-logs policy.