Ads by TechWords
Subscribe to our e-mail newsletters
For more info on a specific newsletter, click the title. Details will be displayed in a new window.
Computerworld Daily News (First Look and Wrap-Up)
Computerworld Blogs Newsletter
The Weekly Top 10
More E-Mail Newsletters 

Looking for IPSEC VPN solution? Try Cisco

By Alex Scoble on Fri, 09/30/2005 - 10:52pm

Was talking to Greg Hughes today about VPN solutions. Had an interesting conversation as far as IPSEC clients go.

For most IPSEC clients, the fact that their tunnels don't go over the normal web ports (80 and 443) is a big disadvantage. Some hotels, colleges and other networks block pretty much anything but port 80 and 443 or require you to use a proxy for other services. This means that an IPSEC client like Netscreen Remote (or SonicWall's client, or WatchGuard's client, or any client based on the same client that they all use) is completely nonfunctional when used in this sort of network.

Anyhow, found out from Greg that Cisco's VPN client (most likely when used with a Cisco Pix firewall) can be set up to send IPSEC traffic over port 443. This means that even though their client is still sending IPSEC traffic, because it creates the tunnel on port 443 it will have no problems working when a user is in one of those more restrictive networks.

I'm sure that Checkpoint's client has similar functionality, but most companies will find it hard to justify the cost of a Checkpoint firewall.

The point is that if you are looking for an all in one hardware/software firewall and VPN solution, take a closer look at the Cisco Pix line of firewalls. Sounds to me like you will be glad you did.

For the rest of us, there's always SSLExplorer. :)

By the way, after I wrote this, I saw that Greg had posted more info on this on his blog.

For client based VPN solutions, he obviously favors Cisco's client (what I wrote above is a very good reason why), but I personally favor clientless VPN solutions as they are easier to deploy and manage, in my opinion.

Ahhh, welcome to the dark side, friend. Cisco, Starbucks and Microsoft. Heh...

I'll post some details, too. Note that you can configure connections with the Cisco VPN clinet in this way to do Port 80 if you want, and you can specify TCP or UDP. Between the ports and porotocol combinations, you can pretty much always connect with one of those, regardless of where you are.

Posted on Sat, 10/01/2005 - 1:51am

Hehe, I have nothing against Cisco products. Have just found their products to be generally too expensive for the small business market.

This is just another example of how life is. If I had known that the Netscreen 25 would not support manual key dial-up VPNs and had I known that the Cisco client had this functionality, I would have taken a much harder look at the Cisco products.

Or I would have taken a look at some of the available SSL VPN firewall boxes out there.

Lesson to be learned there...always look at alternatives even if you think you are satisfied with current vendor. If you don't look and poke around, you'll never find out that some other product can meet your needs better. Mea culpa.

Luckily, I can resolve the issue with SSLExplorer for free, although as good as the product is, I think that buying SSLExplorer Xtra would be warranted.

Posted on Sat, 10/01/2005 - 2:56pm

While I like NetScreen and Cisco, I have gone with MS ISA 2004 for a VPN Client/Server. The NS Remote is very limited, and pretty buggy from my experiences, and I am no longer a fan of using Manual/Pre-Share keys with VPNs. I moved to using certificates from a Windows enterprise CA and using RADIUS with ISA to authenticate L2TP/IPSec right at windows login. I am somewhat afraid of an SSL VPN since you can't ensure what the client PC has installed, or who has access to it. I do like this work around, but I think in 12 months it might be hard if people start implimenting SPI/proxy. I think ports were originally designed to seperate services, but now it seems everything under the sun runs on 80/443. VPN, Email, IM, VoIP, etc.

What are your thoughts on this greater problem of port blocking?

Posted on Tue, 10/04/2005 - 2:49pm

Be careful what these posters are saying.

IPSec is layer2 (ESP), to change to TCP or UDP and give it a port number for example 443 is all well and good. That is not the same as Ciscos SSL solution, which is an SSL vpn, not IPSec. The biggest problem with IPSec on the go is NAT traversal, not firewall blocking I think they may find. SSL VPN is easier and clientless (well the web browser is the client so thats not actually true) and has poorer security to match the increased ease of administration. You will also want to investigate what you wish to actually do over the VPN before investing in any solutions.

Posted on Wed, 10/12/2005 - 8:19pm

The Cisco solution is NOT SSL. It is rerouting of IPSEC protocols over a set port, 80 or 443 for instance. Not the same as SSL because the traffic is still IPSEC, it's just getting processed and handled over ports that are more widely available in the wild.

By the way, for all intents and purposes SSL VPNs are clientless as there is very little if any configuration that needs to be done on the remote PC side of things, which is the whole point.

All modern PCs have a browser and most have a Java virtual machine, so it's a no brainer to use SSL for most organizations.

Those that need the extra security that IPSEC provides will still want to go that route, however.

Posted on Fri, 10/14/2005 - 1:39am

Look, Cisco arent the only ones that can encapsulate ESP, eg Lucent can encapsulate the entire ESP packet in UDP of a port of your choice. As a solution to NAT travseral, most modern IPSec providers allow some form of tunnel mode IPSec (UDP encapsulation). See
for details of how that works.

As for Cisco SSL VPN, what can I say? Read

Posted on Sun, 10/16/2005 - 6:52pm

I think you are missing the point completely. Cisco's VPN solution allows for the tunnel to be routed over any TCP or UDP port statically.

The inability of most VPN clients to not choose the port is a sizeable problem in IPSEC deployments that wreaks havoc on the lives of IT admins. Ever try troubleshooting an IPSEC problem over the phone? It's a complete mess and most of the time we CAN'T do ANYTHING to help the user as the problem is caused by the setup of networks that we CANNOT control.

Which is why encapsulation of the packets through TCP port 80 or 443 is so important as these are open 99.99% of the time, whereas the transports required for native IPSEC are blocked in enough circumstances to make it a headache for IT managers.

And the solution that Cisco's IPSEC client employs has NOTHING to do with SSL, other than the fact that it can use the same port.

Posted on Mon, 10/17/2005 - 2:21pm

Symantec Backup Exec System Recovery—Restore Systems Anytime, from Anywhere to Virtually Any Device
Restore Windows® systems quickly, easily, and reliably to dissimilar hardware, virtual environments or in remote, unattended locations. Watch this Symantec webcast to learn how you can perform bare metal system recovery in minutes, meet and exceed service level agreements and recovery time objectives, and minimize requirements for remote on-site IT support.
View this webcast 
The Real Deal: Protecting your Windows Systems
This webcast explores challenges that Windows shops face today and strategies for ensuring data protection. We discuss backing up business information on desktops, laptops or servers, the major vulnerabilities in Windows—based systems, and how Symantec Backup Exec and Symantec Client Security team up to offer the real deal in Windows protection.

View this webcast 
Don't Make Me Come Over There – Tapping Into The Power of Symantec pcAnywhere's Improved Connectivity
Learn how Symantec pcAnywhere can extend your IT administration reach and enable you to connect anytime, anywhere. We'll show you tips and tricks for connecting to servers, desktops, and mobile computers, faster and easier. pcAnywhere Access Server, the pcAnywhere gateway, web remote and the host invitation features will also be presented.

View this webcast