How to set up a split-tunnel WireGuard configuration via AllowedIPs

The choice between address-based and app-based rules is covered in the overview of traffic-splitting methods.

Specify the required subnets in AllowedIPs

A peer is the other side of the connection, usually the VPN server. On sending, AllowedIPs selects the peer by destination address; on receiving, it acts as a filter, dropping packets with a disallowed source address. The route to the interface is created by the system or the client.

I recommend keeping the original configuration and then changing AllowedIPs in the existing [Peer]. For a full tunnel, the fragment looks like this:

[Peer]
PublicKey = <server public key>
AllowedIPs = 0.0.0.0/0, ::/0

To allow access to only two remote subnets, replace the list:

[Peer]
PublicKey = <server public key>
AllowedIPs = 10.0.0.0/24, 192.168.50.0/24

Keep the real key in place of the placeholder, along with the Endpoint and the rest of the configuration. Reconnect and check the remote device. A /24 mask denotes a range of 256 IPv4 addresses, /32 a single address. Write a subnet as the network address, e.g. 192.168.50.0/24; a single host as 192.168.50.7/32.

The table assumes the routes exist. Inside WireGuard, a packet with no suitable peer is dropped.

A full tunnel requires both entries: 0.0.0.0/0 and ::/0. For a split tunnel, separately choose IPv6 subnets or a direct IPv6 exit. Verify the result: some client modes block an unconfigured address family.

AllowedIPs accepts IP addresses, not website names. For domain-based splitting, v2rayN routing rules will come in handy.

For an editable WireGuard configuration, I recommend CitadelVPN: such configurations come with the MAX plan, and support helps with setup. For a router, check your model and firmware compatibility before choosing a plan. On the other plans, you connect through VLESS clients.

Exclude the local network from a full tunnel

For the task "internet via VPN, local network direct" you need a different list: AllowedIPs has no exclusion syntax. An entry such as 192.168.1.0/24 sends that network into the tunnel.

You need to enumerate ranges covering the address space minus the excluded network. In the official Android client, a setting does this for you:

Exclude private IPs — exclude private IP addresses.

It replaces 0.0.0.0/0 with a list of ranges, leaving 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16, among others, outside the tunnel. The Android client adds routes to the interface's DNS servers. The ::/0 entry is not affected by the toggle. After saving, check access to the printer by its IP.

Example: the printer 192.168.1.40 is directly reachable, but the remote network 192.168.50.0/24 is also excluded. If you need it via the VPN, add it back to AllowedIPs.

The Apple client's interface also provides an option to exclude private IPs. The client descriptions here are based on code checked on 21 October 2026; the store versions were not verified.

Take your client's specifics into account

Select applications on Android

If you do not need app-based splitting, you can skip this step.

In the tunnel editor, open the application selector. Two modes are available:

• Exclude: the selected apps work outside the VPN.
• Include only: only the selected apps have access to the VPN.

In the [Interface] section, these correspond to the parameters:

ExcludedApplications or IncludedApplications.

Having both lists at once is not allowed. AllowedIPs continues to apply to the selected apps as well. Check the external IP from both an included and an excluded app.

Check the kill switch in Windows

With a single peer, with 0.0.0.0/0 or ::/0 present, and without Table = off, the official client offers:

Block untunneled traffic (kill-switch) — block traffic outside the tunnel.

Unticking it replaces the IPv4 route with 0.0.0.0/1, 128.0.0.0/1, and IPv6 with ::/1, 8000::/1. The halves still cover the entire address family: the kill switch is disabled, but no split tunnel appears.

For a split tunnel, replace the halves with the required subnet and check access to it.

Keep the automatic routes in Linux

wg-quick automatically creates routes from AllowedIPs. This parameter in [Interface] disables that:

Table = off

You would then have to set the routes yourself via PostUp, and remove them via PreDown. I recommend the automatic mode. Check the path to a device:

ip route get 192.168.50.10

You should see the tunnel interface's name. The kill-switch example in the wg-quick manual is intended for a full tunnel: without adaptation it blocks the direct traffic you need.

With a classic manual full-tunnel setup, you need a route to the Endpoint — the server's external address — via the ordinary gateway: it must stay outside the tunnel. wg-quick handles the default route automatically through routing rules.

Fix errors and verify the result

The connection is established. Now check the actual list of addresses in Linux:

wg show wg0 allowed-ips

Replace wg0 with your interface name. The output should match the intended ranges. Then run four checks:

• open the remote device by IP;
• check access to your home printer or router;
• compare the external IPv4 and IPv6 with and without the tunnel;
• check name resolution and the route to the DNS server in use.

When private subnets are tunnelled, the browser's external IP usually does not change. A website loading proves nothing: the browser is equally happy with a wrong configuration.

If the home and remote subnets coincide, I recommend separating the ranges. Editing AllowedIPs will not resolve a conflict of identical addresses.

Frequently asked questions

What to keep in the working configuration

Specify the required subnets, keep the route creation in place, and configure IPv6 separately. Excluding a LAN means listing the complementary ranges or setting the routes manually. The two /1 entries cover all of IPv4 and do not by themselves create a split tunnel. Save the configuration after checking the routes and device reachability.