WireGuard connected but no traffic: troubleshoot LAN access and Internet

WireGuard says connected, or shows a successful handshake, but the resource you need still does not respond. Perhaps the remote LAN is unreachable, a service will not open, or Internet access stops when you enable the tunnel.

Start by finding which part of the connection works. A tunnel can be enabled without exchanging useful traffic; a successful handshake does not prove that the remote gateway can reach your server or return its reply. The checks below separate those stages before you change any settings.

The commands are for macOS and the examples use IPv4. You can follow the diagnostic with your existing WireGuard client.

Start with one destination and identify what fails

Choose one resource that should work: its IP address, the service and port, and its hostname if you use one. Confirm those details with the network administrator. Record which local network you are on and whether another VPN is active.

Tunnel enabled, handshake successful, service reachable: three different checks

These observations answer different questions:

• Tunnel enabled: the client has activated its tunnel interface.
• Handshake successful: an authenticated exchange with the WireGuard peer has taken place.
• Service reachable: the application you need has responded through the intended connection.

Try the actual service, then look at the client’s handshake information if available. Use the symptoms to choose your next check:

Where permitted, compare the same test with the tunnel enabled and disabled. A private office resource being unavailable without the tunnel is expected; that alone is not a fault.

All addresses and names below are fictional examples. Replace them with your administrator’s values before running a command:

The network probes make connection attempts, but do not change your configuration. Avoid regenerating keys, replacing DNS servers, adding a full-tunnel route or changing MTU until you have evidence for that change.

Check the handshake after a real access attempt

No successful handshake: check tunnel establishment first

Note the last handshake and traffic counters if your client exposes them. Attempt to access your chosen resource, then inspect them again.

An old handshake on an idle tunnel is not enough to diagnose a failure. WireGuard is quiet when there is no traffic to send. If the client does not expose handshake information, record it as unknown.

For an existing command-line installation that exposes its WireGuard interfaces, you can optionally use:

wg show

This reports interface and peer information, including handshake and transfer details. It is not a requirement: a Mac app’s tunnel is not necessarily accessible through this tool. Do not install another client or rewrite your configuration just to obtain this output.

If no successful handshake is visible after the access attempt, troubleshoot a tunnel that will not connect. Endpoint reachability, UDP access and peer configuration belong to that investigation.

A handshake succeeds, but the destination still fails

A successful handshake establishes an authenticated exchange with the peer. It does not establish access to the LAN behind it, a working return route, or a listening application.

Increasing transfer counters are useful observations, but they can include other traffic. They do not prove that your selected resource replied. Continue with its exact destination address.

Do not add PersistentKeepalive as a general repair. Its purpose is to maintain a NAT or firewall mapping when needed, as explained in the WireGuard quick start; it does not fix missing LAN routes or application permissions.

Check the route and AllowedIPs for the exact destination

Inspect the route macOS selects

Ask macOS which route it selects for the resource’s IP:

route -n get 10.42.0.20

Look at the reported interface, gateway and destination or mask where present. Does the route lead towards the intended tunnel, your local network, or another VPN?

A utun interface indicates a tunnel interface, but its number is not fixed and does not identify WireGuard by itself. Establish which active connection it belongs to before drawing a conclusion.

An unexpected route is a reason to inspect the configured prefixes and other active VPNs. A route through the expected interface makes the local routing choice plausible; it does not prove that packets reach the server or return. Proxies and other VPN policies can also affect the application’s path.

Check the exact IP rather than only the default route: a more specific route may apply to this destination. This command only looks up a route. There is no need to add, delete or flush routes during this check.

Check AllowedIPs on both peers

On the Mac’s peer configuration, does AllowedIPs include the destination address or its remote subnet? In this example, 10.42.0.0/24 includes 10.42.0.20.

There are two related layers. The system selects a route to an interface; once a packet is handed to WireGuard, AllowedIPs selects the peer for its destination. On receipt, it also restricts the source addresses accepted from that peer. The client or tooling sets up the system routes. See WireGuard’s cryptokey routing explanation.

The remote administrator should check the peer representing your Mac as well. Its allowed source addresses must include the Mac’s tunnel address, and replies must be directed to the correct peer. Do not copy the remote LAN prefixes into every peer indiscriminately.

