SoftEther Connected but Other Devices Have No Internet? Troubleshooting Windows VPN Sharing

SoftEther, PacketiX, or another VPN client is connected on Windows. The host PC can reach the required network, but another computer, virtual machine, or device connected through Windows still has no usable connection.

This is easy to misdiagnose as a VPN failure. In many cases the VPN itself is working. The missing piece is somewhere between the downstream device and the VPN interface on the Windows host.

A connected VPN session only proves that Windows has a working VPN path for the host itself. Sharing that path adds several more layers: local connectivity, Windows forwarding, ICS/NAT, routing, return traffic, and DNS.

First separate the VPN problem from the sharing problem

Before changing ICS, hotspot settings, or adapters, test the VPN directly on the Windows host.

If the host cannot reach the remote network, website, or service through the VPN, the problem is still on the VPN side. Check the VPN server, credentials, virtual adapter, Windows routes, and DNS first.

Only continue with sharing diagnostics after the Windows host itself works correctly through the VPN. At that point the path looks more like this:

Client / VM / Phone
        ↓
LAN / Wi-Fi Hotspot
        ↓
Windows
        ↓
ICS / NAT
        ↓
SoftEther Virtual Adapter
        ↓
VPN Server
        ↓
Internet / Remote Network

The practical goal is to find the exact point where traffic stops.

Check the downstream IP address, gateway, and DNS first

On another Windows computer, run:

ipconfig /all

Look at the IPv4 address, default gateway, and DNS servers. If the client has an address such as 169.254.x.x, it usually has not received a valid configuration from the shared Windows network. The problem has not reached SoftEther yet.

Check Windows Internet Connection Sharing (ICS), Mobile Hotspot, DHCP, the downstream adapter, and the physical or Wi-Fi connection.

Once the client has a valid address, test the Windows gateway:

ping <Windows gateway IP>

If the client cannot reach the Windows host, keep troubleshooting the LAN side, firewall, and downstream adapter. There is little value in debugging VPN routing until this hop works reliably.

If the client reaches Windows but not the internet, verify the shared adapters

A real Windows machine may have Ethernet, Wi-Fi, SoftEther, WireGuard, OpenVPN, Hyper-V, VMware, VirtualBox, WSL, and other virtual interfaces at the same time.

That makes one mistake especially common: sharing the wrong upstream adapter.

You need to identify two things clearly:

• Which adapter represents the VPN path you actually want to use;
• Which adapter connects to the downstream computer, switch, or hotspot clients.

The intended relationship is roughly:

SoftEther / PacketiX VPN Adapter
            ↓
         ICS / NAT
            ↓
LAN / Hotspot Adapter
            ↓
          Client

If Ethernet or Wi-Fi is selected as the wrong upstream connection, the client may still have internet access while completely bypassing the VPN. That is harder to notice than a total outage because the setup appears to work.

Connected does not mean all Windows traffic is using the VPN

SoftEther Client exposes a virtual network adapter to Windows, and the client can also affect the Windows routing table. That means the VPN can be fully connected while only selected destinations use it.

Check the host routing table with:

route print

or PowerShell:

Get-NetRoute

Pay attention to the default route 0.0.0.0/0 and any more specific routes for the remote network. For example:

0.0.0.0/0      → Local internet connection
10.0.0.0/8     → SoftEther VPN

In this example, SoftEther may be working exactly as configured, but only the 10.0.0.0/8 network uses the VPN. General internet traffic still leaves through the local ISP.

SoftEther documents how its virtual network adapter integrates with Windows and how routing can be handled by the client. See SoftEther VPN Client Virtual Network Adapter for the underlying behavior.

The client has internet access, but the public IP is wrong

Do not stop testing once a web page opens. Check the public exit on both the Windows host and the downstream client.

If the host uses the intended VPN exit but the downstream client shows the local ISP address, the sharing path is alive but the traffic is not entering the VPN as expected.

Review the ICS upstream adapter, the Windows default route, whether the VPN is split-tunnel or full-tunnel, and whether another VPN or virtual adapter has changed route priority.

On multi-adapter Windows systems, this check is essential. “Has internet” and “uses the intended VPN exit” are not the same result.

If IP addresses work but domain names fail, check DNS

If the client can reach a public IP address but websites fail by name, test DNS separately:

nslookup example.com

The forwarding path may already be working. The failure may simply be name resolution.

Check which DNS server the client is using, whether requests time out, whether the VPN provides its own DNS servers, and whether reconnecting the VPN leaves stale DNS settings behind.

This is especially common on Windows systems with more than one VPN client. Several products may try to change DNS at different times, so a DNS failure can easily look like a broken VPN share.

