Samba on a VPN Address: Why the Listener Disappears

The share works all morning, the tunnel reconnects at lunch, and the same UNC path now times out while ping to the server still answers. Nothing changed in the share definition and the VPN is up. What changed is the local address Samba had bound to, which no longer exists after the interface was recreated. That failure mode is a listener lifecycle problem, not a permissions problem.

The share works until the tunnel restarts

Binding a service to an address ties its socket to that address's lifetime. When the tunnel interface is destroyed and rebuilt, the old address disappears and the socket bound to it goes with it. The service keeps running, but nothing listens where clients are being routed.

Ping can still succeed if the new address answers ICMP, which is why reachability looks fine while the share is dead. That single misleading success is what sends people to the firewall.

Reachability is not a bind address

Three decisions get mixed together here. The route decides whether a client packet arrives. The listening socket decides whether anything accepts it at the local address. The share configuration and filesystem permissions decide what happens after that. Only the second one breaks when the interface is recreated.

An address in the VPN pool is not automatically a local bind address either. It belongs to a client, not to the file server. Ping is a poor test for a file service.

Keep those owners separate in the documentation as well. A future change to the VPN pool should not require editing Samba, and a share permission change should not require a tunnel restart.

Bind to a stable address instead

The more stable design keeps Samba on a permanent address and lets the VPN carry clients to it. The server address does not change when a tunnel flaps, so the listener never has to follow an interface. Admission is then enforced by the VPN path and the host firewall, which are built for that job.

If you must bind to the tunnel, understand the contract of the installed release. The interfaces and bind interfaces only parameters are not the same thing, and the binding documentation warns about intermittent interfaces. Dynamic listener handling exists on some platforms, but it is a capability to verify rather than assume. Read the table before and after a flap and diff the two outputs.

ss -ltnp | grep ':445'

Test the reconnect, not the green light

Verify the listener after a reconnect, not just after a service start. Recreate the tunnel, then read the listening table and confirm the socket exists on the address clients are routed to. A green tunnel indicator and a passing configuration check prove neither of those things.

smbclient -L //files.corp.example -U alice

Then run one permitted operation and one denied path from a client, and repeat after a second reconnect. If the share only works until the first flap, the binding is still tied to the interface lifetime and the design has not been fixed. Change the binding or the service address, and the symptom stops coming back.