Adding 0.0.0.0/0 to reach one missing host changes the routing scope; it is not a neutral fix. Nor does changing AllowedIPs open the remote firewall. For the underlying concepts, see DNS, routing and split tunnelling.

Check for overlapping local and remote subnets

Your local LAN uses the same range as the remote LAN

In macOS network settings, check your local IP address and subnet mask. Compare that range with the remote LAN.

If both use 10.42.0.0/24, the address 10.42.0.20 is ambiguous between two networks. Recheck the route to that exact address. Do not assume that the local LAN always wins, or that a tunnel always wins.

If permitted, repeat the test from a different local network. Success there strengthens the overlap hypothesis, but does not by itself prove the precise routing mechanism: other conditions also changed.

A durable solution may require the administrator to renumber a network or design an address-translation arrangement. An arbitrary host route is not a universal solution for identical addresses.

Another VPN also claims the destination

Compare the destination ranges of other active VPNs. Two tunnels may cover the same subnet, or one may cover a broader range containing your resource.

Where permitted, temporarily isolate the other VPN and repeat the same route and service checks. Change one condition at a time. Improvement points towards an interaction worth investigating; stopping one tunnel is not necessarily the long-term solution.

For coexistence options, see multiple WireGuard tunnels on macOS.

Check forwarding, firewall rules and the return path

The WireGuard peer is reachable, but its LAN is not

A remote peer can respond while the LAN behind it remains inaccessible. If ICMP is allowed, these optional probes can help compare the peer and the resource:

ping -c 3 10.77.0.1
ping -c 3 10.42.0.20

A reply confirms an ICMP exchange with that address. An unanswered ping does not prove that the host or its service is inaccessible: ICMP may be blocked. Test the intended service as well.

If the peer responds but the LAN service does not, ask the remote administrator to check:

• Whether the gateway forwards traffic between WireGuard and the LAN.
• Whether transit firewall rules allow the required destination and port.
• Whether the destination host permits connections from the VPN source.
• Whether replies have a route back to the Mac’s tunnel address.
• Whether the remote peer’s AllowedIPs match that address.

Allowing WireGuard’s external UDP traffic is separate from allowing decrypted traffic onwards to the LAN. A handshake can succeed while a transit rule blocks the service.

Return routing and NAT are different solutions

The destination’s reply needs a path back to the source it sees. With routed access, the relevant LAN gateway needs a route towards the Mac’s tunnel address. Depending on the topology, source NAT may instead make the connection appear to come from an address the LAN already knows how to reach.

Neither approach is a universal prescription. The administrator must choose the appropriate routing or translation design. Do not disable the firewall or add broad allow rules to find out.

From the Mac alone, you may not be able to distinguish a forwarding failure, firewall drop and missing return route. Remote logs or routing checks are needed to confirm which one is responsible.

If Internet stops working, check the full-tunnel path

Did you intend to send Internet traffic through the VPN?

Inspect the client configuration for AllowedIPs = 0.0.0.0/0, possibly alongside other prefixes. This covers all IPv4 destinations for that peer and expresses a full-tunnel intention when the corresponding routes are installed. It does not create a working Internet exit at the remote end.

For a known Internet service, obtain its correct IP from your administrator and look up the route to that exact address using route -n get, as above. Do not rely on an arbitrary public IP responding to ping.

If the full tunnel is required by your organisation, removing it is not an appropriate troubleshooting shortcut. If only office networks should use the VPN, confirm the intended split-tunnel prefixes before changing them.

Can the remote gateway forward traffic to the Internet?

For an intended full tunnel, the remote administrator needs to verify forwarding, outbound firewall rules, the WAN route and NAT where required by the topology.

Compare the same known service with the tunnel disabled if permitted. A failure tied to activation identifies a useful condition, not the exact cause. One public service failing also does not prove that every Internet destination is unreachable.

If connections to known addresses work but names fail, move to the DNS checks. If direct connections fail too, investigate the traffic path first; a DNS change cannot repair that failure.

Check DNS when addresses work but names fail

Separate name resolution from access to the service

This branch applies when the resource’s correct address is known and access to it works, while access by name fails or uses the wrong address.

Inspect the DNS configuration macOS currently reports:

scutil --dns

