在 NAT 技術和 IPsec 技術的應用都非常廣泛。但從本質上來說，兩者是存在著矛盾的。
1. 從 IPsec 的角度上說， IPsec 要保證資料的安全，因此它會加密和校驗資料。
2. 從 NAT 的觀點來看，為了完成地址轉換，勢必會修改 IP 地址。
IPSec 提供了點對點的 IP 通信的安全性，但在 NAT 環境下對 IPSec 的支持有限， AH Protocol是肯定不能進行 NAT 的了，這和 AH 設計的理念是相違背的； ESP Protocol在 NAT 環境下最多只能有一個 VPN 主機能建立 VPN 通道，無法實現多台機器同時在 NAT 環境下進行ESP 通信。關於 IPSec 在 NAT 環境下的需求問題在 RFC3715 中進行了描述。
NAT 穿越 (NAT Traversal ， NAT-T) 就是為解決這個問題而提出的， RFC3947 ， 3948 中定義，在 RFC4306 中也加入了 NAT-T 的說明，但並沒廢除 RFC3947 ， 3948 ，只是不區分階段 1 和階段 2 。該方法將 ESP Protocol封包封裝到 UDP 封包中（在原 ESP Protocol的 IP 封包頭外添加新的 IP Header和 UDP Header），使之可以在 NAT 環境下使用的一種方法，這樣在 NAT 的內部網中可以有多個 IPSec 主機建立 VPN 通道進行通信。
AH 封裝： AH 封裝的校驗從 IP Header開始，如果 NAT 將 IP 的 Header改動， AH 的校驗就會失敗，因此我們得出結論，AH 是無法與 NAT 共存的。ESP 封裝的傳輸模式：對於 NAT 來說， ESP 封裝比 AH 的優勢在於，無論是加密還是完整性的校驗， IP Header部都沒有被封包括進去。但是還是有新的問題，對於 ESP 的傳輸模式， NAT 無法更新上層Check Sum。TCP 和 UDP Header封包含一個Check Sum，它整合了源和目標 IP 地址和Port Number的值。
當 NAT 改變了某個封包的 IP 地址和（或）Port Number時，它通常要更新 TCP 或 UDP Check Sum。當 TCP 或 UDP Check Sum使用了 ESP 來加密時，它就無法更新這個Check Sum。由於地址或端口已經被 NAT 更改，目的地的Check Sum檢驗就會失敗。雖然 UDP Check Sum是Option的，但是 TCP Check Sum卻是必需的。
ESP 封裝的 Tunnel模式：從 ESP Tunnel模式的封裝中，我們可以發現， ESP Tunnel模式將整個原始的 IP 封包整個進行了加 密，且在 ESP的 Header外面新加了一層 IP Header，所以 NAT 如果只改變最前面的 IP 地址對後面受到保護的部分是不會有影響的。因此， IPsec 只有採用ESP 的 Tunnel模式來封裝資料時才能與 NAT 共存。
由於完整性Check牽涉到 IP Header部，所以 NAT 無法對其修改，不相容。
ESP 的傳輸模式，因為 TCP 部分被加密， NAT 無法對 TCP Check Sum進行修改，不相容。
ESP 的 Tunnel模式，由於 NAT 改動外部的 IP 而不能改動被加密的原始 IP ，使得只有這種情況下才能與 NAT 共存。
NAT 穿越 (NAT Traversal ， NAT-T)
以前 NAT 和 IPsec 只能以 1 對 1 的形式共存， NAT-T 打破了這種形式。而且NAT-T 支持 ESP 的傳輸模式。NAT-T 的基本思想：
將 ESP Protocol封包封裝到 UDP 封包中（在原 ESP Protocol的 IP 封包頭外添加新的 IP Header和 UDP Header）。使得 NAT 對待它就像對待一個普通的UDP 封包一樣。而且支持 ESP 的傳輸模式。NAT-T 的基本原理和執行步驟
1. 檢測通信中是否存在 NAT 設備和對方是否支持 NAT-T NC
2.檢測對方是否支持 NAT-T 是通過交換 vendor ID 載荷來實現的，如果自身支持 NAT-T ，在 IKE 開始交互就要發送這種載荷，載荷內容是“ RFC 3947 ”的 MD5 值，也就是十六進制的“ 4a131c81070358455c5728f20e95452f ”
2.檢測對方是否支持 NAT-T 是通過交換 vendor ID 載荷來實現的，如果自身支持 NAT-T ，在 IKE 開始交互就要發送這種載荷，載荷內容是“ RFC 3947 ”的 MD5 值，也就是十六進制的“ 4a131c81070358455c5728f20e95452f ”
