SoftEther Client at Boot: AccountStartupSet and the Daemon Order

Rebooting the machine leaves it on the network with the tunnel down again. SoftEther's client keeps two pieces of state that most people treat as one: whether the service is running, and whether a saved account is allowed to come up with it. Both have to be true, and the second is a per-account flag rather than a boot setting. Run the four checks below in order and stop at the first failure.

Confirm the account is marked for automatic start

The flag lives in the account record inside the client's own configuration, so reinstalling the client or restoring an empty directory clears it. Open the management console and look at the account list before changing anything else.

cd /opt/softether/vpnclient
./vpncmd

Select 2 for VPN Client management and accept the local server by pressing Enter.

AccountStartupSet
office-hub
exit

AccountStartupSet records the account as one to be brought up when the client service starts. It neither launches the service nor provisions a new account, and it prints nothing useful when the name is wrong. Read the account list back after the command, because a typo is silent and looks exactly like a flag that did not take effect.

Confirm the service starts, and early enough

On Linux the client runs as a daemon from its own directory, and it has to be up before any boot step tries to use the account. A short hook that changes directory and starts it is enough on systems that still run rc.local.

cd /opt/softether/vpnclient
./vpnclient start

Where rc.local is gone, write a systemd unit with an explicit WorkingDirectory and a restart policy. The binary resolves its configuration relative to where it is started, so a unit without that setting can start successfully and read nothing. Ordering is the second half of the problem: a connect attempt that runs before the daemon is listening fails intermittently, which is far harder to diagnose than a consistent failure. A restart policy covers the third case, where the daemon dies quietly hours later.

Check the process list rather than trusting a pid file left behind by the previous boot.

Confirm the adapter received an address

Once the account connects, the client presents a virtual adapter and the adapter still needs an address. A hub running SecureNAT usually answers DHCP; a hub bridged onto a physical LAN expects that LAN's server to answer instead.

ip -brief address
dhclient vpn_vpn1

Take the interface name from the listing, because the number in an example is not a constant. If the address must be static, put it in the distribution's network configuration for that interface so it is reapplied after a link event and not only at boot. A one-shot script leaves the adapter addressless the first time the tunnel reconnects during the day. That failure looks like a dead tunnel even though the account is fine.

An addressless adapter is the quietest failure in the list, since the account still reports connected.

Confirm the route points where you think

Traffic can still fail with a healthy link and a valid address. Ask the kernel which interface it would use for a destination inside the hub subnet, then compare that answer with the tunnel.

ip route get 10.10.20.15

A local subnet that overlaps the hub range wins, because its route is more specific and already installed.

That is a numbering decision rather than a client bug, and restarting the service will not change it. Resolver configuration is the other half: an address without a working DNS server produces a tunnel that passes every link check and still cannot open a name.

Write the four checks into the rebuild notes

Record the account name, the service start command and the interface name together, because a rebuilt host restores the account data but not the operating-system hook that launches the daemon. Those live in different places and are usually backed up by different people.

The flag is one line to reapply and easy to forget.

Keep the order: flag, service, address, route. A checklist that starts in the middle produces a lot of confident wrong answers.