RE: VPN ports

[Wozny, Scott]

Title: RE: VPN ports

Andy is absolutely right about the difference between a protocol and a port and it's important to make the distinction as it is the root cause of the problems with combining IPSec and NAT.  Some VPN tunnel clients on the market now have functionality being referred to as "NAT traversal" which basically says that since IPSec doesn't run over a standard TCP or UDP port it generally can't be NATed (however, to stir it up a bit, I've heard of hacked together, proprietary implementations of NAT that can do it, but need to watch the entire session setup to decode the tunnel endpoints and build a separate NAT table for them; a VERY processor intensive process).  The Enterasys RiverPilot client Version 3.1 (and before I get flamed for bias, I welcome anyone else's suggestion for ways around this, I am just providing the one I know about) does NAT traversal by attempting to initiate a native IPSec session and if it fails for whatever reason resends the IPSec packets as the payload of an https over SSL packet (TCP port 443 which CAN be NATed) to the tunnel server.  Yes, it's additional overhead, but since IPv6 isn't getting out there (apps or Home OS support) fast enough to cover the need for address space more ISPs will start to do more and more NATing.  I know RR.com on Staten Island NATs once to the main RoadRunner network and then once more to the Internet depending on what service you pay for (found this out by establishing connections within the RR AS (Manhattan to Staten Island) and outside the RR AS (RR Staten Island to a small ISP in Canada) for a friend that was having troubles getting his VPN to work from his broadband connection).

 

Morrow's earlier suggestion may resolve the issue if the only NATing device between the client and the tunnel server is the Linksys (just by getting the Linksys to stay out of the way and use the NATed address as the SIP in an IPSec tunnel, but you won't be able to run more than one tunnel through the LinkSys that way).  If the ISP is NATing too, you need to have some mechanism to do NAT traversal.  Either on the ISPs NATing device (and we all know how accommodating big ISPs can be with requests like that :) ) or on the client software.

 

So Diana, my suggestion to you is to ask you friendly neighbourhood Cisco rep or reseller what and when they plan to offer on their client for NAT traversal.  It may already be out for all I know and you may just need to turn the feature on.

 

Good luck.

 

Regards,

 

Scott A. Wozny

Enterasys, NYC

-----Original Message-----
From: Lemke, Andy [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 10:31 AM
To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: RE: VPN ports

IPSEC doesn't used TCP ports 50 or 51.  It uses "protocol 50" and "protocol 51".  (TCP itself is protocol 6).

You might want to read up on your ports and protocols at www.iana.org.

I doubt that you'll be able to get this to work because NAT is completely impossible if you want full IPSEC.

-Andy

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 15, 2001 10:23 AM
To: [EMAIL PROTECTED]
Subject: VPN ports

Hi all,

One of my users have a DSL at home and he has a Linksys BEFW1154 cable/DSL
modem.  We are having trouble connecting to the office via VPN using the
Cisco VPN client.  At the office we have a Cisco VPN concentrator and it is
configured for IPSEC.  We have tried opening ports 50, 51, 1701 and 10000.
BTW, he is also doing NAT.    I didn't think there is any other ports that
need to be open.  Any ideas?

Thanks.
Diana

_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls

The sender believes that this E-mail and any attachments were free of any virus, worm, Trojan horse, and/or malicious code when sent. This message and its attachments could have been infected during transmission. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective and remedial action about viruses and other defects. The sender's employer is not liable for any loss or damage arising in any way from this message or its attachments.