Although this issue pops up from time to time (cannot map drives over vpn), we got a lot of complaints after upgrading from v220.127.116.11 to v18.104.22.168 (apm client v7185 to v7198). After uninstalling the v7198 client and then installing v7185 affected users can generally map their drives afterward. Although I'm testing the v7213 apm client as a replacement, I'd like to look at ways to reduce if not eliminate this wonky dns behavior altogether.
What F5 tech support's seen in the client vpn diag file and which I've seen in a client Wireshark capture (looking at TCP 139 & 445 and UDP 137), is the client's trying to use its local DNS rather than that supplied by VPN to resolve the hostname for drive mapping. Of course, it's going to fail.
Has anyone else had this issue? Some end users have trouble while others don't which makes me wonder if there's something on the client side that needs to be corrected.
Yes, I've enabled the Enforce DNS option. I haven't tried the static host field yet, but I will to see if that works. I'll add an update here with the results.
What we've tracked this down to (but not "why") is enabling the "DNS Relay Proxy" in the Edge Client. When the Edge Cleint is installed, the DNS relay proxy service for it will start/run whenever Windows boots up (rather than when the app's run - fyi). After stopping that service, drive mapping will work as expected. For the time being, we're not enabling "DNS Relay Proxy" in the Windows Edge Client (we're moving to a different VPN in the future anyway).