Blog: VPN

I came across a problem in one of our automated Robocopy command scripts when copying files from NTFS to EMC Celerra file system.  The problem was that every time Robocopy was told to copy files to the EMC Celerra over the VPN, the files were always detected as “newer” on from the originating source.  This caused Robocopy to copy every single file from our network to the remote network each and every time. 

I came across a command line switch for Robocopy: /FFT : Assume FAT File Times (2-second date/time granularity).  So what this does is force Robocopy to use FAT style time stamps which are 2-second granularity.  It allows enough flexibility to account for the way the time is recorded when doing a file copy from NTFS to another file system. This is needed when going between and NTFS and Linux/Unix/FAT or emulated file system.


When working with Cisco 800 model routers (and probably any Cisco Integrated Services Router) you might run into an issue that the VLAN which is assigned to the LAN ethernet ports is in an “up/down” state.  This is because an SVI must meet all of the following conditions to transition to the full "up/up" state:

  • The VLAN must exist and be active in the VLAN database.
  • At least one switched port in the VLAN (access or trunk) must be up.
  • That port must be in the STP forwarding state.

Sometimes it is necessary to have that VLAN interface up even if there are no devices or ports using that VLAN.  [more]The most recent case that I experienced this need was when I was trying to transfer IOS images remotely across a VPN connection.  Because the transfer was traversing across the VPN I had to source the file transfer from the internal VLAN interface.   There weren’t any PC’s connected to the router so the VLAN interface was in an “up/down” state.  To resolve this issue, I could have either connected a PC or a loopback into the router or simply forced the VLAN into an “up/up” state.  Issuing the “no autostate” command on the VLAN interface will bring the interface up.  Basically, the command just tells the VLAN interface to ignore the above mentioned prerequisites.  Note: This command is only available in certain IOS images.


A coworker and I ran up against a very interesting situation at a virtualization consulting customer's site the other day. We got an after-hours call from the customer that said he was working on the console of a new Windows 2008 virtual machine. He was trying to set the IP address on the NIC and accidentally choose the “bridge network adapters” setting. Afterwards, he was unable to get to anything in the internal network from this server and several other VMs could not communicate with the internal network either. My coworker connected via VPN just fine, but was unable to ping the vmhost2. He could ping the SBS server, one terminal server, and the ISA server. We discussed over the phone that the particular ESX server that those servers were on must have somehow gotten isolated from the network. Sure enough, when my coworker checked the NIC status on vmhost1, it showed that all NICs connected to the LAN network were disconnected. We decided to go onsite and check out what was going on. On the way out, I realized what had happened. When the two NICs got bridged on that VM, it created a loop and must have looped a BPDU and err-disabled the port. Once onsite we confirmed that the port was down and portfast was NOT enabled on that port.

So, the warning here is two fold…yes, a VM can take down the whole ESX server. And second, its best to turn on portfast for ports connected to ESX servers. They don’t understand STP anyway.


During an IT security audit this week, I had the chance to test the Cisco AnyConnect VPN client from a VPN-hostile network.  The bank has implemented multiple layers of Internet filtering including web content filtering, outbound port filtering, and inbound IP address/port filtering.  As expected, the old Cisco IPSEC VPN client could not connect.  The AnyConnect client, however, connected on the first try without having to ask the bank to modify any of their access controls.

FYI, the AnyConnect client dynamically determines if it can also use a Datagram Transport Layer Security (DTLS) tunnel via UDP in addition to the SSL tunnel.  If the DTLS tunnel connects and is “healthy” the client will use both the SSL and DTLS tunnels to transmit data.  If the DTLS tunnel cannot connect or is unreliable, the client will dynamically switch to using only the SSL tunnel.  You can read more about it on Cisco’s AnyConnect FAQ page.


