The status may merely mean that the client has created a network interface and set up paths for traffic. It does not guarantee that data reaches the server and comes back.
Where to start troubleshooting
Allow 5–10 minutes for initial diagnostics. Change one setting at a time and reopen the same pages each time: this way we can link the result to a specific action.
The main symptoms suggest where to look:
| Symptom | Check | What the result means | Next step |
|---|---|---|---|
| Nothing opens | The same pages without the VPN | The network itself may be at fault | Check the regular connection |
| Works by address, not by name | Access to the resource both ways | A DNS problem is likely | Check name resolution |
| Small things load, large ones stall | A short request and a file transfer | An MTU problem is possible | Check packet size |
| No access on Android even without the VPN | Blocking connections outside the tunnel | Protective blocking may be at work | Check the always-on VPN settings |
| Failure only in one network | Wi-Fi and mobile connection | Transmission conditions differ | Check the router, IPv6 and addresses |
1. Does the internet work without the VPN?
Disable the VPN on your device and open several pages. During the check, traffic may go direct. If there is no access, check the regular connection and whether a setting that blocks internet access without a VPN is switched on.
On Android, the always-on VPN mode can be combined with the "Block connections without VPN" option: the system then blocks traffic outside the tunnel. If the internet disappears after the VPN is enabled, this blocking may have come into effect while the tunnel was not working. This does not yet mean the Wi-Fi is broken.
On public Wi-Fi, the cause may be the sign-in portal: until sign-in or acceptance of the terms is complete, access is restricted by the network itself.
2. Does the resource respond by address but not by name?
The Domain Name System (DNS) translates a website's name into a numerical Internet Protocol (IP) address. If the DNS server assigned to the tunnel is unavailable, the browser does not know where to send the request.
Compare access by name and by numerical address to a resource that is known to support both. If the address responds but names do not resolve, suspicion falls on DNS. An arbitrary IP in the browser is unreliable for such a test: the site may require a domain name and produce a certificate error. Do not ignore it for the sake of the test.
In essence, we are separating address lookup from data delivery. DNS is set by the tunnel configuration, for example the DNS field in wg-quick; on Android, the VPN can also assign these servers. If you have changed them manually, save the values and check the client's recommended settings.
3. Do only large transfers stall?
The maximum transmission unit (MTU) limits the amount that passes through a network segment without fragmentation. The tunnel adds overhead headers, so less room remains for useful data. An overly large packet may fail to get through.
Normally, the path MTU discovery mechanism helps the sender reduce the size. If the network drops the necessary Internet Control Message Protocol (ICMP) messages, the connection can stall on the first large packet. RFC 2923 describes such a "black hole": short responses get through, but the file transfer stops.
Although stalled downloads can occur with other faults as well, MTU is still worth checking here. If the client allows it, save the original value, temporarily reduce it according to the instructions and repeat the download. There is no universal number. If there is no improvement, revert the setting.
3. Do only large transfers stall?
4. Do IPv6 and local network addresses differ?
Internet Protocol version 6 (IPv6) may be available in only one of the networks being compared. Check whether the client supports it: if it is handled incorrectly, part of the traffic can bypass the tunnel. The mere presence of IPv6 does not prove the cause of the failure.
Then compare the home router's subnet with the tunnel's addresses. Private addresses repeat across different networks: using the 192.168.1.0/24 subnet both at home and on the remote side can create an ambiguous route. Record the overlap for support before changing addresses.
5. What changes in another network or on another server?
Keep the same device and VPN profile, then compare the connections:
| Connection | What to compare with | What it helps to check |
|---|---|---|
| Home Wi-Fi | Mobile data | Router, addresses, IPv6 and differences in the route |
| Public Wi-Fi | Access before the VPN is enabled | The need to sign in to the network |
| Phone's hotspot | Home Wi-Fi | The difference between two paths to the internet |
| Mobile data | Your own Wi-Fi | Whether the failure depends on the mobile network |
The router may restrict the User Datagram Protocol (UDP) ports used by the VPN. If the VPN works on mobile internet but not on home Wi-Fi, continue with the separate guide.
Try another available server, then another supported connection method. This may restore access in the event of a server fault or transport restriction. There is no guarantee: the cause may lie outside your device. On a work device, an administrator changes the settings according to the organisation's rules.
What if only individual websites do not open?
If most pages load but fast.com or one app does not respond, resetting the entire network is premature. The service may restrict VPN addresses; DNS and packet size faults are also possible.
The scenario where only individual websites or apps fail to open is covered separately. If a service requires a direct connection, follow its rules and keep in mind that its traffic will travel outside the tunnel.
What information to send to support
If the internet works without the VPN and the DNS and MTU checks have not revealed the cause, review the configuration together with support. For a CitadelVPN connection, I recommend contacting the engineers via the CitadelVPN website: configuration help is included in the service.
Prepare the following details for your enquiry:
- State the system, and the client's name and version, as settings depend on the platform.
- Attach the check results and the error message, as the "connected" status does not show where the failure occurred.
- Hide keys and subscription links in screenshots, as they may grant access to the connection.
Frequently asked questions
Why does the client show "connected" if data is not getting through?
The indicator may reflect the completion of the interface setup. For example, wg-quick creates the WireGuard interface and sets the MTU and routes. This is not a check that websites load; in other clients the meaning of the indicator depends on the implementation.
Why is there no internet on Android even after the VPN is disabled?
Check the combination of always-on VPN and blocking of connections without it. According to the Android documentation, the block cuts off traffic outside the VPN. Temporarily disabling it allows you to test a direct connection, but removes the corresponding protection.
Does disabling IPv6 help?
It may help localise the problem, but it is not a universal solution. In RFC 7359, disabling IPv6 is considered a temporary measure against leaks. A permanent solution requires the client to handle IPv6 correctly.
Restoring access: the order of checks
Check the internet without the VPN, taking blocking of direct connections into account. Then separate a DNS failure from an unreachable route; if large transfers stall, check the MTU. Compare IPv6 and the subnets, retry the connection via another network and server. If the failure affects a single website, test it separately. Send the results to support if the failure persists.
Restoring access: the order of checks
It does not guarantee that data reaches the server and comes back.
Change one setting at a time and reopen the same pages each time