WireGuard AllowedIPs: How to Exclude an IP Address or Private Networks

What “Exclude an IP” Means in WireGuard

A common WireGuard full-tunnel configuration includes this setting under a peer:

AllowedIPs = 0.0.0.0/0, ::/0

This broadly allows IPv4 and IPv6 traffic to be sent to that peer. In many client setups—especially those managed by wg-quick—it also creates default routes that send ordinary internet traffic through the WireGuard interface.

However, full tunneling is not always appropriate for every destination. You may need to:

• Keep access to a router, printer, NAS, or local server.
• Reach a company network through the normal LAN instead of the VPN.
• Send traffic to one public IP address outside the tunnel.
• Keep a service reachable through a separate gateway.
• Prevent private RFC 1918 networks from being routed over the VPN.

The key detail is that WireGuard has no universal DisallowedIPs or ExcludeIPs configuration directive. To exclude an address, you normally use IP routing. In some cases, you can also use multiple, more-specific AllowedIPs prefixes that represent everything except the excluded address or network.

The best approach depends on the operating system, client software, routing table, and whether you use wg-quick, a mobile WireGuard app, a network manager, or manual wg and ip route commands.

What AllowedIPs Controls in WireGuard

AllowedIPs is one of WireGuard’s most important settings, but it has two related functions that are easy to confuse.

Outbound peer selection

When WireGuard sends an encrypted packet, it uses AllowedIPs to determine which peer should receive it. If multiple peers match a destination, WireGuard selects the peer with the most specific matching prefix.

For example:

[Peer]
PublicKey = PEER_A_PUBLIC_KEY
AllowedIPs = 0.0.0.0/0

[Peer]
PublicKey = PEER_B_PUBLIC_KEY
AllowedIPs = 10.20.30.0/24

Traffic for 10.20.30.15 matches both peers, but /24 is more specific than /0, so it is associated with PEER_B.

This is WireGuard’s “cryptokey routing” behavior. It is separate from the operating system’s route lookup, which determines whether a packet enters the WireGuard interface at all.

Inbound source-address validation

For received traffic, WireGuard uses a peer’s AllowedIPs as a source-address allowlist. A decrypted packet claiming to come from an address outside that peer’s allowed ranges is not accepted as valid traffic from that peer.

As a result, changing AllowedIPs can affect more than outbound routing. If a server needs to send private-subnet traffic through a peer, removing that subnet from the peer’s AllowedIPs may also prevent expected return traffic or inbound packets.

How Route Selection and AllowedIPs Work Together

To exclude an IP from a WireGuard tunnel successfully, you need to understand two separate decisions:

1. The operating system chooses a route.
   The device evaluates routing rules and tables to decide whether the destination should use Wi-Fi, Ethernet, cellular data, or the WireGuard interface.

2. WireGuard chooses a peer.
   If the selected route sends traffic into WireGuard, the WireGuard interface uses AllowedIPs to choose the peer that may carry the packet.

Within a routing-table lookup, a longer prefix is normally preferred over a less-specific one:

• A host route such as 203.0.113.25/32 is more specific than 0.0.0.0/0.
• A LAN route such as 192.168.1.0/24 is more specific than 0.0.0.0/0.
• An IPv6 host route such as 2001:db8::25/128 is more specific than ::/0.

However, Linux policy-routing rules determine which table is consulted before longest-prefix matching occurs. wg-quick uses policy routing and a firewall mark for common default-route configurations. Custom ip rule entries, Table settings, VRFs, firewall rules, and kill-switch configurations can change the result.

That is why an explicit route outside the tunnel is often the simplest answer to a WireGuard exclude IP requirement. Keep the WireGuard peer’s broad AllowedIPs setting, then add a more-specific route for the destination through the normal network gateway. Verify the active rules and routing tables instead of assuming that the main table controls everything.

Exclude One Public IP Address From a Full-Tunnel Configuration

Suppose your WireGuard client sends all IPv4 traffic through the VPN:

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.net:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

You want the public address 203.0.113.25 to use your normal internet connection instead.

203.0.113.25 is a TEST-NET-3 documentation address reserved by RFC 5737. It is only a placeholder. Replace it with the actual public address you intend to exclude.

Use a host route outside the tunnel

Before connecting the VPN, identify the normal gateway and interface:

ip route get 203.0.113.25

An example result might show that traffic normally uses gateway 192.168.1.1 over eth0.

After the WireGuard tunnel is active, add a host route:

sudo ip route replace 203.0.113.25/32 via 192.168.1.1 dev eth0

Because /32 is more specific than the default route within the applicable lookup, packets for that address can use eth0 instead of the WireGuard tunnel. Other internet traffic continues through WireGuard.

Confirm the selected path:

ip route get 203.0.113.25

The result should show the physical interface and local gateway rather than wg0. With wg-quick or a custom policy-routing setup, also inspect the active rules and all routing tables:

ip rule show
ip route show table all

Make the exception persistent with wg-quick

On Linux, a wg-quick configuration can use PostUp and PostDown commands:

[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 10.0.0.2/32

PostUp = ip route replace 203.0.113.25/32 via 192.168.1.1 dev eth0
PostDown = ip route del 203.0.113.25/32 via 192.168.1.1 dev eth0

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

Replace the address, gateway, and interface with values from your network.

This example is intentionally static. A laptop that moves between home Wi-Fi, office Ethernet, and mobile tethering may use a different gateway or interface each time. In that situation, a fixed route command can fail or send traffic to the wrong place. Use your operating system’s VPN routing features, a route-management script that detects the active gateway, or separate profiles for different networks.

Do not confuse the VPN endpoint with an excluded destination

The WireGuard server endpoint must remain reachable outside the tunnel. Otherwise, the tunnel may try to send its own encrypted UDP packets through itself, creating a routing loop.

Some full-tunnel tools handle endpoint routing automatically. wg-quick, for example, uses policy routing and a firewall mark for common default-route setups. Other clients and manual configurations may require an explicit route to the endpoint’s public IP through the original gateway.

This requirement is separate from excluding an unrelated IP address. Always verify that both the endpoint and your intended exception use the correct route.

Exclude RFC 1918 Private Networks From WireGuard

RFC 1918 reserves these IPv4 address ranges for private networks:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

A full-tunnel VPN can route private destinations to the VPN peer unless more-specific local routes already exist. This can make a home printer, local router interface, NAS, or office service unreachable.

Route private traffic through the local gateway

If your local gateway is 192.168.1.1 on wlan0, these routes keep RFC 1918 destinations outside the tunnel:

sudo ip route replace 10.0.0.0/8 via 192.168.1.1 dev wlan0
sudo ip route replace 172.16.0.0/12 via 192.168.1.1 dev wlan0
sudo ip route replace 192.168.0.0/16 via 192.168.1.1 dev wlan0

In practice, you may not need all three routes. If you only need access to devices on your current local network, a narrower route is safer:

sudo ip route replace 192.168.1.0/24 dev wlan0

This keeps traffic for the directly connected LAN on Wi-Fi while allowing other private networks to continue using the VPN, if that is how the VPN is designed.

Why broad private exclusions can be risky

Excluding all RFC 1918 ranges assumes those addresses are meaningful and reachable through your local network. That may not be true.

For example, a workplace VPN may provide an internal application at 10.50.0.20. If you route all 10.0.0.0/8 traffic outside the WireGuard tunnel, that application may stop working because the local router usually has no route to the company’s private network.

Use the narrowest exception that meets your goal:

• Exclude one device: 192.168.1.50/32
• Exclude the local subnet: 192.168.1.0/24
• Exclude a known remote private subnet only when it is reachable outside the VPN
• Exclude all RFC 1918 ranges only when you understand the local routing consequences

Using AllowedIPs as a “Not This Address” List

Users sometimes search for a WireGuard allowedips calculator because they want to express “all IPv4 addresses except this IP” directly in AllowedIPs.

CIDR notation cannot represent “everything except one address” in a single prefix. The complement must be represented by multiple CIDR blocks.

For example, excluding 203.0.113.25/32 from the entire IPv4 address space requires a set of prefixes covering every other IPv4 address without overlapping that host. The list contains 32 prefixes for a single excluded IPv4 address.

This approach may be useful when a client only supports route behavior derived from AllowedIPs. However, it has drawbacks:

• The configuration becomes long and difficult to audit.
• An incorrect prefix can create a traffic leak or block legitimate traffic.
• The peer’s AllowedIPs still has inbound-validation implications.
• A route exception is usually simpler for a single host or local subnet.

The WireGuard AllowedIPs calculator is a vendor convenience tool, not an independent authority on routing correctness. Independently verify any generated output, especially for host-level or subnet exclusions.

When using a generated list, confirm that:

1. The excluded destination is not included.
2. Every destination that should use the VPN is included.
3. Your operating system has a route sending excluded traffic through the intended non-VPN interface.
4. The WireGuard server configuration permits the addresses and traffic your client expects to use.

Common Configuration Patterns and Caveats

Pattern: Full tunnel plus a local LAN exception

This is common when users want ordinary internet traffic to use the VPN but still need access to a router or local device.

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0

Then retain or add a local route such as:

ip route replace 192.168.1.0/24 dev wlan0

Many systems already install a connected route for the local subnet automatically. Check before adding another route:

ip route show

For wg-quick default-route configurations, also check policy rules and all routing tables:

ip rule show
ip route show table all

Pattern: Split tunnel for only a private remote subnet

If only a private office network should travel through WireGuard, do not use a default route:

[Peer]
AllowedIPs = 10.50.0.0/16, 10.60.10.0/24

The operating system must also route those networks to the WireGuard interface. wg-quick normally derives routes from AllowedIPs; a manual WireGuard setup may require explicit ip route commands.

All other traffic follows the device’s normal default gateway. This is usually easier to understand than building exclusions into a full tunnel.

Pattern: Full IPv4 tunnel but normal IPv6 connectivity

A configuration containing only:

AllowedIPs = 0.0.0.0/0

does not automatically tunnel IPv6 traffic. If the device has IPv6 connectivity, IPv6 traffic may use the normal network. Whether that is desirable depends on your network and privacy requirements.

For a full dual-stack tunnel, use both:

AllowedIPs = 0.0.0.0/0, ::/0

To exclude one IPv6 address, use a more-specific /128 route through the intended IPv6 gateway. For internal IPv6 networks, remember that IPv6 private-style addressing commonly uses Unique Local Addresses in fc00::/7, while link-local traffic uses fe80::/10. Do not exclude broad IPv6 ranges without confirming how your local and remote networks use them.

DNS may follow different rules

An IP route exception does not necessarily determine where DNS requests go. Your VPN client may:

• Push or configure a VPN DNS resolver.
• Use a local resolver.
• Use encrypted DNS through an application.
• Apply split-DNS rules for specific domains.

For example, you might route 192.168.1.0/24 outside the VPN but still use a DNS resolver reachable only inside the tunnel. Local hostnames may then fail to resolve even though the route is correct.

Check the configured DNS servers and test both name resolution and direct IP connectivity.

Troubleshooting a WireGuard Exclude IP Configuration

Check the route selected for the destination

On Linux:

ip route get 203.0.113.25

For IPv6:

ip -6 route get 2001:db8::25

The result should identify the expected interface and next-hop gateway. If it shows wg0, the exception route may be absent, less specific than another route in the relevant lookup, or installed in the wrong routing table.

When wg-quick, custom policy rules, or a kill switch are involved, inspect the routing rules and all tables as well:

ip rule show
ip route show table all

Check WireGuard’s current configuration

sudo wg show

Review the active peer’s allowed ips, endpoint, latest handshake, and transfer counters. A successful handshake only confirms that the tunnel can communicate with its peer. It does not prove that a particular destination uses the intended route.

Test the excluded address and a tunneled address separately

Do not use 203.0.113.25 as a live test target. It is a documentation-only TEST-NET-3 address and should not be reachable on the public internet.

First, use ip route get with the actual IP address of the service you intend to exclude. This confirms the local routing decision. Then test a hostname on a real server you control or are authorized to test:

curl --connect-timeout 10 https://your-real-hostname.example

Use a valid hostname and a valid TLS certificate for that server. Testing an HTTPS URL directly by IP address can fail even when the route is correct because certificates, virtual hosting, firewalls, and application policies may depend on the hostname.

To verify which egress path carried application traffic, check the source address in logs on a server you control or use a trusted IP-check service. Compare that result with a separate request to an ordinary tunneled destination.

Look for overlapping private networks

Address overlap is a frequent source of problems. If your home LAN is 192.168.1.0/24 and the remote VPN network also uses 192.168.1.0/24, the device cannot reliably distinguish local and remote hosts based on the destination address alone.

The durable fix is to renumber one network to a non-overlapping range. Route metrics and policy rules may provide a temporary workaround, but they do not remove the ambiguity.

Verify firewall and kill-switch rules

A kill switch may deliberately block all non-VPN traffic. In that case, a route exception alone is not enough: firewall rules may still drop packets leaving the physical interface.

Review firewall rules, VPN client leak-protection options, and endpoint security policies before assuming WireGuard itself is causing the failure.

For general service information, see ProxySocks5 VPN services. Route behavior should always be verified on the device that establishes the tunnel.

FAQ

1. Does WireGuard have a DisallowedIPs or ExcludeIPs setting?

No. WireGuard uses `AllowedIPs`, not a universal `DisallowedIPs` setting. To exclude traffic from a full tunnel, the usual solution is a more-specific operating-system route that sends the IP address or subnet through another gateway or interface.

2. Can I exclude one IP address from `0.0.0.0/0`?

Yes. The most practical method is to keep `AllowedIPs = 0.0.0.0/0` and add a `/32` route for the excluded IPv4 address through the normal gateway. A `/32` route is more specific than the default route within the relevant routing-table lookup, although policy-routing rules can affect which table is checked.

3. How do I exclude private IPs from WireGuard?

Add routes for the private subnet or subnets through the local network rather than the WireGuard interface. For local-device access, exclude only the actual local subnet where possible, such as `192.168.1.0/24`, instead of all RFC 1918 ranges.

4. Will excluding RFC 1918 networks break access to company resources?

It can. Many VPNs use addresses in `10.0.0.0/8`, `172.16.0.0/12`, or `192.168.0.0/16` for internal services. If you route those ranges outside the tunnel, your local router may not know how to reach them. Use narrow, intentional route exceptions.

5. Does changing AllowedIPs only affect outbound traffic?

No. `AllowedIPs` also acts as a source-address allowlist for traffic received from a peer. Removing a network from a peer’s allowed ranges can affect both outbound peer selection and whether inbound decrypted packets with that source address are accepted.