95 lines
7.1 KiB
HTML
95 lines
7.1 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html lang="en-us" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="security" content="public" />
|
|
<meta name="Robots" content="index,follow" />
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|
<meta name="DC.Type" content="concept" />
|
|
<meta name="DC.Title" content="NAT compatible IPSec with UDP" />
|
|
<meta name="abstract" content="UDP encapsulation allows IPSec traffic to pass through a conventional NAT device. Review this topic for more information about what it is and why you should use it for your VPN connections." />
|
|
<meta name="description" content="UDP encapsulation allows IPSec traffic to pass through a conventional NAT device. Review this topic for more information about what it is and why you should use it for your VPN connections." />
|
|
<meta name="DC.Relation" scheme="URI" content="rzajavpnprotocols.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rzajaupdscenario.htm" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2000, 2006" />
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2000, 2006" />
|
|
<meta name="DC.Format" content="XHTML" />
|
|
<meta name="DC.Identifier" content="rzajaudpencap" />
|
|
<meta name="DC.Language" content="en-us" />
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|
<!-- US Government Users Restricted Rights -->
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
|
<title>NAT compatible IPSec with UDP</title>
|
|
</head>
|
|
<body id="rzajaudpencap"><a name="rzajaudpencap"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">NAT compatible IPSec with UDP</h1>
|
|
<div><p>UDP encapsulation allows IPSec traffic to pass through a conventional
|
|
NAT device. Review this topic for more information about what it is and why
|
|
you should use it for your VPN connections.</p>
|
|
<div class="section"><h4 class="sectiontitle">The problem: Conventional NAT breaks VPN</h4><p>Network
|
|
address translation (NAT) allows you to hide your unregistered private IP
|
|
addresses behind a set of registered IP addresses. This helps to protect your
|
|
internal network from outside networks. NAT also helps to alleviate the IP
|
|
address depletion problem, since many private addresses can be represented
|
|
by a small set of registered addresses.</p>
|
|
<p>Unfortunately, conventional
|
|
NAT does not work on IPSec packets because when the packet goes through a
|
|
NAT device, the source address in the packet changes, thereby invalidating
|
|
the packet. When this happens, the receiving end of the VPN connection discards
|
|
the packet and the VPN connection negotiations fail.</p>
|
|
</div>
|
|
<div class="section"><h4 class="sectiontitle">The solution: UDP encapsulation</h4><p>In a nutshell, UDP
|
|
encapsulation wraps an IPSec packet inside a new, but duplicate, IP/UDP header.
|
|
The address in the new IP header gets translated when it goes through the
|
|
NAT device. Then, when the packet reaches its destination, the receiving end
|
|
strips off the additional header, leaving the original IPSec packet, which
|
|
will now pass all other validations.</p>
|
|
<p>You can only apply UDP encapsulation
|
|
to VPNs that will use IPSec ESP in either tunnel mode or transport mode. In
|
|
addition, at v5r2, the iSeries™ server can only act as a client for UDP encapsulation.
|
|
That is, it can only <em>initiate</em> UDP encapsulated traffic.</p>
|
|
<p>The graphics
|
|
below illustrate the format of a UDP encapsulated ESP packet in tunnel mode:</p>
|
|
<dl><dt class="dlterm">Original IPv4 datagram:</dt>
|
|
<dd><br /><img src="rzaja521.gif" alt="Graphic showing an IPv4 datagram with IP header followed by Payload data" /><br /> </dd>
|
|
<dt class="dlterm">After applying IPSec ESP in tunnel mode:</dt>
|
|
<dd><br /><img src="rzaja522.gif" alt="Graphic showing datagram after applying IPSec ESP in tunnel mode. New IP header followed by ESP header followed by Original IP header followed by Payload data followed by ESP Trailer followed by ESP authentication" /><br /></dd>
|
|
<dt class="dlterm"> After applying UDP Encapsulation:</dt>
|
|
<dd><br /><img src="rzaja523.gif" alt="Graphic showing datagram after applying UDP Encapsulation. New IP header followed by UDP header followed by ESP header followed by Original IP header followed by Payload data followed by ESP Trailer followed by ESP authentication" /><br /></dd>
|
|
</dl>
|
|
<p>The graphics below illustrate the format of a UDP encapsulated
|
|
ESP packet in transport mode:</p>
|
|
<dl><dt class="dlterm">Original IPv4 datagram:</dt>
|
|
<dd><br /><img src="rzaja521.gif" alt="Graphic showing an IPv4 datagram with IP header followed by Payload data" /><br /></dd>
|
|
<dt class="dlterm">After applying IPSec ESP in transport mode:</dt>
|
|
<dd><br /><img src="rzaja524.gif" alt="Graphic showing datagram after applying IPSec ESP in transport mode. Original header followed by ESP header followed by Payload data followed by ESP Trailer followed by ESP authentication" /><br /></dd>
|
|
<dt class="dlterm">After applying UDP Encapsulation:</dt>
|
|
<dd><br /><img src="rzaja525.gif" alt="Graphic showing datagram after applying UDP Encapsulation. New IP header followed by UDP header followed by Original IP header followed by ESP header followed by Payload data followed by ESP Trailer followed by ESP authentication" /><br /></dd>
|
|
</dl>
|
|
<p>Once the packet is encapsulated, the iSeries sends the packet to it's VPN
|
|
partner over UDP port 4500. Typically, VPN partners perform IKE negotiations
|
|
over UDP port 500. However, when IKE detects NAT during key negotiation, subsequent
|
|
IKE packets are sent over source port 4500, destination port 4500. This also
|
|
means that port 4500 must be unrestricted in any applicable filter rules.
|
|
The receiving end of the connection can determine whether the packet is an
|
|
IKE packet or a UDP encapsulated packet because the first 4 bytes of the UDP
|
|
payload are set to zero on an IKE packet. For it to work properly, both ends
|
|
of the connection must support UDP encapsulation.</p>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzajavpnprotocols.htm" title="It is important that you have at least a basic knowledge of standard VPN technologies. This topic provides you with conceptual information about the protocols VPN uses in its implementation.">VPN concepts</a></div>
|
|
</div>
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
|
<div><a href="rzajaupdscenario.htm" title="In this scenario, a large insurance company wants to establish a VPN between a gateway in Chicago and a host in Minneapolis when both networks are behind a firewall.">Scenario: Firewall Friendly VPN</a></div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html> |