We've had issues with cached credentials not updating when a user’s password expires while he or she is away from the office. The only connection into the network is through terminal services (non-VPN) and the password is changed on the terminal server.  The problem is that the cached credentials on the user’s laptop are not updated, even after the user connects via VPN for a while.  Here is the easiest way I've found to force cached credentials to update to the new password.  While connected via VPN, have the user lock their laptop (Win+L) and then unlock the laptop using the new password. This procedure forces the laptop to check in with the domain controller and authenticate using the new password.


We use MRTG on our internal network to help monitor bandwidth for several network connections.  After setting up monitoring for several VPN’s I noticed a couple of the busier VPN’s would “flat line” during the day but look normal after hours.  When MRTG can’t access the device to get data, it continues to plot the previous value which creates this flat line effect.  Therefore I initially thought there was a problem with those VPN’s, but the VPN’s were working fine.  After digging further I noticed the MRTG cfgmaker utility put  “MaxBytes[xxxx]: 1125” for the graph of the VPN interface.  This tells MRTG how to scale the graph, but it also discards data above that threshold.  So during the day the bandwidth was above the threshold and displaying the flat line graph because it was displaying the last known good data value.  I increased the value on the MaxBytes statement to fix the problem.


I was working remotely on a customer’s network using a PPTP VPN connection. When my work was completed, I clicked on the network icon in my system tray expecting to find a “disconnect from” option for the connection.  It was not there.  I opened up Network and Sharing Center, but could not find a way to disconnect the session.  Finally, I disabled my network interface card (NIC) and re-enabled it.  That disconnected the session.

I knew I didn’t want to have to disable my NIC every time I used a PPTP VPN connection, so I looked for a solution.  I found an online forum that mentioned that this was a known issue. The workaround for this problem is: [more]

Open up a command prompt window.  At the prompt, type rasdial “connection name” /disconnect and then enter.  That will disconnect the session.  The connection name will need to be in quotations if the name of the connection has spaces in it.  If it does not, then quotations are not needed.  If you need to identify the connection name, you can just type rasdial and then enter.  This will give you a list of all your active connections.

If you utilize the same PPTP connection(s) quite often, you can also create a disconnect shortcut for each connection, which will simplify the process.  Just create a new shortcut and add the listed command string in the location.  Then, when you need to disconnect from the PPTP session, just use the shortcut.


I was trying to connect a VPN from Terminal Server that was recently upgraded to Windows 2008 and when I would connect, I would lose my terminal server connection completely.  I would then have to log my session from a different server using Terminal Services Manager.  I tested the same VPN connection on a local Windows 7 machine and experienced similar issues where all of my network connections were dropped upon connection. 

Upon examining the properties of the VPN connection entry, there was a checked setting to use the default gateway on the remote network.  Unchecking this box through the IPv4 properties stopped the disconnects from happening.  I also recommend unchecking the use of IPv6; it also has the same options to use the remote network’s gateway.  [more]


During troubleshooting of some VPN connection issues, I was running a traffic dump session on the Ecessa PowerLink.  I noticed some unusual SSH traffic going to the internal VPN router.  When I entered in “show users” at the command line of the router, it showed myself and someone using “root” connected.  The IP address of the “root” user was an external IP address.  I performed a “whois” on the IP address.  It appeared to be originating from St. Louis Missouri. [more]

I talked to another engineer about this and after some investigation and testing, it turns out that when a person is trying to connect to a Cisco device, the show users output will show whatever username is being utilized.  I verified this by connecting to the same router and typing it “admin” at the username prompt.  The show users output showed the name admin.


One of our bank customers has a vendor that monitors the status of one of their servers remotely through a VPN connection.  In the past few days, something has happened to where they call saying that they are detecting the server is down or unreachable.  The bank had not noticed any problems in their ability to provide service to their customers as they usually get calls when something isn’t working right.

The vendor began troubleshooting network connectivity and determined later that there didn’t seem to be a network problem, but their network monitoring software was still indicating the server was down.  They later said that the problem had been traced to an “application” problem.  Rebooting the server brought the connectivity back up with their monitoring software.  The application running on the bank server had stopped responding and blocked incoming requests from the vendor’s monitoring software. This is an example of network monitoring software only being as good as the application on the other end.