Archive for the ‘64-Bit’ Category

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 compatibility.

By Nicholas Greene

We already know that IPsec is here to stay, especially since it’s such an integral part of IPv6. So, how did IPv6 become so ingrained with IPsec? Why was IPsec developed in conjunction with IPv6, and how did it get to where it is today? To answer these questions, let’s quickly revisit the origins of IPsec.

Let’s go back to the 1990s, when (as most people think)  IPv6 was first being developed because of IP address exhaustion. But in reality, along with the address exhaustion, something else was abundantly clear to the Internet Engineering Task Force (IETE). During its inception, the Internet was a relatively private technology. Truth be told, I don’t think the original technology was ever intended to become the public platform that it is today. And as most people involved with networking will tell you, security for a private network is a very different beast than from public network security. A public security remedy is what the IETF ultimately realized was lacking as the Internet became increasingly public.

“The obvious need for securing content at layer three [the ‘network’ layer of the seven-layer OSI networking model] was what spurred the development of IPsec,” said Paul Hoffman, head of the VPN Consortium. “There is security for each protocol at each layer, and IPsec is for that IP.” See, as the Internet grew, a number of applications and protocols began to appear that SSL wasn’t really equipped or designed to deal with.

Essentially, SSL at the time, wasn’t well-suited for public networks.  There were two reasons for this. The first one: SSL was — and still is — software dependent, meaning it’s only able to secure specific applications. So SSL worked for the small, private networks, but this posed a problem with the birth of the Internet as we know it today. Since SSL wasn’t designed to work with the new applications, it couldn’t secure them. Granted, SSL/TLS nowadays can work for public networks, but back then, not so much.

Here’s the second reason. While SSL was suitable for establishing remote connections between systems, it provided no way of securing those remote connections against attack from the higher layers. The fact that these connections were so often insecure left the user’s machine — and data — vulnerable to outside access.

In light of these realities, a new security protocol became necessary. This excerpt from the TCP IP Guide explains:

“What was really needed was a solution to allow security at the IP level so all higher-layer protocols in TCP/IP could take advantage of it. When the decision was made to develop a new version of IP (IPv6), this was the golden opportunity to resolve not just the addressing problems in the older IPv4, but the lack of security as well.”

I’ve got to hand it to the folks at the IETF- they’ve got rather incredible foresight. They saw it all coming, and swooped in to kill two birds with one stone, tackling both the address exhaustion and the network security issue with IPv6. Of course, since they knew that network security would probably become a problem long before address exhaustion, we’re just now beginning to see the last of the 32-bit IPv4 addresses assigned.

I’ve noticed a bit of confusion as to the status of IPsec in the Internet Protocol Suite- namely, as to whether or not it’s mandatory in IPV6. I was told by Paul Hoffman that it’s never been mandatory…even though most sources cite it as a mandatory element. Why the contradiction?

Turns out, there’s actually some rather confusing wording related to IPsec’s status in IPV6.

Essentially, IPV6 lists IPsec implementation as mandatory. What this means is that IPV6 has to have IPsec available…but sysops don’t actually have to deploy that implementation. Either way, it’ll still be present in IPv6, should anyone choose to deploy it. So, ultimately, IPsec is definitely here to stay.

We’ve been seeing a lot of discussion in the forums about Cisco’s IPsec VPN client (welcome to the party—you’re four years late).  In 2010, a 64-bit client isn’t enough.  Perhaps four years ago this would work, but not today.  In today’s mobile world, users are constantly on-the-go and purchasing the latest and best devices—they need more than just a VPN client.

NCPs client was developed with both the user and administrator in mind.  When an employee is away on business, they need to connect and remain connected to the network hassle-free.  They need to be reassured that their desired device, whether it be a laptop, mobile phone, etc., will work with their VPN client and have access to the appropriate files, email, folders, etc. they need.

Overlapping subnets, roaming across networks and connections dropping shouldn’t be an issue.  Users should be able to use important features, such as two-factor authentication, end-point security software and personal firewalls without any IT knowledge or help desk support.  It should be a matter of a one-click and get connected.  Will a 64-bit IPsec VPN client be enough to meet customers’ remote access needs?  No, and we think you’ll agree.

Follow this discussion on Twitter @VPNHaus

Options for 64-bit Windows 7 VPN

Posted: November 10, 2009 in 64-Bit, Posts

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.


Posted: September 17, 2009 in 64-Bit, Posts, Windows 7

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.