vEffort

Physical efforts in virtualization and mobility

NetScaler VPN SMB Share Access and Group Policy Retrieval

It has been a VERY long time since I’ve posted anything but I just had to get this quick one out.

Scenario

Standard NetScaler Gateway for Citrix Virtual Apps and Desktops, with StoreFront, with Universal Gateway feature of SSL VPN. Laptops have the Citrix NetScaler Gateway Plug-In, Split tunnelling is set to OFF, so all traffic is forced down the VPN connection.

Connect to the URL with either the browser of the Gateway Plug-in works fine, intranet site and proxying to the Internet works fine. User home drives, and general departmental shares do not work however, even though SMB port 445 is open from the NetScaler (SNIP) to the file servers.

What we found is that mapping the file shares using IP address instead of the host name the file shares worked fine. What we also found is that using a non-domain joined laptop, the file shares worked fine with both host name AND IP address.

  • Add the laptop to the domain – Fails
  • Remove it from the domain – It works again

Wut?

Solution

Please bear in mind this article is not to scale and this took a very long time to bottom out, this article was a clue.  So we got the firewall guy on the phone and did a trace from the NetScaler SNIP to ANYWHERE to see if there were any drops. The key one we found was port 88 Kerberos, to the domain controllers. This was denied, and to be fair we hadn’t requested it.

Next day this was added and SMB shares were now working fine.

Note that port 88 is UDP with a TCP failback so ensure that both are requested.

It’s also worth pointing out that this port is not listed on either the Citrix Ports or Industry saviour Carl Stalhood’s firewall rules guide , if it was it would have been requested already. Personally I feel that mapping drives via VPN is a standard requirement, even in this day and age of using OneDrive etc.

Update…Group Policies over VPN

Another issue we’ve found was that when connected over VPN, group policy updates would not apply, and running GPUpdate /force would fail  eventually timing out and producing a DNS error. What we discovered was that TCP port 135 from the SNIPs (or VPN pool, if configured) to the domain controllers,  was also lacking from the previously mentioned documentation.

Until next time….maybe!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: