IKE is encapsulated as well

PAT and IPSec

PAT performs many-to-one translation for a range of internal IP addresses. PAT is generally supported with most TCP and UDP applications automatically, and ICMP requires some special handling.

Using IPSec over a PAT device will break the tunnel, as the PAT device has no algorithm to associate an incoming IPSec packet to the single global address with an inside VPN peer (there are no "ports" to remember with an IPSec connection). For that reason, Cisco has developed two proprietary solutions, which enable an IPSec tunnel to be established over PAT devices

■ Encapsulation of IPSec packets inside UDP, where the entire IPSec packet is additionally encapsulated with an UDP header, with the destination port of 10000. Such a session now looks like a plain UDP session to the PAT device, and can be bi-directionally routed over it.

Encapsulation of IPSec packets inside TCP, where the entire IPSec packet is additionally encapsulated with an TCP header, with the destination port of 80. Such a session now looks like a plain HTTP session to the PAT device, and can be bi-directionally routed over it.

With both encapsulations, the IKE protocol is encapsulated together with IPSec packets inside the same encapsulation session.

Any of the two encapsulations can be used to overcome difficulties with PAT. It must be noted, that the TCP (HTTP) encapsulation currently is not a "correct" TCP session in terms of sequence/acknowledgement numbers, and is dropped by any good stateful firewall, if one exists in the packet path. Therefore, if the encapsulated IPSec session has to cross a PAT device AND a stateful firewall, the UDP encapsulation is required.

The IETF is currently working to standardize the UDP encapsulation of IPSec packets. More information can be found in the published draft

■ UDP Encapsulation of IPSec Packets, http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-03.txt.

Supported Applications

Traffic types/applications supported:

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii Lisco.com • NetBIOS over TCP/IP (Datagram,

• Any TCP/UDP traffic that does not

Name, and Sespi (on Services)

ca rry sourc e and/or destination IP1

• White Pines' CcSeeMe

addresses i n the applicat ion data stream

• DNS "AS" and "PTR" Queries

• HTTP

• Xing TecOnologies' Streamworks

• H.323/NeoMeeting v.20 and v2.01

• TFTP

(4.3.2206)—12.0(1)/1 d.0(1 )T

• Telnet

• VDO—ve—11.3(4)/11.3(4)T

• Archie

• Vxtreme—11.3(4)/11.3(4)T

• Finger

• IP Multicast—12.0(1 )T—Source

• IN TP

Translation Only

• rlogin, rsh, rcp

Traffic types/applicationo not supported:

• NFS

• BOOTP

Although the following traffic types

• NetShow

carry/ IP addressas i n Nie application

data stream, they are supported by

Cisco IOS® NAT:

• Routing Table Updates

• ICMP

• DNS Zone Transfers

• SMTP

• SNMP

• FTP (including PORT and PASV

• peop^S^, SAP

commands)

• Oracle SQL, SQL*Net

© 2003, ^^Progressive Networks' RealAudio

DPP 1.0—2-2-32

The following is a list of protocols supported by Cisco's NAT implementation:

■ Any TCP/UDP traffic that does not carry source and/or destination IP addresses in the application data stream

■ TFTP Telnet Archie Finger NTP

Although the following traffic types carry IP addresses in the application data stream, they are supported by Cisco's NAT implementation:

■ FTP (including PORT and PASV commands)Progressive Networks' RealAudioNetBIOS over TCP/IP (Datagram, Name, and Session Services)White Pines' CuSeeMe

■ DNS "A" and "PTR" Queries Xing Technologies' StreamWorks

■ H.323/NetMeeting v.20 and v2.01 (4.3.2206)—12.0(1)/12.0(1)T

■ IP Multicast—12.0(1)T—Source Translation Only

Note that this list continues to grow, so network professionals who need to verify whether some specific protocol, not mentioned in the list, is supported or not are strongly encouraged to consult the Cisco web site.

Was this article helpful?

0 0

Post a comment