Why Samba Rejects VPN Clients That Can Reach the Server

A VPN client pings the file server, resolves its name, and still cannot open a share. Samba's host policy is one of four layers that can refuse that connection, and it is the one people edit last. The allowlist is evaluated against the source address smbd actually receives, which may not be the address the client believes it has. Getting that source right turns a vague permission problem into a one-line configuration change.

Four layers that fail with the same message

A refusal can come from the route, the host firewall, the Samba host policy, or the SMB identity. Each layer produces a client message that says roughly the same thing, which is why guessing burns an afternoon. Ordering the checks from the network inward removes most of the guesswork.

Start with transport. If port 445 never reaches the server, no Samba setting matters, and a capture on the server interface settles it in seconds. Next comes the host firewall on the server itself, which can drop a permitted source before smbd ever sees it. Only after those two pass does the allowlist become a candidate. Authentication comes last, because a login failure and a host refusal look different in the server log even when the client reports both as access denied. The order matters more than the tools, since every layer has a command that answers it.

Find the source address smbd actually sees

With routed access the server usually sees the client's address from the VPN pool. With source translation on the gateway it sees the gateway's LAN address instead, and every client behind that gateway becomes indistinguishable.

That difference decides whether an allowlist entry is a policy or a hole. Allowing a translated gateway address admits everyone behind it, which is rarely what a per-client rule was meant to express. Read the source from the server rather than from the client's own idea of its address. A capture on the server interface is the cheapest way to see it, and the same capture proves whether the packet arrived at all. Cap the capture with a packet count and add a host filter once you know which client you are following. The Samba session table is the other half of the answer: in smbstatus -b, the client column of each session row is the peer that smbd recorded, which is the fastest confirmation of the address that actually reached the service.

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

Read the allowlist as Samba reads it

The hosts allow setting takes a list of addresses, networks or names, and it can appear globally or inside a share. Two entries that look equivalent to you may not be equivalent to the parser, so the effective configuration is the thing to inspect. That means the merged view rather than the file you happened to edit.

An illustrative pair of prefixes looks like the line below, and it is an example rather than a replacement for the entries already there. Keep the administrative and application clients that legitimately connect today, and read any deny list in the same pass. Whether a host is admitted depends on the policy as a whole, so test the exact client instead of reasoning about precedence. Host permission also says nothing about share permissions or filesystem modes, which are separate gates. A success from the test tools means the host policy admits that source, and nothing beyond it.

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

Change the file that survives a reboot

On a normal Linux host the configuration path is fixed and the service reads it again on restart. On a router or appliance the running smb.conf is often generated at boot, and a hand edit disappears at the next reboot. Use the appliance's supported customization mechanism, which is usually a configuration file of its own.

The temptation at this point is to flash alternative firmware because one thread reported that it worked. That is a large change for a small policy problem, and it moves the device outside its supported state. Identify the supported control first, since most appliances expose the allowlist through their own interface. If they genuinely do not, that limitation is an argument for different hardware rather than for an unsupported build.

Record which file you changed and what regenerates it, so the next person does not repeat the diagnosis.

Test one permitted and one excluded client

Test both outcomes, not only the one you wanted. A permitted client that connects proves the change works; an excluded client that is still refused proves the rule did not simply open everything.

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

When the connection never reaches smbd, the answer sits in routing or in the server firewall. If the host is admitted and the login fails, the identity is the problem and widening the allowlist again will not help. Keep diagnostic output private, since a verbose Samba log can expose share paths and account names. Change one layer per attempt, or the next result tells you nothing.