In reply to a post by Woolwich:

Jings, this seemed simple and the original answer was. Now we're down on of them rabbit holes...

You’ve broadened the scope to multi site IP address assignments and multi site VPNs. Its a big leap from the original question 😉

In reply to a post by Woolwich:

In reply to a post by nemeth782:

Personally, I use 192.168.2.0/23 as a subnet on my home network, I.e. 192.168.2.0-192.168.3.255.

I then have my router on 192.168.2.1, all my static things on 2.x, and 3.x is my DHCP pool.

VPN clients are on their own subnet.

OK, I'm using /24 because I don't know enough about networking but (after reading a bit) also because I have four VPN connections between sites and each of those needs to ne on lits own subnet. As far as I understand. So if I ran a 192.168.1.0/23 LAN here I couldn't have the the office which uses 192.168.2.0 VPN in.

So VPN on their own subnet but I want to have access to file shares on the office LANs. If I come in on a different subnet I won't be able to access them.

Jings, this seemed simple and the original answer was. Now we're down on of them rabbit holes...

Having VPN connections on their own subnet isn't what determines whether they will have access to file shares.
One should still check if they have added any firewall rules affecting traffic between internal networks.

However sometimes people rely to heavily on local network browsing to discover shares, and if this is depending on multicast or broadcast across the same network that's when they might not automatically show up.

However any shares should be on computers or servers that have consistent names in DNS, and specifying an internal DNS server for VPN clients use, so that one can list the shares by browsing to the named computer.

For Windows-like shares historically a computer browse list spanning multiple networks was centralised using WINS,
but having DNS resolve properly is the more generalised way for connections between computers and services. There is a reason we moved away from distributing a big hosts file by scripting!

Note that trying \\computername\sharename often relies on LLMNR or a fallback to the older NBNS (NetBIOS Name Service) both of which will fail unless the VPN has hacks to act as a kind of repeater (which doesn't scale well to multiple sites and/or remote clients).
Worst case for client-to-site remote access they may be broadcasting these requests locally to them instead of over the VPN potentially accessing a third party's computer.

Whereas \\fully.qualified.domain.name\sharename should first translate the FQDN to an IP then browse the target machine (unicast).

Try to avoid your FQDNs using .local otherwise devices will trying to do mDNS (aka Bonjour formerly Rendezvous) which again is local multicast rather than a routeable protocol.

Edited by prlzx (Mon 14-Mar-22 13:17:45)

Gone off my original question but still, I'd like to know....

In reply to a post by prlzx:

Having VPN connections on their own subnet isn't what determines whether they will have access to file shares.

So I thought I need to be on the same subnet to access a file server and that's what the VPN is doing. From my LAN address 192.168.1.2 I'm connecting to another LAN which uses 192.168.2.0/24 and I get an IP address there of 192.168.2.123 (say). The VPN isn't on its own subnet here, is it?

But if you landed into my LAN 192.168.1.0/24 and the VPN is on the 192.168.5.0 subnet you won't be able to access the file server at 192.168.1.99. That's my understanding and how I have different sites setup. Please do tell me if I'm wrong

For Windows-like shares

We're all Mac but i'd love to have my internal DNS setup properly. At the moment we use Finder's 'Connect to server...' and access smb://192.168.2.100 which gets a list of shares which can be mounted. I can get there using smb://domain (no suffix) but don't because it only seems to work locally (not over the VPN). I and users know how to the 'Connect to server...' and as it works I haven't tried to improve things.

Are you saying I could use smb://server.domain.tld/share if I had DNS set up correctly. And users couldn't access that share without being either on the LAN or VPN? On a Mac!

In reply to a post by RR_The_IT_Guy:

In reply to a post by andynormancx:

I'm currently using .5 on my home network, how does that make you feel ?

😉

Bit much, I'll stick to /22 in my core network.

I said .5, not /5, as in I've ended up with my pfSense gateway on .5 (because at one point it was running alongside my existing router which was on .1 and .2-.4 were already in use for servers).

On 192.168.7.5 to be precise.

Using 192.168.7.0/24 for my home LAN was a fair arbitrary choice, I mainly wanted to get away from 192.168.0.0/24 and 192.168.1.0/24 as far too much stuff at the time was coming preconfigured on those.

I also use 192.168.11.0/24 for my WireGuard VPN and 192.168.10.0/24 for an OpenVPN setup I don't really use much anymore.

And my Mikotik LTE router is setup with 192.168.9.0/24 (with DHCP enabled plugged into its own port on the pfSense box), because then if the whole of the rest of my network goes wrong for some reason, I can just plug that directly into one of my access points, bypassing everything else.

In reply to a post by Woolwich:

Gone off my original question but still, I'd like to know....

So I thought I need to be on the same subnet to access a file server and that's what the VPN is doing. From my LAN address 192.168.1.2 I'm connecting to another LAN which uses 192.168.2.0/24 and I get an IP address there of 192.168.2.123 (say). The VPN isn't on its own subnet here, is it?

But if you landed into my LAN 192.168.1.0/24 and the VPN is on the 192.168.5.0 subnet you won't be able to access the file server at 192.168.1.99. That's my understanding and how I have different sites setup. Please do tell me if I'm wrong

For Windows-like shares

We're all Mac but i'd love to have my internal DNS setup properly. At the moment we use Finder's 'Connect to server...' and access smb://192.168.2.100 which gets a list of shares which can be mounted. I can get there using smb://domain (no suffix) but don't because it only seems to work locally (not over the VPN). I and users know how to the 'Connect to server...' and as it works I haven't tried to improve things.

Are you saying I could use smb://server.domain.tld/share if I had DNS set up correctly. And users couldn't access that share without being either on the LAN or VPN? On a Mac!

SMB so yes they are Windows-like shares

So this part is all about client remote access VPN rather than site-to-site.

Well have a think about what the server at 192.168.2.100 does when it replies to a client. If the client is 192.168.2.123 but isn't actually present, how does the server know to send the traffic to the (VPN) router? Normally it wouldn't talk to the router to reply to the same subnet, it would do an ARP broadcast and ask for the MAC address corresponding to the target, to find out who "owns" the IP.
You can see the router does something funky to make it look like they are actually the source of the client's traffic.

Now look at the default gateway from the perspective of your server. if the default gateway points to your router and that is also the VPN router, the server is quite capable of responding to requests from outside its own subnet, because replies would be sent via the router.
In this case the server does not broadcast to locate the client.

The router in turn would know the IP belongs to a VPN client and forward (route) it over the tunnel.

Have a look at the virtual interface created on the client when it brings up VPN.
You may find it is really receiving a /32 but also a setting making the tunnel the default route interface for all non-local traffic.
The VPN client also usually adds an exception for the public IP of the VPN endpoint to reach that directly for the already-encrypted traffic (as seen by the Internet).