Look for the expected nameserver and domain-related entries. Search domains help complete short names; their presence alone does not prove that queries for an internal domain go to the intended resolver. This output describes configuration, not a successful lookup or a capture of the query actually sent.

The remote DNS server also needs a usable route:

route -n get 10.42.0.53

An expected route is a prerequisite, not proof that the DNS server answers.

For a known HTTPS service with a certificate valid for its hostname, you can compare normal resolution with a request using its confirmed IP:

curl -4 --noproxy '*' --connect-timeout 5 --max-time 10 -v -o /dev/null https://portal.office.example/
curl -4 --noproxy '*' --connect-timeout 5 --max-time 10 --resolve portal.office.example:443:10.42.0.20 -v -o /dev/null https://portal.office.example/

Replace the fictional hostname and IP in both commands. Use this test only where direct access is appropriate: --noproxy '*' bypasses explicit proxies, so it is unsuitable for a service that requires one.

The commands use IPv4, limit the connection and overall wait, show diagnostic details and discard the response body. The second substitutes the IP for that hostname and port while retaining the hostname for HTTP and TLS. It changes only this curl request, not the system DNS settings.

If normal resolution fails but the second request reaches the expected service, investigate DNS or the address normally selected. That comparison does not identify the responsible resolver automatically. If both fail, examine the connection or TLS errors rather than declaring a DNS fault.

Do not replace the hostname with https://IP/ and mistake a certificate-name mismatch for a tunnel failure. Keep certificate verification enabled. The commands also do not follow redirects, which could introduce another destination.

curl’s result is evidence for these requests, not proof of how every Mac application resolves names. Verify the original application afterwards. For resolver selection and search domains, see WireGuard split DNS on macOS.

Check the remote service and consider MTU only for partial failures

A reachable host does not prove the service works

Use the actual application and expected port. The HTTPS checks above are suitable for a known HTTPS service; use the intended client for RDP, SMB or other protocols.

Interpret responses at the stage they establish:

Ask the service administrator to check the listening port, address binding, host firewall and access rules. A closed port on one host is not evidence that the whole tunnel is broken.

Small exchanges work, but larger transfers stall

Consider MTU only when you have established a partial failure: small exchanges succeed, while larger responses or transfers repeatedly stall.

This can be consistent with an MTU or path-MTU problem, but packet loss, the service and other intermediaries can produce similar symptoms. Record a reproducible small-versus-large comparison and ask the administrator to investigate the path.

Do not choose an arbitrary MTU value as the first fix. A handshake or small ping succeeding does not validate larger transfers, and a stalled transfer alone does not identify MTU as its cause.

Verify the result and collect useful evidence

After a targeted, authorised change, repeat the original test with the same destination, port and hostname. Verify the actual application, DNS if relevant, and Internet access if it is expected. Make one change at a time and retain a way to undo it.

If the fault is intermittent, capture observations when it happens, including whether it follows sleep or a network change. That timing is useful evidence, not proof of a general macOS defect.

If you still need help, send the relevant administrator:

• The time, local network and exact resource or service that fails.
• The tunnel concerned and any other active VPNs.
• The handshake observation after an access attempt, or that it is unknown.
• The route to the destination and the service-test result.
• DNS observations where relevant, and what changes on another network or with the tunnel disabled.

Ask for a specific remote check when needed: forwarding, a firewall log, or the return route. Leave unobserved stages marked unknown.

Before sharing, remove private keys, preshared keys, passwords, tokens and unnecessary internal details. Verbose HTTP output can contain sensitive information. Do not post a complete configuration publicly; keep your private key safe.

A successful test validates the resource you tested in those conditions. The handshake returning by itself is not the final verification.

If you use Paart: observe resources and connection logs

If you already use Paart Client, its public features can help gather observations for this diagnostic:

• Resource checks show reachability and latency for configured resources on a connection. Their result is evidence about those checks, not a test of every service.
• Connection logs help collect and export information for investigation. Remove secrets and unnecessary network details before sharing them.
• Overlap notices flag overlapping networks Paart observes, giving you a reason to examine the address ranges and routes.

These observations do not automatically identify a routing, DNS, NAT or firewall fault. An overlap notice does not correct the conflict or decide which route wins. Use the checks above, and remote-side evidence where needed, to determine the next action.