Collaborative directories aren't supported by OpenVPN.
Collaborative directories aren't supported by OpenVPN.
I received a Lenovo Tiny PC as a home server. It runs Windows 11 Pro, which suits my needs for sharing files, openHAB, and Jellyfin—my old 4590T CPU performs better than Plex for high-quality video playback. I also got a TP-Link Archer C6 AC1200 that supports OpenVPN and includes tplinkdns, so I chose it to establish a VPN connection for accessing my home network remotely. It functions properly; I can connect, manage the router, and RDP into its IP address. However, I can’t ping it, and when I try to open network drives (using the IP instead of the hostname like “\\ip\Folder”), I get an error saying “Network Path Was Not Found.” I’m unsure what changed—after many attempts, I noticed earlier it said “local device name is already in use.” I suspect a basic configuration issue. My VPN settings: I added the 10.10.0.0/24 subnet to the exceptions in my Windows firewall (both ways). My LAN is on the 192.168.0.0/24 subnet, with DHCP settings (server uses .101, reserved). I also have this setup on my router, but I’m not sure if that’s why RDP works.
When using \\hostname it depends on NETBIOS Discovery or DNS to locate your machine. NETBIOS Discovery isn't functional across different subnets. That's why \\IP functions but \\HOSTNAME fails. To resolve this, configure a custom DNS search domain for your LAN and VPN networks if your router permits. Use .localdomain as the DNS Search, then all devices will resolve via that domain. For example, server.localdomain, laptop.localdomain, etc. Regarding ICMP Ping, Windows applies distinct rules. The Firewall has a built-in rule for ICMP Echo requests. You must modify it to permit ICMP from devices on other networks—your VPN subnet should appear in the "Remote IP address" scope, or set it to "Any IP Address."
Yes the port forwarding is likely why RDP works, they probably are creating rules that forward that port for incoming traffic on ANY interface on the router. This is the problem with consumer routers though, they don't always tell you exactly what firewall and NAT rules they are creating. One possibility is if you are connecting to the VPN via a network that uses the same LAN subnet as your home LAN, you will never be able to access your home LAN as you cannot override the route of the LAN you are using to connect to the VPN (as its being used to access the Internet in the first place). I had to change my home subnet to deal with this problem myself.
They misunderstood the message; the device isn’t relying on a hostname or IP address. The router probably isn’t handling NAT for VPN and LAN connections, which explains the failed ping.
The router already offers Home Network and Home Internet + Internet choices, indicating a firewall issue on their side. NAT isn't needed between local subnets, only bridging is required. They can connect to the router and also access the Internet and RDP, confirming bridges exist and routing works. If OP forwarded RDP to the Internet, it might suggest a Hairpin NAT setup, though a functional bridge remains to the LAN. I suspect a deny rule or a broader firewall policy overrides the OP's allow settings. For Windows SMB and ICMP, the same applies as described. In SMB scenarios, key rules include "File and Printer Sharing (SMB-In)" plus "File and Printer sharing (Echo Request - ICMPv4-In)."
You're asking about what bridging actually means in this context. Bridging operates at the Ethernet layer and is rarely used for VPNs because many clients don't support it, and sending broadcast traffic through a VPN isn't advisable. It's possible to route between subnets without NAT, though I'm not sure if that's common practice. I might be wrong about that.
Routers usually establish bridges to connect wireless and wired LAN networks. Internally, they can also link themselves with VPN clients so traffic flows between the VPN software and the network stack. That’s the idea. Please let me know if I misinterpreted anything.
Routing across subnets is feasible without NAT. The device keeps a list of connected subnet clients on Layer 2 and maintains routing tables for Layer 3 connections, plus rules for unknown networks. NAT becomes necessary only when one IP serves multiple devices, requiring the NAT appliance to modify packets so they reach the correct destination after passing through.
On a home router, VPN configurations use free internal addressing, eliminating the need to manage IP scarcity. Thus, even simple routers can generate new subnets in software, set up routing rules, assign unique IPs to VPN clients, and forward traffic using Layer 3. Implementing NAT for software is more resource-intensive because it slows processing.
The TP-Link model here relies solely on built-in firewall capabilities to block internet access—essentially a straightforward IP table that discards traffic destined for the VPN interface or vice versa.
The VPN must operate on its own network segment while the router manages traffic between subnets, similar to how any router connects different parts of the internet. You should observe this behavior using a traceroute, which will show the VPN as a single hop followed by the internal LAN client. If ICMP pings fail, it likely means the final hop isn't reaching.