[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 4437
  • Last Modified:

Unable to Browse Shares On SBS 2008 Over Cisco ASA Clientless SSL Connection

Primarily I'm having some problems with a clientless SSL VPN connection when trying to browse shares on a 2008 SBS server.
The session authenticates fine and presents the user with the portal but when clicking the  Browse Networks -> Browse Entire Network buttons the portal returns the error "Failed to retrieve domains". If the client tries to browse the server directly eg cifs:// the portal returns the error "Error contacting host".

I've played about with the config, setting up WINS, DNS etc but don't seem to be able to get this to show the servers shares.

Secondarily, it will allow the clients to browse https pages (OWA) on the same server although they have to re-authenticate, can SSO bypass this?

I've setup this before with the ability to browse an NAS box on my home network but it's a *NIX based OS so I suspect that this is more an issue with the security on the 2008 box but would like to discount my config on the ASA before getting into that!

Thanks in advance.

Here is the SSL config:
 port 444
 enable outside
 tunnel-group-list enable
  auto-signon allow ip auth-type ntlm
group-policy SSLGrpPolicy internal
group-policy SSLGrpPolicy attributes
 vpn-tunnel-protocol webvpn
  url-list value Server_Access
  hidden-shares none
  file-entry enable
  file-browsing enable
group-policy DfltGrpPolicy attributes
 wins-server value
 dns-server value
username *** password *** encrypted privilege 15
tunnel-group DefaultWEBVPNGroup general-attributes
 authentication-server-group VSERVER
tunnel-group VONSSL type remote-access
tunnel-group VONSSL general-attributes
 authentication-server-group VSERVER
 authentication-server-group (inside) VSERVER
tunnel-group VONSSL webvpn-attributes
 nbns-server VonneSBS master timeout 2 retry 2
 group-alias SSL enable

Open in new window

  • 5
  • 4
1 Solution
You've likely got a problem with either Windows love of broadcast based protocols not passing your tunnel since VPN won't pass broadcast, or another protocol trying to spin up to complete your connection and that one isn't open yet on the ASA, or the SBS is sending an HTTP redirect to make hte connection with a name you cant resolve or an IP that you cant reach. I've seen all happen, it's not uncommon. I suggest you turn logging to level 6 for a little while, capture any syslog errors associated with the IPs in question, paste in the associated messages, then turn your logging back down to your usual level.

In case you don't have logging on, this would do it:
conf t
logging enable
logging buffered 6

Then test your external ssl connection, noting your client's actual IP, the IP assigned to the ssl client connection, your server's IP address, and any NAT address(es) your server may have. Log back into enable mode on the ASA, and type each command and capture the outputs
sh logg | grep (client native IP)
sh logg | grep (client VPN DHCP IP)
sh logg | grep (server  native IP)
sh logg | grep (server NAT IP)

Then paste them back in here, and we'll figure it out.

TSG_UsersAuthor Commented:

Here is the output as requested, probably not quite what you might have been hoping for!

Client IP:
Client VPN DHCP IP: None! Clientless connection :-)
Server Native IP:
Server NAT IP:


ciscoasa(config)# sh logg | grep
%ASA-6-302013: Built inbound TCP connection 138021 for outside: ( to identity: (
%ASA-6-302014: Teardown TCP connection 138019 for outside: to identity: duration 0:00:20 bytes 34324 TCP Reset-O
%ASA-6-302013: Built inbound TCP connection 138022 for outside: ( to identity: (
%ASA-6-302014: Teardown TCP connection 138017 for outside: to identity: duration 0:00:21 bytes 68275 TCP Reset-O
%ASA-6-302013: Built inbound TCP connection 138023 for outside: ( to identity: (
%ASA-6-302014: Teardown TCP connection 138023 for outside: to identity: duration 0:00:04 bytes 4779 TCP Reset-I
%ASA-6-302013: Built inbound TCP connection 138024 for outside: ( to identity: (
%ASA-6-305011: Built dynamic TCP translation from inside:VonneSBS/5341 to outside:
%ASA-6-302013: Built outbound TCP connection 138027 for outside: ( to inside:VonneSBS/5341 (
%ASA-6-305012: Teardown dynamic TCP translation from inside:VonneSBS/5321 to outside: duration 0:05:00
ciscoasa(config)# sh logg | grep
ciscoasa(config)# sh logg | grep
ciscoasa(config)# sh logg | grep VonneSBS

The ASA essentially proxies connections to your internal devices when you use SSL VPN.

There are limitations to what the client can do, I'm not certain the "cifs://" command is an option directly in the portal browser, though I don't see it documented as a "will work" or "wont work" on Cisco's support pages anywhere. Perhaps try pointing a separate browser session at the port the Cisco WebVPN service page shows your server CIFS service connected on? As in locate the address/port pair associated with your server connection in the portal ( or whatever port shows up), pop open a new browser, then try "cifs://" in that new browser window.

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

Did you use the CLI to configure the webvpn, or the ASDM? I noticed that in ASDM configurations, this line shows up, and I do not see it in your config

  functions url-entry file-access file-entry file-browsing mapi port-forward filter

TSG_UsersAuthor Commented:
The initial configuration was done through the ADSM, then I've tweaked it a bit from the CLI. I've setup a share on a 2003 box (that is due to be decommissioned at some point in the future) and I can successfully access shares on there so it IS the 2008 box causing a problem :(

In the syslog output when connecting to the 2k8 box there is a TCP-reset message when the connection is aborted, if you are trying to connect to a service and a firewall is dropping the packets would you see a TCP reset or would you expect to see a reset when a device actively rejects the connection? I suspect the latter as a firewall should be more stealthy?

Thanks for the link, unfortunately the commands used on the webvpn side of things have changed quite a lot since between ASA 7 and 8 so he specific command you suggested no longer exists.
Which version of ASA are you running?

And the ASA connection reset options are configurable, but the defaults are
service reset outbound
no service reset inbound

meaning traffic attempting to transit the ASA from higher to lower security interfaces are sent a reset on denied flows, and traffic attempting to transit the ASA from lower to higher security interfaces are silently discarded.

Plus, I'm pretty sure you can upgrade the code level of your ASA at no charge as long as its a very recent purchase. Double check with your ASA vendor. Current versions I deploy are ASDM 6.21 and ASA 8.21, they are a good balance of best/most current  securtity features and limited caveats to deal with.
We had the same problem. The ASA was 100% correct. By default the Computer Browser Service in SBS 2008 is disabled by default. We enabled the service and all worked as planned.
TSG_UsersAuthor Commented:
We have tried a few further things, turning on the computer browser server, turned off the firewall, tried to connect by IP and then I upgraded to ASA release 8.2.2 last night and now it works. It even carries though the authentication from the initial portal logon through to the 2K8 shares, which it didn't for the 2K3 shares :-)

I'll see if turning off the Computer Browser Service breaks it and then I'll allocate some points.

TSG_UsersAuthor Commented:
Turned off the Computer Browser Service and it's still working just fine, so I'm seems it was just the upgrade that fixed the problem.

Thanks All.

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now