New OpenVPN Server Instance - No access to DFS Namespace/shares
-
Hi Guys,
This is an odd one. As there is another older instance that's working its certificates and auth methods are retiring - and we're migrating to a new VPN.
However unlike the old remote workers / road warriors tunnels - this instance cannot see the DFS.It is literally driving me potty.
FQDN - yes
Connectivity to all nodes - yes
Can I reach the component shares from \hostname.domain.local\share - yes
VPN Subnet added to Sites and Services
Does name space resolve - yes
All DNS Servers working on VPN - yesI have tried with WINS and Netbios over TCP but this is currently turned off, as it is not turned on, on the current working VPN
Anyone tackled this?
Any pointers could result in extreme Kudos from me LOL
-
@Jake-Biker Would almost bet related to not using fqdn for DFS..
See here
-
@johnpoz Thanks John, Its a good call - but DFS is configured to use FQDN - and the existing VPN can access it with the same paths and drive letters all declared with FQDN.
:(
-
@Jake-Biker and what is different about the existing vpn and the new one? Is the old one using different dns for the client? Is it a bridge/tap connection vs tunnel?
Do a simple sniff, you should see when you try and access the dfs share if its presented in fqdn\share or hostname\share.. Been a long time since I played with any of that sort of stuff.
If you you have access to all the servers IPs via vpn rules, and routing, etc. Then the only thing that comes down to why couldn't access the dfs share is client doesn't know how to get there..
There is nothing in the vpn that could say, hey you can get to IP on port 445, and you can get to other IP on 445, but oh you can't go to the dfs share that points to one of those IPs on the same port 445.. It comes down to name resolution of the dfs share not working..
-
@johnpoz Yes John
Can connect to each member with 445 also.
Existing connection and shortcuts are the same all using FQDN,However I have just noticed that the sites and services subnet as not replicated to our more distant DC which is the one named first if you nslookup the namespace.
Come back to this tomorrow.
If you think of anything else lemme know :)
-
@Jake-Biker so the new vpn tunnel network is not correctly defined in sites and services, or is not fully replicated..
-
It was defined - but hadn't replicated - we are testing now :)
-
Fixed !! ...
I am so used to working on smaller 100% fibre based networks with min 1Gbe connectivity.
I forget this is more complex. And takes longer to replicate.
When you try and resolve the namespace it comes up with the primary DNS being the one furthest away that did not have a valid replication.
Thanks John!
