Q:

CIFS mount issue over IPsec VPN

I'm trying to connect a client running Ubuntu 13.04 to a network share hosted by a file server which has recently been upgraded from Windows Server 2003 to 2012. 
Currently I am able to mount the remote share while connected to the LAN using:
sudo mount -t cifs //myserver.mydomain.co.uk/myshare /media/myshare/ -o user=myself,domain=myworkgroup,pass=**********

However, I'm having trouble mounting the share via a Cisco (IPsec/Xauth) VPN.  Prior to the server upgrade I had no problem with this, but now I get the following message:
mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

dmesg | tail gives me [ 1975.651346] CIFS VFS: cifs_mount failed w/return code = -112
The host is most definitely not down - I am still able to connect to the same share over the VPN using smbclient:
smbclient //myserver.mydomain.co.uk/myshare -U myself -W myworkgroup
Enter myself's password: 
session request to MYSERVER.MYDOMAIN failed (Called name not present)
Domain=[MYWORKGROUP] OS=[Windows Server 2012 Standard 9200] Server=[Windows Server 2012 Standard 6.2]
smb: \>

I'm not sure of the significance of the "session request to MYSERVER.MYDOMAIN failed (Called name not present)" error, since I'm still able to browse the directory structure. 
Any suggestions for what to try next? 

A:

Well, a year later I finally figured it out! 
The root cause turned out to be a problem with hostname resolution.  The clue came when I was trying to solve a different problem with SSHing into a machine on the same remote network via the VPN. 
From the output of ssh -v:
debug1: Connecting to myserver2.mydomain.ox.ac.uk [163.1.21.182] port 22. 

I found that OpenSSH was trying to connect to a nonsense IP address (it was actually resolving the hostname of my server to the IP address of a network printer!).  I found that ping was also failing to correctly resolve hostnames, whereas host seemed to work.  That eventually led me to this thread on Ask Ubuntu. 
It turns out that ping and ssh both use the glibc resolver, as does mount.cifs.  The sources from which glibc obtains name-service information are configured in /etc/nsswitch.conf. 
The contents of my nsswitch.conf originally looked like this:
passwd:         compat
group:          compat
shadow:         compat

hosts:          files myhostname mdns4_minimal [NOTFOUND=return] dns wins mdns4
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

The important line is the one that starts with hosts:, which lists the order of sources that glibc queries when performing hostname resolution.  Note that in my version, dns comes after [NOTFOUND=return] in the search order. 
My interpretation is that if glibc fails to resolve the hostname according to the first four sources, it will return before it has actually queried any DNS servers!  I have no idea why nsswitch.conf was configured in this way (I certainly didn't set it up like that), but changing the line to:
hosts:          files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

suddenly made everything work properly, including ping, ssh and mount.cifs.