Collaborative directories aren't supported by OpenVPN.
Collaborative directories aren't supported by OpenVPN.
They are already configured as requested. Activated for local subnets. Edit: I was actually confused and likely tired (it's almost midnight in Europe), there were three of each SMB-in and Echo Request but didn't set them all properly. I also had two ping settings, so I chose local subnets and the 10.8.0.0/24 range used by my VPN, and now ping, RDP, and file sharing function correctly over the VPN. Thanks for your assistance!
I no longer understand anything. I tested traceroute using my home server's IP address, and it recognized its host name. The output was "Tracing route to homesv...", but the request timed out. Then I used nslookup, which found my server's IP address. It should be related to router settings, but I can't figure it out. I also tried forwarding SMB ports like with RDP, but that didn't work either.
It's better to avoid forwarding SMB because it exposes the public IP, which is a big security concern. Getting the IP address makes sense—using the routers' DNS should prevent external access to the LAN. The traceroute results aren't very helpful unless we can verify ICMP or ping traffic reaches the network. I'm curious, have you tried sending a ping from the LAN to the VPN client's IP?
The problem was related to Windows firewall, but I’m unsure if I could reach the VPN client.
The Firewall stuff works both ways. Generally speaking, Windows will allow the communication outbound by default. But anything inbound whether on VPN or on the server, will get blocked unless explicitly allowed. The laptop/VPN device might have a third party firewall which treats the VPN as non-trusted/public. The VPN interface is separate from the actual network interface, so the Firewall may use a different profile for it. Just have to make sure it's set accordingly, and, well, make sure your "Local Networks" or "Subnets" trusted are configured correctly too. For Traceroute, that uses ICMP but relies on the "TTL Expired" ICMP reply rather than "Echo" reply. That too requires a firewall rule in order to work. Here's an example of one for IPv6. IPv4 will follow similarly... A successful traceroute should show your VPN Gateway IP (the secondary IP the router sets up for itself for the VPN network) followed by the server's IP. Glad we got the core problem figured out, though!
I completely missed the Windows habit of resetting your network type to Public. I don’t understand why they still block ICMP by default—it’s widely considered a security measure, but it can actually cause issues, especially with IPv6. Sorry I wasn’t more helpful, but glad you managed it!