Hotel VPNs: When the firewall strikes back, Part Two

In part one of this two-part series, we explored the problem that many IPsec users face when trying to connect to their corporate network from the road, especially hotels. This being, some hotels block IPsec ports because of the misconception that SSL is universally employed. So what’s the solution? Firstly, for security reasons, users should not deactivate the firewall or the proxy server. However, compelling a hotel guest to send or receive sensitive information via unsecured connections is no option either. Even using SSL is not a suitable for all situations, as SSL does not provide the same level of security as IPsec. And to further complicate matters, SSL only works with applications that are optimized for browser access. However, there is a third option that combines the best of both worlds: NCP’s VPN Path Finder Technology. When a guest wants to establish a connection to his company network from a hotel, NCP’s Secure Client automatically recognizes if the company’s VPN gateway is not available via IPsec. In this case, the client software automatically switches to a modified IPsec protocol mode.This modified IPsec mode uses a TCP encapsulation and prefixes a SSL header. The IPsec client simulates a SSL connection via the standard HTTPS Port 443 and uses it to establish an IPsec tunnel to the company network. The main advantage of this solution: there is no discernible change for users. They continue using all their regular authentication mechanisms — and reap the benefits of IPsec. Also, the corporate system administrators can enforce this security policy without having to make exceptions for single users who would undermine the company’s security concept....

How can I make sure my VPN is encrypted and working properly?

*Editor’s Note: These columns originally appeared in TechTarget’s SearchEnterpriseWan.com By Rainer Enders, CTO of Americas for NCP engineering The simplest way to do this is to act like a hacker. Snoop around the network traffic, either on the device itself or a port on the network. In the case of IPsec, for example, you would see encapsulating security payload (ESP) frames (Protocol 50).  Yet, when you look inside the packet payload, you will only see garbled characters — no clear text at all. Network snooping tools are easily available on the Internet and are simple to use. Of these, Wireshark is probably the most popular tool. You may find this resource on how to do penetration testing on your VPN useful. Can I compare performance metrics of an MPLS VPN to another network? This is a very complex question that is difficult to answer without knowing the specifics. Performance assessments can range in effort and complexity. It is ultimately important to understand the underlying requirements, which will determine the parameters that are relevant to performance. So, first you want to define “performance:”  What are the relevant parameters, such as throughput, latency, packet loss and jitter? Once you measure the aforementioned metrics of your Layer 2 and Layer 3 MPLS VPN networks, you should be able to compare them...

From the Trenches: Worst IT Mistakes I’ve Seen, Part 1

By Chuck Romano If you do any kind of tech work today, then you must be very familiar with doing help desk support or administration using remote access.  Your scenario could be administering 100s of PCs on a corporate network, spread across different geographical locations, or it can be providing help desk support to a residential or small business client. In my 10+ years of experience as a repair tech, I’ve seen my fair share of mistakes that can be made in the world of IT and remote access. In fact, here’s a very common scenario that comes up: You are tasked with removing malware from a remote PC.  Time constraints, efficiency, and location make remote access the best way to clean the computer. Yet this presents challenges right off the bat, because not only do you need to remove the problem on the target computer, but you have to make sure that the computer and network that you are working from stays clean.  Anyone else deal with that? Sure, each scenario will present unique challenges and specialized configurations, but they really boil down to making reliable remote connections while retaining the proper level of security. Here’s my list of the worst IT mistakes related to remote access that I’ve seen. Ignoring the Vulnerabilities in SSL VPNs This is probably one of the most important security aspects in a VPN or remote access situation.  Remote access is basically creating a connection between two endpoints.  Once that connection is established, those endpoints can share information, good or bad.  No matter what kind of connection software and encryption methods are being...

Some VPNs still face compatibility, connection issues

As more and more companies are enabling remote access for their workforce, stability and compatibility are becoming as crucial as security in ensuring employee productivity. This trend is highlighted by recent news that both Certona and 3marketeers have rolled out NCP engineering’s Secure Client-Juniper Edition IPsec VPN to solve, not only security, but also stability and compatibility problems they faced with previous VPN deployments. NCP’s IPsec VPN client software has provided both companies with a more stable VPN connection and supported their migration to Windows 7 32-/64-bit PCs, while also seamlessly integrating with their existing VPN gateways from Juniper Networks. Despite only deploying the solution a short while ago, Dan Ruyle, Director of Information at Certona called NCP’s solution his “go-to answer for our enterprise’s secure remote access concerns.” Willy Lam, director, application development, 3marketeers added that “Juniper’s recommendation of the NCP Secure Client – Juniper Edition proved to be spot on.” The NCP Secure Client – Juniper Edition replaced Juniper’s own end-of-life Netscreen-Remote VPN. It includes data encryption, support of mobile connect cards, and one-time password token and certificate support through a public key infrastructure. It seems the new trifecta for ensuring successful VPN deployments – security, stability and...

War Stories: The Faux DHCP Server

By Jeff Orloff It was the day before the state’s standardized testing day, and I received a call from the assistant principal. At the school district where I was working, standardized testing is done mostly online, so it was certainly bad news when the assistant principal told me that half of the computers in the facility were not working. The school, located in a juvenile detention facility, had about 60 students using computers in eight  different rooms with three servers; a domain controller, an application server, and a media server for online courses that the students could take. When I arrived at the school, one of the teachers showed me the strange problem. The teachers could not access any of the practice tests, retrieve documents, or access data from other network based applications. They could, however, get online and students could access their online courses — but the videos that delivered lectures were lagging. Rogue Device to Blame The computers were obviously attached to a network, since they were able to access the Internet. But running the simple IPCONFIG test on the computers showed a Class C network address opposed to the Class A block that was given out to all computers on the district network. Immediately, I thought that somehow our computers were connecting to the detention facility’s network. Checking one of their computers, I noticed that they, too, were using Class A IP addresses. Now I was starting to worry. Clearly, something was on the network that was acting as a DHCP server. It would have been easy to ask the teachers if they had brought in...

Split Tunneling: Part II

Last month, we wrote about Rene Poot’s thoughts on split tunneling.  Here is the second installment from that conversation: Spilt tunneling can also be used in conjunction with the local firewall that comes with the NCP client.  Rather than locking the user in to the tunnel as described earlier, one can also just use a shorter list of the subnets or hosts that can be reached from home via the VPN tunnel at the corporate side, and all other is simply dropped by the local VPN client’s firewall.  The user can then try to access expedia.com (our example from before), but it is simply dropped. It all depends on how secure one wants to lock down this remote resource.  He or she can extend the full restrictive measures imposed on the corporate environment to the machine at home or on the road as if they’re still partaking in the central network, or choose to be less restrictive using a combination of split tunneling and firewall rules on the client. It should be mentioned that Cisco gateways will most often ‘publish’ these ‘whitelists’ to the client during the negotiations, and so the ‘split tunneling’ list is populated automatically.  Other gateways don’t supply this, and so the client MUST either define it manually or automatically be locked in. A helpful resource Rene recommends is Security Now podcast: episode 208 Follow this discussion on Twitter...