Options for 64-bit Windows 7 VPN

Big news today from Cisco as reported by Network World:

Cisco (NASDAQ: CSCO) is warning customers of its unified communicationsWindows 7 will be supported. Products that support for Windows 7 won’t be forthcoming until the product’s 8.0 release scheduled for the first quarter of 2010. About a dozen more UC products will not support Windows 7 until version 8.5, in the third quarter of 2010 and at that time, only the 32-bit version of.

For customers who need IPsec 64-bit support, NCP engineering can help you out. The “beta” version of the client is scheduled to go release candidate any day now too.

Remote Access without User Obstacles

There’s a great podcast featuring a friend of NCP engineering, Lisa Phifer, vice president of Core Competence, that outlines a few good steps network administrators can take to help protect the network from threats caused by traveling employees accessing it from unsecured public  hotspots.  While Lisa offers great technical advice on VPN and personal firewall settings, and hotspot danger warning signs, she makes two poor assumptions.

First, Lisa assumes the network administrator can educate each and every traveling employee, or user, on these best practices. Secondly, she assumes the users will choose safety over convenience. Let’s face it, the average user isn’t technical, doesn’t want to be bothered and simply wants Internet / network access.

We’ve seen this situation many times and continue to recommend combining user education with a remote access technology that takes the user completely out of the picture. With an ‘intelligent’ remote access solution, network administrators can provision VPN clients, centrally manage each personal firewall and enforce policy all from the admin side. All the user sees is his or her device turning on, finding the hotspot and connecting to the Internet through the secure network.

What is equally important to in this situation is endpoint security, beyond simply the VPN.  An infected device that is connected to the network will cause just as much harm as a clean device that has fallen prey to a man-in-the-middle attack.  Before users are granted a VPN connection, a full sweep or ‘pat-down’ of the device should take place.  This pat down checks the device and make sure anti-spyware, anti-virus and anti-malware software are up-to-date. If something is lax then the user is instructed how to remedy the issue and asked to re-establish a connection.

If network administrators add these tips to those gleaned from Lisa’s podcast, the network will be safe and the company’s employees will be able to access the Internet and network safely from anywhere they happen to be.

Pat the Device Down

Read an interesting article on InfoWorld earlier this week about the iPhone falsely reporting VPN policies and encryption support.  While the iPhone has been updated and fixed, miscommunication with Exchange VPN servers brings up a larger question—should the server do more than just query the device client and should the enterprise VPN take on a NAC function through a device ‘pat down’?

Allowing for a full ‘pat-down’ before allowing a VPN connection, the NCP Secure Enterprise Management System looks at the actual individual device rather than a standard set of queries.  NCPs ‘pat down’ checks and makes certain that security software is up-to-date, the right form of encryption is being used, firewall settings are enabled, and the machine is compliant to pre-set network policy enforcement parameters.  By running this pat-down, the administrator will be reassured its employees’ devices are compliant, and those who aren’t are alerted to take the necessary steps to reach compliance.  Without an endpoint device ‘pat-down’ enterprise remote access can be compromised, just as the InfoWorld article illustrates.

For more information on this issue, check out a recent article published in Processor or visit http://www.ncp-e.com/en/solutions.html.

YES to VPN

NCP has recently been selected to provide end-point security solutions for Texas-based YES Prep Public Schools.  The school’s IT manager needed a secure VPN solution that would not only allow staff access to the Intranet, but also flexibility to integrate the solution to existing and future devices and operating systems.  NCP Secure Entry Client provided 64-bit support to gain access to the network and prepared the school’s migration to Windows 7.

As we’ve blogged in the past, the need for end-point security is critical for school systems.  Security breaches do affect this market, and hackers gain access to student’s personal records, school internal documents and other confidential data.   Education institutions need to be ware and take action to protect their network, and the most effective way to this is with a VPN.

NCPs universal client provides YES’ teachers with secure and constant communications to the Intranet, where they can access lesson plans and student files immediately.  It also enables YES staff to be in contact with each other in the seven different locations.  This access is important to YES because it grants students with the quality education they deserve.  The entry client saved YES from downgrading their 64-bit machines to 32-bit; and the client will work on new operating system, Windows 7.

For more information on this issue, check out a recent article published in Processor.

Lost Connections? Overlapping Subnets may be your culprit

Having trouble connecting to the network when you are on the road?  Don’t worry, you are not alone.  When traveling, many users report issues to their network administrators stating they cannot access the company’s network.  Employees complain that they either had connection and it was dropped; they were connected, but no VPN access; or simply no connection could be made.  All of these are common signs of overlapping subnets.

An overlapping subnet is when you establish a connection from the VPN client to another network with the same ‘private IP address range’, and an ‘overlap’ occurs with the addresses.  I.e. the hotel router assigns your machine a ‘private IP address range’, i.e. 192.168.1.0, and this address matches the office’s.  When the client connects, it uses the source IP address it currently has, which is the home network.  The gateway sees this as an internal (local) address, and thus subnets overlap  and deny your VPN connection.

Here is a technical description NCP shared with us:

IPsec includes two negotiation phases; phase 1 authenticates and negotiates a secure channel to set up a Phase 2 tunnel.  Phase 1:  ‘ISAKMP/IKE’ takes place over UDP500.  Once the negotiations have taken place, one or more IPsec tunnel(s) is created in Phase 2 (between the two peers—client and the gateway.  Traffic is sent using ESP (Encapsulated Security Payload) Frames, which are not within UDP or TCP, except ESP = IP Protocol 50; something ‘parallel’ as it were to the aforementioned TCP or UDP.  However, if there’s a router or firewall in between that performs Network Address/Port Translation (aka Network Address Translation) these packets will either be dropped or modified (modified, meaning tampered with, therefore being dropped by the gateway or client).  Some routers/firewalls allow for ‘ESP Pass-through’, meaning these ESP frames will not be dropped and it’ll work.

99% of the time there is going to be NAT performed on the packets.  In order to circumvent this problem, the ESP frames are wrapped inside UDP packets which may be modified/touched by the routers.  Once they arrive at either the two peers, the outer (modified) UDP headers are stripped off, revealing the untouched ESP frames which then can be processed.  This UDP encapsulation is called NAT-Traversal or NAT-T.

Back to our original definition, IPsec uses UDP 500 and ESP frames, the latter may be encapsulated within UDP 4500 (or variable; other gateways sometimes use UDP10000).

We will follow up on this topic with solution in a later post—stay tuned.