In a domain environment, we have a ReadyNas 1100 and some Window 2003 Servers acting as File Servers. Users on our network can access both without problems. However those that connect via VPN ( managed by watchguard firewall) cannot access the ReadyNas drives or web interface (but can ping it).
VPN IP Pool is 10.181.20-80 DHCP Pool is 10.181.10.20-200 ReadyNas IP is 10.181.2.1 and 10.181.2.2 (Eth0 & Eth1)
Any help would be greatly appreicated as this is an on-going issue that I'm struggling with.
Just to add, I've tried mapping to the shares via Sharename (CHDNAS001) and IP. The latter just times out. Using IP prompts for a username/password which never works (NAS Admin nor their Windows account (User/admin/network admin all get the same result), as it just says "The specified network password is not correct".
Mapping via IP works when connected to the network
I suspect it's an SMBv1 issue, as that's all OS4.2.x supports. Your configuration sounds more complex than the usual solution of enabling SMBv1 in Windows10.
Does https://nas-ip-address/admin work correctly on these systems? If it does, you could enable http sharing for a test share, and see if that works over the VPN.
Have you tried disconnecting one of the ethernet ports? When you use both ports w/o bonding, the return traffic from the NAS could be sent from either NIC, and that might be messing up the VPN routing.
I wasn't able to access the admin webpage via VPN before, but I've been playing with the MTU on the VPN clients (increased from 1380 to 1400) and I'm now able to get into the root of the ReadyNas (but not any of the shares). When I try the website now, I'm getting prompted about security certificates and asked for credentials but seems to just hang.
I think the ReadyNas was using 1 Ethernet port but was moved to a new rack on Sunday where it was given an additional Ethernet port. When I get chance I'll try going back to 1 port and see if that changes anything.
but I've been playing with the MTU on the VPN clients (increased from 1380 to 1400) and I'm now able to get into the root of the ReadyNas (but not any of the shares).
That's a good clue. Try resetting the MTU to 1400 on the 1100, and see if that works.
So keep the MTU on the VPN clients as 1400 and lower the 1100 from 1500 to 1400?
I thought VPN MTU should be slightly lower than normal MTU to account for the additional VPN Encapuslation. AKA a packet of 1400 might become 1450 after the VPN encrypts it which would cause problems if say the 1100 was set to 1400? I could be wrong as this isn't my area of expertise!
I thought VPN MTU should be slightly lower than normal MTU to account for the additional VPN Encapuslation. AKA a packet of 1400 might become 1450 after the VPN encrypts it which would cause problems if say the 1100 was set to 1400? I could be wrong as this isn't my area of expertise!
Well, the VPN does encapsulate, and that will reduce the effective MTU. But the MTU setting for the VPN is supposed to be the max payload of the unencapsulated payloads. Most VPNs can handle 1500 bytes - but they do need to fragment the original 1500 byte packets when they do that. There is additional bandwidth overhead (because 1500 byte packets have to be split for transport, and reassembled on on the other end). You might need to delve into how your particular VPN handles that.
The puzzle with going below 1500 in the NAS is that it does need to receive 1500 byte packets properly from your on-net clients - so if you do try reducing the MTU on the NAS, make sure that you test that.
