Browsing Network Shares & Files over VPN tunnel

Posted on 2016-10-12
Last Modified: 2016-10-18
Hmmm...    Using Untangle devices to connect 4 branches:   Houston, Dallas, Austin, and San Antonio.

VPN tunnels have been configured for some years and working for that same time period.   About 6 to 9 months ago, we started having problems when trying to access network shares in Dallas (from any other branch).    So, I can ping Dallas AND I CAN BROWSE some of the DALLAS shares.   But most of the shares it allows me to browse are relatively empty (very few files).   Anytime I try to drill down into a share that has a large (but not crazily so) number of files, I get an hourglass for a minute or so and then an error (\\server\share\directory is not accessible.   You might not have permission to use the network resource...   The specified nework name is no longer available.)
Of course, if I am on the LAN  in Dallas, everything works great (I can access all the shares no problem).
Also, from Dallas, I can browse and access any shares on the remote servers in Houston, or Austin, or San Antonio - going through the VPN tunnels of course.

Last little tidbit of info...      If I try to run an RDP session on the Dallas Server (from say Houston) going through the VPN tunnel, I connect but get a blank screen - no video.    I CAN do an RDP session to the Dallas Server - but I have to come in directly from the Internet (ie, use the public IP address - not the VPN tunnel).

So, what kind of strangeness could be blocking/preventing network shares from working ?!?!?   Any ideas !?!?
Question by:ponedog
  • 3
  • 2
LVL 27

Assisted Solution

skullnobrains earned 500 total points
ID: 41841749
can't really tell but this looks like a common networking mess with VPNs

my guess would be

VPN is configured in udp mode so it will send 2048bytes cells whenever it has that much data to send or whenever there was data in waiting for a few ms.

this by itself induces quite poor tcp connectivity in many cases because the RTT is irregular. when the vpn is heavily used, it actually works better and quite seemlessly

then you may notice the udp cell size is bigger than the MSS ( likely around 1400-1500 ) so those cells get to be split. the split actually reduces bandwidth unless the cell size is a multiple of the MSS. additionally if either endpoint or any statefull firewall equipment is slightly saturated in the middle, it will have a hard time to cope with reconstructing the split packets an possibly drop some of them.

the above would explain situations in which small queries work but larger ones don't : basically any question or answer above the MSS is likely to be lost in space.

this can usually be confirmed with simple ping tests : it is likely that pings above a specific size work erratically.

if that is actually the case, first check the connections the vpn runs over, and possibly use smaller cells, switch to tcp mode, let the ISP handle the problem on his side.... depending on your findings

Author Comment

ID: 41841902
Running Ping tests (eg: ping dallas /f /l 1418) shows that 1418 is the maximum packet size without fragmentation.

However, this is true of all the VPN tunnels to each of the branches.   So, there does not appear to be a difference between how the Untangle is set up for the different VPN's.

However, it does appear that Dallas is somehow different since we seem to have our problems "clustered" with them.    

How would we tell if the ISP (and how they were handling packets) is part of the problem ???

Accepted Solution

ponedog earned 0 total points
ID: 41843033
Solution found - with credit to Untangle Support (Chad).

An option in the Untangle box was unchecked that needed to be checked.   Specifically...
APPS --> IPsec VPN --> IPsec Options --> Traffic Processing:   Bypass all IPsec traffice - Check this BOX !!!!     Of course, we have no idea how/who unchecked this box.  Probably happened in the ancient mists of time and only showed up when someone rebooted the Untangle box.

Screen Shot of Untangle IPsec Option that MUST be checked.
LVL 27

Expert Comment

ID: 41843259
good to see you "solved" it and it is actually quite a frequent way to solve vpn problems. but ipsec is pretty much the security of the vpn and only needs to be disabled either when the cpu of your endpoints can't cope with the traffic or when the network is a mess ( encrypted connections break easily with little packet loss ). please make sure it was disabled in the first place and make sure this is the security policy you want.

Author Closing Comment

ID: 41847985
Answer came from Untangle - clearly the answer to my problem!

Featured Post

Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Data center, now-a-days, is referred as the home of all the advanced technologies. In-fact, most of the businesses are now establishing their entire organizational structure around the IT capabilities.
When it comes to security, there are always trade-offs between security and convenience/ease of administration. This article examines some of the main pros and cons of using key authentication vs password authentication for hosting an SFTP server.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor ( If you're looking for how to monitor bandwidth using netflow or packet s…

809 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question