SoftEther SecureNAT: DHCP and NAT Are Two Decisions

SecureNAT is one checkbox that turns on two services, and that is the source of most confusion about it. A virtual DHCP server hands the client an address, mask, gateway and often a resolver. A virtual NAT forwards packets past that gateway using the server host's own network stack. They sit next to each other in the configuration and fail independently: a client can have a perfect lease and no working path, or a working path with settings that point at the wrong resolver. Verify them as two decisions, and the diagnosis becomes short.

Two services behind one checkbox

The virtual DHCP side answers a configuration question: what settings does this client receive inside this Virtual Hub. The virtual NAT side answers a forwarding question: when a client sends a packet to an address outside the hub, does the server translate and forward it. The first is local to the hub and needs no upstream network. The second depends entirely on the host.

The virtual host interface belongs to the first decision, not the second. Its address, often something like 192.168.30.1 by default, is the gateway the DHCP service offers. It is not the server's public listener address, and confusing the two produces firewall rules and client settings aimed at a machine that does not exist on that network.

Decision 1: who supplies the address

If the virtual DHCP is enabled, clients should receive a lease in the pool you configured, with the virtual host interface as gateway and whichever resolver you supplied. Inspect the lease rather than the client's status text, because "connected" describes the tunnel and not the address assignment:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Two failure modes are worth knowing before you debug anything else. A client with a leftover static address from a previous design will keep it and ignore the lease, which looks like DHCP refusing to answer. And a second DHCP source on a bridged segment will compete for the same clients, which produces intermittent addresses and a support queue that cannot reproduce the problem.

Overlapping pools belong here too. If the virtual DHCP pool overlaps the host's LAN subnet or another hub's pool, the client gets an address that routes ambiguously, and every later test is inconclusive.

Decision 2: who forwards past the virtual gateway

With the virtual NAT enabled, outbound traffic from the hub is translated by the server and sent through the host's routing table. That means the forwarding chain is: client to virtual gateway, virtual NAT to host stack, host stack to its default route. Each link can fail without touching the others, and the failure signatures differ.

Test the second decision with something that must leave the hub, not with something local to it. Pinging the virtual gateway proves the first link and nothing more:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

If name resolution works but connections to a public address fail, you are in the forwarding chain rather than in DHCP. If both fail, check the resolver first, because a resolver pushed as an unreachable internal address will make a working path look completely broken.

SecureNAT's forwarding is implemented by the server process, not by the kernel forwarding path you would use with a bridge. That is convenient and slower than bridging, and it also means the host's own firewall rules and routing decisions still apply to the translated traffic. The virtual NAT does not bypass the host's policy; it uses it.

The host's own path is a third thing

Everything above assumes the server host can reach the destination. A host with no working upstream route, a restrictive outbound policy, or an address family the host does not have will fail the second decision no matter how correct the hub configuration is. Check the host on its own, outside the tunnel, before you attribute its failure to SoftEther.

SecureNAT is also not authorization to reach every network attached to the server. It translates and forwards traffic that reaches it; deciding what the host may reach is still the host's firewall and routing job, and a design that relies on the tunnel to grant access is one bad rule away from granting too much.

Address families deserve their own check. A working IPv4 DHCP example does not establish that every IPv6 capability is present in your build, so read the manual for the version you actually run before promising dual-stack behaviour. The SecureNAT section of the manual covers the virtual NAT and DHCP functions for the current release.

Verify each decision with its own test

Accept the first decision with a lease check: address in the pool, gateway equal to the virtual host interface, resolver the one you configured. Accept the second with an outbound request from the client plus a look at the NAT table on the server, because a rising session count is the only direct evidence that translation is happening rather than merely being enabled.

Then record the split in the design note: which component supplies the address, which component forwards, and which host interface the traffic leaves through. When a restart changes behaviour, that note tells you which of the three to inspect instead of restarting everything and hoping the symptom moves.

One more decision belongs in the record, even if you are not making it today: SecureNAT and a local bridge are different designs for the same hub, and a hub that needs both is a hub that needs a different plan. Choose deliberately, write down why, and the next person will not have to reverse-engineer it from a running configuration.