Connected to OpenVPN but no ping or SMB share? Check three gates

The tunnel comes up, the client gets an address, and nothing on the far LAN answers. Ping fails, the share does not open, and the VPN log looks clean because from its point of view the session is healthy. Three independent gates sit between that session and a file on a server: forwarding policy, the ports the service needs, and the name you typed instead of an address.

Each gate fails with a different symptom, and only the first one is on the VPN server.

Forwarding is a policy on the FORWARD chain

Accepting the OpenVPN listener happens on INPUT, which is why the tunnel can connect while every packet aimed at the LAN is dropped. Traffic that arrives on tun0 and leaves on the LAN interface traverses FORWARD, and a host with a default DROP policy there discards it silently. Check both the sysctl and the chain before touching anything else: sysctl net.ipv4.ip_forward and iptables -L FORWARD -v -n.

Allow the direction you intend and the replies that belong to it, for example an accept rule from the tunnel interface to the LAN interface plus a stateful rule for established and related traffic. If the LAN sits behind another router, that router needs a route back to the client pool or a source NAT on the VPN server. Confirm that path with a single ping before adding more rules, because a rule that cannot be reached never shows up in a counter.

SMB needs more than one port

File sharing is not a single TCP 445 conversation. Discovery uses UDP 137 and 138, older NetBIOS sessions use TCP 139, and modern SMB sessions use TCP 445. A rule that opens only 445 produces the maddening case where a mapped drive works and browsing the network does not, or the reverse.

Large transfers over a tunnel also hit MSS problems that look like a broken share. A SYN that advertises the LAN's full segment size gets dropped by the tunnel's smaller MTU, and the connection hangs after the handshake. Clamping MSS on the forwarding path, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, removes that class of stall. Verify with a copy of a few megabytes rather than a directory listing, since small replies fit through even when bulk transfers do not.

The tunnel adapter arrives as a new network profile

Windows classifies each adapter into a network profile, and a fresh tunnel adapter usually lands in Public, where file and printer sharing rules are blocked. That is a host firewall decision on the file server, not a routing problem on the VPN server. Change the category deliberately with Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private after confirming the policy allows it, because the category also changes which inbound rules apply.

The same profile explains a ping that fails while TCP 445 succeeds: echo requests are dropped on Public by default.

Names do not cross a routed tunnel on their own

NetBIOS name resolution and local discovery rely on broadcasts that a routed tunnel does not carry. Typing the server's short name therefore fails while its address works, and the share looks broken when only the lookup is. Add a DNS record for the server on the resolver the tunnel hands out, or use the address in the shortcut.

If the deployment still depends on WINS, configure it on the client rather than hoping broadcast traffic appears. Test by address first so a name failure cannot be mistaken for a firewall failure.

Test one layer at a time and read the first failure

Work upward: ping the tunnel gateway, ping a LAN host by address, then open the service port with Test-NetConnection -ComputerName 10.8.0.5 -Port 445, and only then authenticate to the share. The first step that fails is the layer to fix, and every later step is noise until it passes. A ping that answers while the port stays closed points at the file server's own firewall, while a port that opens despite silent pings points at ICMP filtering. Write down the first failing step before changing anything, because a second change hides the result of the first.

If the VPN server is not the LAN's router, confirm the return route on that router before adding more rules to the server. Without it, requests reach the host and replies leave by the default route toward the internet, which looks exactly like a firewall drop from the client side.

Keep the share account separate from the VPN login in your notes, since a successful tunnel says nothing about file permissions. Exposing SMB to the internet to dodge a missing rule is not a fix.