--- title: "WireGuard AllowedIPs explained: one setting, two jobs" description: "What WireGuard's AllowedIPs really does: it picks the peer for every outgoing packet and checks every incoming one. Worked examples for phones, laptops and servers." section: "Guides" group: "How the technology works" source: https://wrapvpn.com/en/guides/wireguard-allowedips-explained last_reviewed: 2026-11-03 --- # WireGuard AllowedIPs explained: one setting, two jobs You've set up WireGuard on a server at home, and now your phone either sends everything through it when you only wanted the lab, or reaches nothing at all. Both come down to one line, AllowedIPs, which quietly does two different jobs. TL;DR: AllowedIPs pairs each peer with a list of address ranges. When a device sends a packet, WireGuard hands it to the peer whose range contains the destination, and the most specific range wins. When a packet arrives, WireGuard decrypts it and drops it unless the table says its source address belongs to the peer that sent it. On a client, 0.0.0.0/0 and ::/0 mean everything; on a server, each device gets one narrow address. ## A small table that answers two questions Every WireGuard device keeps a short table: each peer's public key, and beside it a list of address ranges. That list is AllowedIPs. WireGuard's author calls the arrangement cryptokey routing, because it ties a key (who you are) to addresses (where your packets may go and come from). The keys themselves are covered in our WireGuard explainer; here we'll stay with the addresses. The table answers two questions. On the way out: which peer should this packet go to? On the way in: is this peer allowed to send a packet from that address? WireGuard's own site describes the list as a sort of routing table when sending and a sort of access control list when receiving. Most confusion about AllowedIPs comes from remembering only one of the two. Our running example is a small home lab. A server at home runs WireGuard at the inside address 10.0.0.1, with your home network behind it (10.0.1.0/24 in our example, where a file server sits at 10.0.1.20). Your phone is 10.0.0.2 and your laptop is 10.0.0.3. A quick word on the slashes, since everything below depends on them. The number says how many bits of the address are fixed. 10.0.0.2/32 is exactly one address; 10.0.1.0/24 is the 256 addresses from 10.0.1.0 to 10.0.1.255; 0.0.0.0/0 fixes nothing, so it matches every IPv4 address, and ::/0 does the same for IPv6. On a Linux machine you can see the whole table with one command, which prints each peer's public key followed by its ranges. *See the table on the server* ``` sudo wg show wg0 allowed-ips ``` ## On your phone: everything, or just the lab Start with the phone, which has a single peer: the home server. Here AllowedIPs decides what enters the tunnel at all. wg-quick and the official WireGuard apps turn each range into a route, so anything inside the ranges goes to the server and anything outside them takes the phone's normal connection. Option one is the catch-all. With 0.0.0.0/0, ::/0, every packet the phone sends, whether it's for the file server or a website, is encrypted to the home server, which passes it on. That's what a VPN app does: websites see the server's address instead of yours, and the café's Wi-Fi sees only encrypted traffic heading to one place. Option two is just the lab. With 10.0.0.0/24, 10.0.1.0/24, packets for the tunnel's addresses and the home network go to the server, and everything else, your browsing included, goes out the usual way from your own address. It's tidy when the tunnel's only job is reaching the file server, and no help at all on a café network you don't trust. The same line also works in reverse. With the lab-only list, a packet from the server claiming to come from some website's address is dropped, because that address isn't in the phone's list. With the catch-all, anything the server sends back is accepted, which is exactly what replies from websites need. *The phone's [Peer] section: pick one* ``` # Option 1: everything, IPv4 and IPv6 AllowedIPs = 0.0.0.0/0, ::/0 # Option 2: only the tunnel and the home network AllowedIPs = 10.0.0.0/24, 10.0.1.0/24 ``` ## On the server: one narrow range per device The server has a [Peer] block for each device, and here AllowedIPs runs the other way round: each device gets only its own inside address. A reply for 10.0.0.2 is encrypted for the phone's key, a reply for 10.0.0.3 for the laptop's, and there's never any doubt about who gets what. Why can't two peers claim the same address? Because the table has to give one answer. A reply for 10.0.0.2 can only be encrypted for one key, so WireGuard keeps the mapping one-to-one: give a second peer an address that another peer already has, and the address moves to whichever peer was given it last, quietly leaving the other without it. That's the classic copy-and-paste accident. You add the laptop by duplicating the phone's block, change the key and forget to change the address. The phone, which worked a minute ago, stops working, because 10.0.0.2 now belongs to the laptop. The laptop doesn't work either, because it sends from 10.0.0.3, which now belongs to nobody. *The server's peers* ``` [Peer] # Phone PublicKey = AllowedIPs = 10.0.0.2/32, 2001:db8::2/128 [Peer] # Laptop PublicKey = AllowedIPs = 10.0.0.3/32, 2001:db8::3/128 ``` ## The check that happens after decryption Now the second job, from the server's side. A packet arrives from the laptop. WireGuard first checks that it was sealed with the laptop's key and decrypts it, and only then looks at the address inside. The packet says it comes from 10.0.0.3, the table says 10.0.0.3 is the laptop, so in it goes. If the laptop sent a packet claiming to come from 10.0.0.2, the table would say that address is the phone's, not the laptop's, and the packet would be dropped on the spot. One peer can't pose as another, even though both are on the server's list. That gives the server something genuinely useful: inside the tunnel, a source address is proof of who sent the packet. A firewall rule on the server saying only 10.0.0.2, arriving through the tunnel, may reach the file server really does mean only the phone, because nothing else can produce a packet from 10.0.0.2 that survives this check. ## When ranges overlap, the most specific one wins Ranges are allowed to overlap. When they do, WireGuard picks the longest match: the range with the most fixed bits that still contains the address. It's how a postal sorting office treats a letter with a flat number on it, which goes to the flat rather than into the building's general pile. Suppose the laptop's entry on the server is written as the whole 10.0.0.0/24 rather than its single address, while the phone keeps 10.0.0.2/32. A packet for 10.0.0.2 matches both, and /32 beats /24, so it still goes to the phone. A packet for 10.0.0.9 matches only the laptop's range, so it goes to the laptop. Here's the subtle part. When a packet arrives from the laptop, WireGuard doesn't ask whether its source address is somewhere in the laptop's list. It asks which peer the table would choose for that address, and whether that's the laptop. So a packet from the laptop claiming to be 10.0.0.2 is still dropped, even though 10.0.0.2 sits inside the laptop's /24. The table always gives one answer per address, in both directions, so replies go back to the peer that really sent the packet. *Overlapping ranges on the server* ``` [Peer] # Phone: one address PublicKey = AllowedIPs = 10.0.0.2/32 [Peer] # Laptop: the whole range PublicKey = AllowedIPs = 10.0.0.0/24 ``` ## Three ways to get it wrong Most AllowedIPs trouble falls into three patterns, and only one of them stops anything working. The other two look fine until they don't. *The ::/0 mistake, and the fix* ``` # IPv4 only: IPv6 skips the tunnel AllowedIPs = 0.0.0.0/0 # Everything, both kinds of address AllowedIPs = 0.0.0.0/0, ::/0 ``` - Forgetting ::/0. With only 0.0.0.0/0, every IPv4 packet goes through the tunnel and IPv6 isn't mentioned at all, so on a network that has IPv6, traffic to sites that support it goes straight out over your normal connection, from your real address. Nothing looks broken, which is the problem. If you mean everything, write both. - Overlaps you didn't mean. Two peers with the same range is the copy-and-paste accident above. Its bigger cousin is a catch-all on one of the server's peers: wg-quick would treat it as a new default route and send the server's own internet traffic to that one device. - Treating AllowedIPs as a firewall. On the way in it checks where a packet claims to come from, not where it's going. With the phone at 10.0.0.2/32, the server will still forward the phone's packets to the laptop, the file server or the internet if its own routing allows it. To limit what a peer can reach, write a firewall rule on the server, which can trust the source addresses precisely because of the check above. ## What WrapVPN does with that line In WrapVPN there's nothing to configure. The app sends all of your traffic, IPv4 and IPv6 alike, through the tunnel to the location you picked, on iPhone, iPad, Mac, Android and Windows, so a forgotten ::/0 isn't something you can run into. That's option one from the phone example, chosen for you, and it comes with the trade-off you'd expect: there's no setting to leave particular addresses or apps out. On Windows, printers and other devices on your local network may be unreachable while you're connected, so pause WrapVPN for a few minutes, or disconnect, when you need them. Our guide to checking that your VPN is working shows how to see the result for yourself. Or install WrapVPN and try it on the free plan's three one-hour sessions a week. ## Questions ### What does AllowedIPs = 0.0.0.0/0 mean in WireGuard? 0.0.0.0/0 matches every IPv4 address. On a client, it means every IPv4 packet goes through that peer, and any source address coming back from that peer is accepted. It says nothing about IPv6, so add ::/0 if you want all traffic in the tunnel. ### Is WireGuard's AllowedIPs the source or the destination? Both, depending on direction. For outgoing packets, WireGuard matches the destination against every peer's AllowedIPs to choose who gets the packet. For incoming packets, it checks the decrypted packet's source address and drops it unless that address maps to the peer that sent it. ### Can two WireGuard peers have the same AllowedIPs? No. Each range can belong to only one peer, because replies to an address must go to a single key. If you give a second peer a range another peer already has, WireGuard moves it to whichever peer was given it last and the other one loses it, which usually shows up as that device suddenly getting no replies. ### Does AllowedIPs work as a firewall? Only partly. It stops a peer from sending packets under another peer's address, but it doesn't limit which destinations a peer can reach through the server. For that you need a firewall rule on the server, which can rely on the source addresses AllowedIPs has already checked. ### How do I send only some traffic through WireGuard? List only the ranges you want in the client's AllowedIPs, such as your home network and the tunnel's own addresses; everything else then uses your normal connection. WrapVPN doesn't offer this: while you're connected, it sends all of your traffic, IPv4 and IPv6, through the tunnel. --- Source: https://wrapvpn.com/en/guides/wireguard-allowedips-explained Last reviewed: 2026-11-03