Shared folders doesn't work with OpenVPN

[PoPet]

So, I got a Lenovo Tiny PC as a home server. It runs Win11 Pro, since I only needed something to share fodlers, openHAB and Jellyfin (my cpu in it is an old 4590T and for some reason, it works better than Plex with high quality videos). 

 

I also got a TP-Link Archer C6 AC1200 that can create an openvpn and has tplinkdns, so I went with it to set up a VPN to acces my home network from anywhere. It works fine, I can connect in, acces my router, and also can RDP my home server with its IP. But I can't ping it, and if I try to open the network drives on it (it's connect with the the IP, not hostname like "\\ip\Folder", and work perfectly without the VPN) gives an error message "Network Path Was Not Found". I dont know how it changed, I tried so many things, but earlier it was "local device name is already in use".

 

I know it has to be something basic shit, that I can't figure out.

 

My VPN settings: 

I added the 10.10.0.0/24 subnet to the exeptions on my servers windows firewall (both directions).

 

My LAN is in the 192.168.0.0/24 subnet, with these DHCP settings:

(The server uses .101, and it's reserved for it)

 

I also have this seted up on my router, but I dont know if it is why the RDP works:

 

[Smith6612]

When using \\hostname it is relying on NETBIOS Discovery or DNS to find your host. NETBIOS Discovery doesn't work between subnets. This is why \\IP works but \\HOSTNAME doesn't. To fix this, if your router allows you to set up a custom DNS search domain for your LAN and VPN Networks, make that match for both networks and you'll have better success. For example, use .localdomain as your DNS Search, and then from there all computers will resolve using .localdomain. So server.localdomain, laptop.localdomain, etc.

 

For ICMP Ping, Windows has a different set of rules for ICMP. In the Windows Firewall, there is a built-in rule for enabling ICMP Echo / Pings. But you have to adjust it so it'll allow ICMP Echo from computers on other networks (in this case, your VPN is considered another network). You have to enable this rule, but also adjust the "Remote IP address" section under the Scope to include your VPN subnet, or change it to "Any IP Address."

 

[Alex Atkin UK]

5 hours ago, PoPet said:

So, I got a Lenovo Tiny PC as a home server. It runs Win11 Pro, since I only needed something to share fodlers, openHAB and Jellyfin (my cpu in it is an old 4590T and for some reason, it works better than Plex with high quality videos). 

 

I also got a TP-Link Archer C6 AC1200 that can create an openvpn and has tplinkdns, so I went with it to set up a VPN to acces my home network from anywhere. It works fine, I can connect in, acces my router, and also can RDP my home server with its IP. But I can't ping it, and if I try to open the network drives on it (it's connect with the the IP, not hostname like "\\ip\Folder", and work perfectly without the VPN) gives an error message "Network Path Was Not Found". I dont know how it changed, I tried so many things, but earlier it was "local device name is already in use".

 

I know it has to be something basic shit, that I can't figure out.

 

My VPN settings: 

I added the 10.10.0.0/24 subnet to the exeptions on my servers windows firewall (both directions).

 

My LAN is in the 192.168.0.0/24 subnet, with these DHCP settings:

(The server uses .101, and it's reserved for it)

 

I also have this seted up on my router, but I dont know if it is why the RDP works:

 

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.

[Alex Atkin UK]

4 minutes ago, Smith6612 said:

When using \\hostname it is relying on NETBIOS Discovery or DNS to find your host. NETBIOS Discovery doesn't work between subnets. This is why \\IP works but \\HOSTNAME doesn't.

You misread their post, they are NOT using hostname and IP is not working.  The router is likely not performing NAT between VPN and LAN interfaces, thus why ping doesn't work either.

[Smith6612]

7 minutes ago, Alex Atkin UK said:

You misread their post, they are NOT using hostname and IP is not working.  The router is likely not performing NAT between VPN and LAN interfaces, thus why ping doesn't work either.

The router already presents a Home Network and Home Internet + Internet option, so this is most likely a firewall problem on their server. NAT is not required between local subnets, but bridging is. They can reach the router itself as well as the Internet and RDP, so that tells me the bridges are there and routing is possible. If OP port forwarded RDP to the Internet, then there is possibly Hairpin NAT involved, but there still persists a working bridge to the LAN. I'm betting there is a deny rule or a less specific rule on the server firewall superseding whatever allow rule the OP created.

 

For Windows SMB and ICMP, the same rule applies from my original post. In the case of SMB, the important rules are "File and Printer Sharing (SMB-In)" along with "File and Printer sharing (Echo Request - ICMPv4-In"

[Alex Atkin UK]

11 minutes ago, Smith6612 said:

The router already presents a Home Network and Home Internet + Internet option, so this is most likely a firewall problem on their server. NAT is not required between local subnets, but bridging is.

What exactly do you mean by bridging here?  Bridging is done at the ethernet layer and hardly ever used for a VPN as many clients do not support it and sending broadcast traffic over the VPN is a bad idea.

I believe its possible to route between subnets without NAT, but I do not think this is usually done either.  Though I may be mistaken on that.

[Smith6612]

38 minutes ago, Alex Atkin UK said:

What exactly do you mean by bridging here?  Bridging is done at the ethernet layer and hardly ever used for a VPN as many clients do not support it and sending broadcast traffic over the VPN is a bad idea.

I believe its possible to route between subnets without NAT, but I do not think this is usually done either.  Though I may be mistaken on that.

Routers typically create bridges to tie together the Wireless and Wired LAN. Internally they can also create a bridge between themselves and VPN clients in order to allow traffic to pass to and from the VPN software in the network stack. That's what I mean. Sorry if I'm confusing things there.

 

Routing between subnets is possible without needing NAT. The router maintains a Table of clients for subnets directly connected to it on Layer 2, and also maintains a routing table of the subnets it has attached to it for Layer 3 routing, as well as a table of rules on how to get to other networks it doesn't know about. NAT is only required if a single IP is hosting multiple devices behind it, where the NAT device has to rewrite the packet to properly deliver it to a device behind NAT after receiving it, since devices can't all have the same IP address assigned to them. On a (home) router VPN, internal addressing is cheap (free) and there is no need to conserve IP addresses, so even home routers will just create a whole new subnet in software, stand up routing rules for it, give VPN Clients their own IP addresses, and just pass it along with Layer 3 routing. Doing NAT for a piece of software is more expensive in CPU power, since the router wouldn't be able to accelerate that. The TP-Link in this case, only has built-in firewall rules to deny access to the Internet (basically a simple IPTables rule that drops traffic to/from whatever the VPN Bridge/VPN Interface is, to/from whatever the Internet Bridge/Internet Interface is). LAN Only means it will still allow say, a client at 192.168.2.2 (VPN) to speak to the router (192.168.2.1), which is also the router for the server (192.168.0.101) at IP address 192.168.0.1.

 

Hope that makes sense.

[PoPet]

1 hour ago, Alex Atkin UK said:

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.

When I wanted to change my VPN to 192.168.0.0/24 subnet, my router denied it since it was my LAN's. I can try the other way, but dont know if it wil allow it.

[Alex Atkin UK]

45 minutes ago, Smith6612 said:

Routing between subnets is possible without needing NAT. The router maintains a Table of clients for subnets directly connected to it on Layer 2, and also maintains a routing table of the subnets it has attached to it for Layer 3 routing, as well as a table of rules on how to get to other networks it doesn't know about. NAT is only required if a single IP is hosting multiple devices behind it, where the NAT device has to rewrite the packet to properly deliver it to a device behind NAT after receiving it, since devices can't all have the same IP address assigned to them. On a (home) router VPN, internal addressing is cheap (free) and there is no need to conserve IP addresses, so even home routers will just create a whole new subnet in software, stand up routing rules for it, give VPN Clients their own IP addresses, and just pass it along with Layer 3 routing. Doing NAT for a piece of software is more expensive in CPU power, since the router wouldn't be able to accelerate that. The TP-Link in this case, only has built-in firewall rules to deny access to the Internet (basically a simple IPTables rule that drops traffic to/from whatever the VPN Bridge/VPN Interface is, to/from whatever the Internet Bridge/Internet Interface is). LAN Only means it will still allow say, a client at 192.168.2.2 (VPN) to speak to the router (192.168.2.1), which is also the router for the server (192.168.0.101) at IP address 192.168.0.1.

 

Hope that makes sense.

Thanks for the refresher, I was aware how NAT works (and why) but its one of those cases where I've been using it so long, I kinda lost track of how this would work with a VPN subnet.  Dumb me had a list of NAT rules I didn't need, lol.
 

[Alex Atkin UK]

4 minutes ago, PoPet said:

When I wanted to change my VPN to 192.168.0.0/24 subnet, my router denied it since it was my LAN's. I can try the other way, but dont know if it wil allow it.

Yes the VPN needs to be its own subnet but the router should "route" between them, just as any router on the Internet passes traffic between different subnets.

 

You should be able to see this happening via a traceroute as the VPN will be one hop, then the final hop should be the internal LAN client.  Of course if ping (ICMP) isn't working, you probably wont get that final hop.

[PoPet]

2 hours ago, Smith6612 said:

The router already presents a Home Network and Home Internet + Internet option, so this is most likely a firewall problem on their server. NAT is not required between local subnets, but bridging is. They can reach the router itself as well as the Internet and RDP, so that tells me the bridges are there and routing is possible. If OP port forwarded RDP to the Internet, then there is possibly Hairpin NAT involved, but there still persists a working bridge to the LAN. I'm betting there is a deny rule or a less specific rule on the server firewall superseding whatever allow rule the OP created.

 

For Windows SMB and ICMP, the same rule applies from my original post. In the case of SMB, the important rules are "File and Printer Sharing (SMB-In)" along with "File and Printer sharing (Echo Request - ICMPv4-In"

They are already set like you said. Enabled and to local subnets. 

Edit: I was actually dumb and probably tired (its almost 1am in EU), there were 3 of each SMB-in and Echo Request and didnt set all of them correctly. Had 2 of ping settings too, I set it all to local subnets and the 10.8.0.0/24 what my VPN uses, and now ping, rdp and file sharing works fine over VPN. 

Thanks for the help guys!

[PoPet]

12 minutes ago, Alex Atkin UK said:

Yes the VPN needs to be its own subnet but the router should "route" between them, just as any router on the Internet passes traffic between different subnets.

 

You should be able to see this happening via a traceroute as the VPN will be one hop, then the final hop should be the internal LAN client.  Of course if ping (ICMP) isn't working, you probably wont get that final hop.

I dont know anymore, now i tried tracrert with my home servers IP, and it knew its host name. "Tracing route to homesv...", but the request timed out. Then I tried nslookup, and it finds my servers ip. It should be some settings on the router I think, but I cant figure it out, how to make it work. I tried port forward the SMB ports too, as I did with the RDP but it didnt work either.

[Alex Atkin UK]

3 hours ago, PoPet said:

I dont know anymore, now i tried tracrert with my home servers IP, and it knew its host name. "Tracing route to homesv...", but the request timed out. Then I tried nslookup, and it finds my servers ip. It should be some settings on the router I think, but I cant figure it out, how to make it work. I tried port forward the SMB ports too, as I did with the RDP but it didnt work either.

Yeah don't port forward SMB as it will be open to the public IP too which is very risky.

Getting the IP makes sense, it should be using the routers DNS - doesn't indicate it can see the LAN.  The traceroute timing out unfortunately doesn't mean much, unless we can get ICMP/ping working at least to show its actually routing to the LAN at all.

I wonder, have you tried the reverse, pinging the VPN client IP from the LAN?

[PoPet]

3 hours ago, Alex Atkin UK said:

Yeah don't port forward SMB as it will be open to the public IP too which is very risky.

Getting the IP makes sense, it should be using the routers DNS - doesn't indicate it can see the LAN.  The traceroute timing out unfortunately doesn't mean much, unless we can get ICMP/ping working at least to show its actually routing to the LAN at all.

I wonder, have you tried the reverse, pinging the VPN client IP from the LAN?

It was a firewall issue on windows after all, now it works fine, but i can't remember if i could ping the VPN client or not 

[Smith6612]

1 hour ago, PoPet said:

It was a firewall issue on windows after all, now it works fine, but i can't remember if i could ping the VPN client or not 

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!

[Alex Atkin UK]

I had completely forgotten Windows habit of resetting your network type to Public.  I don't know why on earth they still block ICMP by default either as its well known the idea this is a "security feature" is absolute rubbish, and in fact can break things if done on IPv6.

Sorry I wasn't more helpful but glad you sorted it anyway.