SoftEther Local Bridge vs SecureNAT: Which One to Turn On

Open SoftEther Manager and the first real decision about a hub is not a checkbox, it is a topology question. A local bridge attaches that hub to a physical adapter and lets the existing segment supply addressing, while SecureNAT gives the hub its own virtual router, NAT and DHCP. Choosing between them changes where addresses come from and which device answers for them. Turning on both and hoping one wins is how a working lab becomes a support thread.

Start from the hub you are actually editing

Manager shows a tree of servers and hubs, and it is easy to configure the default hub while clients connect to a differently named one. Click the hub, read its name, and confirm that the sessions listed underneath are the clients you are trying to serve. That one check prevents most of the confusion that gets blamed on the protocol.

Then decide what the client needs from the far end. Shared Ethernet behaviour with broadcast and LAN services points at a bridge, routed private access to a small address range points at SecureNAT, and an internet exit is a routing decision that either arrangement can carry badly.

Write the answer down before you click anything, because the two settings are not interchangeable and undo takes longer than deciding. Two minutes of writing saves an hour of reconnecting.

What a local bridge does to addressing

A local bridge connects the hub to a physical adapter, so the hub becomes part of that Ethernet segment. Clients receive addresses from whatever already serves the segment, and their gateway is the segment's router. From the client's point of view it has joined the office LAN, with all the reachability and all the exposure that implies.

That also means the bridge needs a real adapter with the right driver support, and it needs the administrator to be authorized to extend that segment. A VPN login proves authentication, not the right to place a host on a production VLAN. Check that the driver name matches the adapter you intend, because bridging the wrong port takes a segment down quickly. If the adapter list is empty or the bridge reports a failure, the answer is normally driver or privilege related rather than cryptographic.

Read the bridge table from the command line when the graphical tree is ambiguous. The output names the adapter, which the tree does not always do.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

An empty bridge list with connected sessions is a useful picture: clients are inside the virtual hub and nothing is extending it to a segment yet.

What SecureNAT adds, and what it hides

SecureNAT gives the hub a virtual router, a NAT function and a DHCP service, all inside the SoftEther process. Clients get addresses from the virtual DHCP range, the virtual router answers for the default gateway, and traffic that needs to leave is translated. No physical adapter is involved, which is why it works on a host with a single NIC and no switch configuration.

The cost is that the virtual addresses belong to the hub and to nothing else. A machine on the office LAN cannot route to a client's SecureNAT address without help, and anything that logs source addresses sees the translated address of the SoftEther host. If your access rules or your audit trail depend on the client's real address, that is a design change rather than a detail. It also decides whether a source-address rule will ever see the client at all.

It is also a DHCP server. Running it on a segment that already has one, or bridging that segment at the same time, produces two answerers and unpredictable leases. The manual treats the two functions as separate choices for exactly this reason.

Inspect what the hub is currently serving before you enable anything else. Each command prints the current state rather than the intended one.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Turning one on without breaking the other

Pick the arrangement, enable it, and leave the other one off. A hub with a bridge and with SecureNAT both active is a hub with two possible answers for the same question, and the client will believe whichever arrives first. When you migrate from one to the other, disable the old function and reconnect the client rather than assuming the new setting takes effect on an existing session.

Order the change so the client pool does not overlap the LAN range. Overlapping subnets are the second most common cause of a tunnel that connects and then cannot reach anything, and they are invisible until you compare both address plans side by side.

Then reconnect from the client and read what it received, because the hub's view of the session is not the client's view of its own network. A reconnect is the only reliable way to force a fresh lease.

Check the gateway and the resolver on the client

A successful authentication tells you the credentials work and the hub accepted the session. It says nothing about whether the client can reach anything, because that depends on the address, mask, gateway and DNS server it was given. Read those four values on the client before you touch a server setting again.

On Windows the adapter detail shows the lease and the resolver, and the route table shows whether the tunnel is actually the default path.

ipconfig /all
route print -4
nslookup intranet.corp.internal

On a Linux client the same information comes from the address, route and resolver files. The default route is the value that decides whether traffic leaves through the tunnel at all. If the gateway points at the office router while the tunnel expects to carry the traffic, the topology is bridged in name and broken in practice. Fix the address source first, then re-test the application, and only then consider changing the other mode.