Why does Windows Mobile Hotspot connect but still show no internet?

Mobile Hotspot solves only the first part of the problem: it gives another device a way to connect to the Windows machine.

It does not prove that the device is being forwarded through SoftEther. The full path still needs to work:

Phone / Laptop
      ↓
Windows Hotspot
      ↓
ICS / NAT
      ↓
SoftEther VPN
      ↓
Target Network

If a hotspot client is connected but reports no internet, use the same order of checks: IP configuration, gateway reachability, ICS upstream selection, Windows routing, and DNS.

It worked once, then failed after a VPN reconnect or Windows reboot

This usually points to interface or routing state rather than a basic setup mistake.

A VPN reconnect can change addresses, interface metrics, DNS configuration, or routes. Wi-Fi reconnection, WireGuard, Hyper-V, and virtual machine software can also change routing decisions on the host.

For a setup that needs to be dependable, test more than the first successful connection:

• Disconnect and reconnect the VPN;
• Reboot Windows and verify that the path returns;
• Switch between Ethernet and Wi-Fi if both are used;
• Start other VPN or virtual networking software and confirm the route is still correct.

If the configuration only works immediately after a manual setup but breaks after reconnects, the real issue is recovery and route stability.

SoftEther SecureNAT and Windows ICS solve different problems

SoftEther also provides SecureNAT, which includes Virtual NAT and Virtual DHCP functions on the VPN Server side, inside a Virtual Hub.

Windows ICS operates at a different point. It is used when devices connected to the Windows host need to continue through a connection that already exists on that host.

So enabling SecureNAT does not automatically mean a device connected to a Windows hotspot will use the SoftEther Client connection on that PC.

For the server-side design, see the SoftEther SecureNAT documentation.

A quick way to isolate the failure

If you do not want to change adapters blindly, check the path in this order:

1. Can the Windows host reach the target network through the VPN? If not, fix the VPN first.
2. Does the downstream device have a valid IP address, gateway, and DNS? If not, fix ICS, DHCP, hotspot, or LAN access.
3. Can the downstream device reach the Windows gateway? If not, fix the local connection or firewall.
4. Can it reach a public IP address? If not, check ICS/NAT and Windows routes.
5. Do IP addresses work while domain names fail? Check DNS.
6. Does the client have internet but the wrong public exit IP? Check the shared adapter and routing.

This approach turns a vague “VPN sharing does not work” report into a much smaller networking problem.

If only a few applications need the VPN exit, ICS may not be necessary

Sometimes the actual requirement is not to route an entire device through Windows. Only a browser, VM application, automation tool, or another program needs to reuse the VPN exit already available on the host.

If those applications support HTTP or SOCKS5, you can treat the problem as explicit proxy distribution instead of rebuilding the whole downstream network around ICS and NAT.

This does not replace a real gateway in every case. Devices or applications without proxy support, and use cases that require transparent system-wide routing, still need NAT, ICS, or another gateway solution.

If you are deciding between the different approaches, see How to Share a Windows VPN Connection with Other Computers: 3 Practical Methods. It compares Windows ICS, hotspot/Ethernet sharing, and HTTP/SOCKS5 distribution.

Where NetConfiger fits

One NetConfiger use case is a Windows host that already has a working SoftEther, PacketiX, corporate VPN, or other network connection and needs to make that existing exit available to other applications on the LAN.

SoftEther / PacketiX / Existing VPN
                ↓
             Windows
                ↓
           NetConfiger
          ↙           ↘
       HTTP         SOCKS5
        ↓              ↓
     PC / VM       PC / VM

The original VPN client still establishes the VPN. NetConfiger does not provide the VPN line and does not replace the existing client. Applications that support HTTP or SOCKS5 can reuse the selected Windows network exit, while devices that require transparent full-device routing should use a gateway/NAT approach instead.

That distinction matters when troubleshooting. VPN connectivity, Windows routing, NAT, and application proxying may all be described casually as “sharing the connection,” but they are different layers and fail for different reasons.

Find the layer that actually failed

A SoftEther or PacketiX status of Connected is only the beginning of the path. A downstream device still depends on Windows forwarding, routing, DNS, and the correct network interface.

If the host itself cannot reach the target network, fix the VPN. If the downstream device has no valid address, fix the LAN or sharing side. If it reaches Windows but cannot reach the internet, inspect ICS/NAT and routing. If IP addresses work but names do not, troubleshoot DNS. If the client is online but uses the wrong exit, return to the shared adapter and route table.

Following the real packet path usually finds the problem much faster than repeatedly reinstalling the VPN client or toggling random adapter settings.