问题场景

左边的支部，它的防火墙上联路由器，由于防火墙内部的接口使用的是私网地址，这就导致其无无法在公网上与对端防火墙进行IPsec的隧道建立 。所以必须在AR5上面不是NAT地址转换，由于一般使用的是NAPT，isakmp协议因为是UDP报文，且没有像AH或者ESP那样有对内容进行签名，所以可以正常地协商IKE SA以及IPsec SA，但是AH和ESP就没有那么简单了

 

 AH和ESP的认证范围如图所示，其实说是认证范围本质上来说应该是进行HASH运算的范围，如图所示，AH的签名范围是包括IP首部的，这就导致如若后续的AH报文在AR路由器上进行NAT转换后，目的端接收到该报文并进行hash值校验时会发现hash不匹配，所以将会导致数据包被丢弃。而对于ESP来说，虽然它的签名范围没有包括IP首部，但是如果在NAPT的场景下，也就是有进行端口复用的场景下，这也同样会导致目的端hash校验的不成功，但是在no-pat的场景下时可以的，但是一般不会这么做。所以就需要NAT穿越。

技术原理

说它是NAT穿越其实也是说的好听，其实又是一个套壳的技术，什么意思？如果你是传输模式，那么就是在IP首部和ESP之间再插入一个UDP首部，源目端口为4500，如果是隧道模式那么就是在新IP首部和ESP首部之间插入UDP首部，对于AH来说，因为它的校验范围是整个IP报文，所以它就和NAT无缘了。对于ESP来说，它的主要问题就是在进行NAPT的过程中端口被替换了，所以才会导致校验的时候出现问题，那么通过在IP首部和ESP首部之间插入UDP层来代替ESP里面的运输层首部进行端口替换就可以完美地解决这个问题。

部署场景和部署细节

场景1、一端做NAT，另一端没有做

在这种部署场景下，我大概说一下要部署的内容，首先左边的防火墙需要配置好IPsec的相关内容，要注意在定义ike peer的时候，要在ike peer视图下开启nat 穿越，输入nat traversal即可，同时需要指定好右边防火墙的地址，然后将相关的IPsec policy应用在接口上。AR路由器只要做NAPT转换即可。因为左边的防火墙使用的是NAT地址转换，有着屏蔽内网的作用，所以右边的防火墙可以直接做ipsec policy，此时指定的IP地址是AR路由器的出接口地址，即便如此右边的防火墙也只能被动的接受左边的防火墙的主动协商，因为NAT屏蔽了内网。也可以配置IPsec策略模板，自己不主动，被动接受协商就好了。右边的防火墙也要开启nat 穿越

场景2、两端都做NAT

 在这种两边都做NAT的情况下，我也大概说一下思路。因为在IPsec的协商过程中肯定是要有人主动进行协商的，所以在两边都被NAT屏蔽内网的情况下，肯定要有一端做nat server，否则协商报文过去后因为被NAT屏蔽了内网的缘故，路由器将无法响应该报文从而导致协商失败，所以我们需要在某一端上创建如下的nat server：

nat server protocol udp global 1.1.1.1 500 inside 192.168.0.1 500

上面这个nat server必须在被动接受协商的一端的路由器上配置

nat server protocol udp global 1.1.1.1 4500 inside 192.168.0.1 4500

这个必须在两端的路由器上都进行配置，如果不配置，那么会导致路由器上因为没有相应的NAT映射表从而导致报文的丢失。在没有开启nat keeplive的时候需要，如果不开启nat keeplive就需要在两端配置端口映射

那么为什么第一个不需要创建nat server？

首先因为左边的防火墙是隧道的主动协商者，且它也是处于NAT网关后的设备，所以虽然它的源地址和源端口会被修改，但是目的地址和目的端口都不会改变，也就是说相关协商报文到达右边的防火墙后是会被正常识别，所以右边的防火墙会正常的回复相关的协商报文，因为左边的防火墙主动发起报文，所以在AR路由器会存在相关的NAT表项，所以右边的防火墙回包的时候会被正常地进行地址转换并将报文转发给左边的防火墙，所以在这种情况下是不需要将500端口映射出去的，那么是否需要做第二条nat server呢？感觉要，但是其实不要，主要是防火墙默认开启了nat keeplive，在ipsec隧道建立之后，防火墙会周期性发送那条keeplive报文，这就使得路由器上的nat映射表得到了周期性的刷新，所以相对于做了一个隐形的端口映射，所以即便路由器上没有做4500端口的映射也可以保证流量的正常通信。

第一个nat sever的主要作用就是让路由器可以将响应的协商报文传递给内部的防火墙进行IPsec的隧道协商。第二个nat server的主要作用就是让esp报文可以进行正常的通过

那么两端的防火墙是如何发现存在NAT网关并将端口从500变为4500的呢？

IKE V1情况

因为ike v1不常用所以就大概说一下。在主模式的阶段一的一，二报文，双方会不仅协商ike sa，还会发送是否开启NAT穿越的标识。双方都知晓互相都开启了nat 穿越后，在阶段一的三，四报文中会携带local address and port hash和remote address and port hash，其含义是本地地址和端口的hash值，以及目的地址和端口的hash值，这些值是防火墙在发送的时候就定义在报文中的，如果对端在接收该报文的时候发现local的hash值以及remote的hash值都进行了改变，那么就说明在两个防火墙之间存在两个NAT网关，如果只是local变化了，那么就说明只有对端的防火墙的前面有NAT网关，如果是只有remote的hash值变化了，那么就说明只有本端的前面有NAT网关。防火墙在察觉了存在NAT网关的情况下，会将后续的五，六报文的源目端口修改为4500，同时后续的协商报文会在运输层首部后面多一层udp encapsulation层。

 

IKE V2的情况

在IKE v 2的IKE_SA_INIT报文中会直接携带NAT_DETECTION_SOURCE和NAT_DETECTION_DESTINATION这两个数据载荷，里面包含的值和IKEv1中的local和remote的hash值是一样的。如下图所示： 

 在后续IKE_AUTH的相互协商中同样也会将源目端口从500修改为4500，并在运输层首部后面多加了一层udp encapsulaion层

 

NAT和IPsec之间的冲突

如图所示目的地址和源地址转换是在VPN之前的，这就导致NAT的操作是先于VPN的，如果要进行VPN加密的报文先进行了NAT的地址转换，导致其原本该加密但是却因为地址转换后无法匹配相关感兴趣流，从而导致没有经过加密就将相关数据流发送出去。如果是nat server的情况下还有可能导致因为进行了nat server操作的缘故导致相关加密报文无法传达到防火墙上进行解封。所以在IPsec与NAT之间我们必须保证它们之间的流量没有任何交集。当然我们可以手动的进行合理的流量分离，也可以直接在nat 策略中明确指明要进行加密的流量是不进行nat操作的，且该策略是最优先匹配的，如下所示：

 在nat-policy中指明相关加密流量的action为no-pat即可