Unable to telnet using wireguard

Telnet fails over WireGuard because the client’s default route is often redirected through the VPN tunnel, but local LAN devices remain unreachable. This article explains how to configure split tunneling or adjust routing tables so that traffic to your local network bypasses the WireGuard interface while other traffic continues through the secure tunnel.

Understanding the Routing Conflict

When you establish a WireGuard connection, the configuration file typically includes a AllowedIPs directive set to 0.0.0.0/0. This setting tells the operating system to send all internet and private network traffic through the encrypted tunnel. While this is ideal for privacy when using public Wi-Fi, it creates a significant problem for local network management. If your target device (such as a router, NAS, or server) resides on the same physical subnet as your computer, the OS attempts to send those packets through the virtual WireGuard interface instead of the physical Ethernet or Wi-Fi adapter. Since the WireGuard peer does not have a route back to your specific local subnet, the packets are dropped, resulting in a timeout when you try to telnet. To resolve this, you must ensure that traffic destined for your local network is handled by the native network interface. This process is known as split tunneling. By excluding your local subnet from the AllowedIPs, you allow the OS to use its standard routing table for local communications while keeping remote traffic secure.

Identifying Your Local Subnet

Before modifying the configuration, you need to know which IP range represents your local network. On Windows, open Command Prompt and run ipconfig. Look for the IPv4 Address and Subnet Mask of your active network adapter. For example, if your IP is 192.168.1.50 and the mask is 255.255.255.0, your subnet is 192.168.1.0/24. On Linux or macOS, use ifconfig or ip addr to find similar information. Note this CIDR notation, as it will be used in the next step.

Configuring Split Tunneling in WireGuard

The most effective solution is to edit the WireGuard client configuration file. Locate the file with the .conf extension associated with your connection. Open it in a text editor and find the [Interface] or [Peer] section where AllowedIPs is defined. You need to change the value from 0.0.0.0/0 to include your local subnet followed by the rest of the world. For example, if your local subnet is 192.168.1.0/24, update the line to:

AllowedIPs = 192.168.1.0/24, 0.0.0.0/0

This syntax instructs the kernel to send traffic for 192.168.1.x via the normal interface and everything else via the WireGuard tunnel. After saving the file, restart the WireGuard service or reconnect the interface. The changes take effect immediately upon reconnection. If you are managing multiple interfaces, ensure that the order of IPs in AllowedIPs matches your priority needs, although modern kernels handle this efficiently. If you cannot modify the client config, you can achieve a similar result manually by adding a static route. However, this method is less persistent across reboots. On Linux, you might add a route like ip route add 192.168.1.0/24 dev eth0 before connecting. On Windows, use route add 192.168.1.0 mask 255.255.255.0 [Gateway_IP]. These commands override the default behavior temporarily.

Firewall and Service Considerations

Even with correct routing, telnet may still fail due to firewall restrictions. Telnet uses port 23 by default. Ensure that the target device has its firewall configured to accept incoming connections on this port. Many modern systems disable Telnet by default in favor of SSH for security reasons. If the target device runs Windows, check the "Turn Windows features on or off" menu to see if the Telnet Client feature is enabled. On Linux servers, verify that the telnetd service is running and listening. Additionally, some routers block broadcast traffic or ICMP, which can interfere with discovery tools, though direct IP-based telnet should work if routing is correct. If you are connecting to a device behind NAT on the remote end, ensure that port forwarding is correctly configured on the remote router to direct port 23 traffic to the internal IP of the target device. For users who frequently switch between home and office networks, consider using separate profiles for each environment. This avoids the need to constantly edit configuration files. You can maintain one profile with AllowedIPs = 0.0.0.0/0 for full tunneling and another with split tunneling for local access. Switching between these profiles ensures optimal connectivity regardless of your physical location. It is also worth noting that relying on Telnet exposes credentials in plain text. If possible, migrate to SSH for remote management. However, if legacy equipment requires Telnet, ensuring proper routing is the critical first step. For more complex network setups involving multiple routers, refer to our guide on troubleshooting Wireguard VPN connection issues on two routers to understand how nested tunnels interact with local routes. Similarly, if you are trying to access applications from different PCs without traditional remote desktop software, understanding these routing principles is essential for seamless integration.

Verifying the Connection

After applying the changes, test the connection by pinging the local device first. Use ping 192.168.1.100 (replace with your target IP). If the ping succeeds, the routing is correct. Then attempt the telnet session: telnet 192.168.1.100 23. If the connection hangs, check the firewall logs on the target device. A successful connection will display a blank screen or a banner indicating the service is ready. If you continue to experience issues, ensure that no other VPN software is interfering with the routing table. Conflicting virtual adapters can cause packets to loop or drop. Disabling other VPN clients during testing can help isolate the source of the problem.

Frequently Asked Questions

Why does my internet speed drop after enabling WireGuard?

WireGuard is generally lightweight, but if you are routing all traffic through a distant server, latency increases. Split tunneling helps mitigate this for local resources, but global traffic still depends on the server's location. Ensure your WireGuard server is geographically close to you for better performance.

Can I use WireGuard to connect to a device on a different subnet remotely?

Yes, provided the remote subnet is included in the AllowedIPs list on the client side. You must also ensure that the remote server has routes back to the client’s network, either through static routes or dynamic routing protocols, to return the traffic correctly.

Is Telnet safe to use over WireGuard?

While WireGuard encrypts the traffic, Telnet itself transmits data in plaintext within the tunnel. If the tunnel is compromised or if there are vulnerabilities in the WireGuard implementation, credentials could be exposed. It is strongly recommended to use SSH instead of Telnet whenever possible for secure credential transmission.

What happens if I forget to exclude my local subnet?

You will likely lose connectivity to local printers, shared drives, and management interfaces. Your internet browsing may also slow down or fail if the remote server does not have a route back to your specific local IP range, causing asymmetric routing issues.

How do I revert to full tunneling if needed?

Simply change the AllowedIPs field back to 0.0.0.0/0 in your configuration file and restart the WireGuard interface. This will force all traffic, including local network requests, through the encrypted tunnel, which is useful for maintaining privacy on untrusted networks.