使用模板方式可以在总舵与公网IP不固定的分舵之间建立IPSec隧道。至此，无论是拥有固定公网IP的分舵还是动态获得公网IP的分舵，都可以通过IPSec安全地访问总舵，天地会业务兴隆一片祥和。
但Internet的江湖远非如此平静，天地会又面临新的问题。有的分舵连动态的公网IP都没有，只能先由网络中的NAT设备进行地址转换，然后才能访问Internet，此时分舵能否正常访问总舵？另外，分舵除了访问总舵之外，还有访问Internet的需求，有些分舵在网关上同时配置了IPSec和NAT，两者能否和平共处？
IPSec隧道途径NAT设备，NAT穿越力保畅通无阻
先来看网络中存在NAT设备的情况，如下图所示，分舵网关B的出接口IP是私网地址，必须经过NAT设备进行地址转换，转换为公网IP之后才能与总舵网关A建立IPSec隧道。
我们都知道，IPSec是用来保护报文不被修改的，而NAT却专门修改报文的IP地址，看起来两者水火不容，我们来详细分析一下。首先，协商IPSec的过程是由ISAKMP消息完成的，而ISAKMP消息是经过UDP封装的，源和目的端口号均是500，NAT设备可以转换该消息的IP地址和端口，因此ISAKMP消息能够顺利的完成NAT转换，成功协商IPSec安全联盟。但是数据流量是通过AH或ESP协议传输的，在NAT转换过程中存在问题。下面分别看一下AH和ESP报文能否通过NAT设备。
- AH协议
因为AH对数据进行完整性检查，会对包括IP地址在内的整个IP包进行Hash运算。而NAT会改变IP地址，从而破坏AH的Hash值。因此AH报文无法通过NAT网关。
- ESP协议
ESP对数据进行完整性检查，不包括外部的IP头，IP地址转换不会破坏ESP的Hash值。但ESP报文中TCP的端口已经加密无法修改，所以对于同时转换端口的NAT来说，ESP没法支持。
为了解决这个问题，必须在建立IPSec隧道的两个网关上同时开启NAT穿越功能（对应命令行nat traversal）。开启NAT穿越功能后，当需要穿越NAT设备时，ESP报文会被封装在一个UDP头中，源和目的端口号均是4500。有了这个UDP头就可以正常进行转换。
根据NAT设备所处的位置和地址转换功能的不同，我们从下面三个场景来分别介绍：
场景一：NAT转换后的分舵公网地址未知，总舵使用模板方式
该场景中，NAT设备位于分舵网络之外，分舵网关B接口GE0/0/1的私网IP地址，经过NAT设备转换后变为公网IP地址。由于天地会无从获知经过NAT设备转换后的分舵公网IP地址，也就无法在总舵网关A上明确指定对端分舵的公网地址。因此，总舵网关A必须使用模板方式来配置IPSec，同时总舵和分舵的网关上都要开启NAT穿越功能。
总舵既然使用了模板方式，那就无法主动访问分舵，只能由分舵主动向总舵发起访问。
总舵和分舵网关的关键配置如下：
|
关键配置 |
总舵 |
分舵 |
|
IPSec安全提议 |
ipsec proposal pro1 transform esp //采用ESP协议传输报文 |
ipsec proposal pro1 transform esp //采用ESP协议传输报文 |
|
IKE对等体 |
ike peer fenduo pre-shared-key tiandihui1 ike-proposal 10 nat traversal //双方同时开启，默认为开启 |
ike peer zongduo pre-shared-key tiandihui1 ike-proposal 10 remote-address 1.1.1.1 nat traversal //双方同时开启，默认为开启 |
|
IPSec安全策略 |
ipsec policy-template tem1 1 //配置模板方式 security acl 3000 proposal pro1 ike-peer fenduo ipsec policy policy1 1 isakmp template tem1 |
ipsec policy policy1 1 isakmp security acl 3000 proposal pro1 ike-peer zongduo |
场景二：NAT转换后的分舵公网地址可知，总舵使用模板方式或IKE方式
该场景中，NAT设备位于分舵网络之内，分舵网关B接口GE0/0/1的私网IP地址，经过NAT设备转换后变为公网IP地址。由于NAT设备在分舵控制范围之内，转换后的公网地址可知，所以总舵网关A上可以使用模板方式也可以使用IKE方式来配置IPSec。
需要注意的是，即便使用IKE方式，总舵也无法主动与分舵建立IPSec隧道。这不是IPSec的问题，而是NAT设备的问题。NAT设备只提供了源地址转换，实现分舵--->总舵这一方向的访问，分舵“隐藏”在NAT设备之后，无法实现总舵--->分舵方向的访问。如果要实现总舵主动访问分舵网关B的私网地址，则需要在NAT设备上配置NAT Server功能，我们会在场景三中详细介绍。
总舵和分舵网关的关键配置如下：
|
关键配置 |
总舵 |
分舵 |
|
IPSec安全提议 |
ipsec proposal pro1 transform esp //采用ESP协议传输报文 |
ipsec proposal pro1 transform esp //采用ESP协议传输报文 |
|
IKE对等体 |
ike peer fenduo pre-shared-key tiandihui1 ike-proposal 10 nat traversal //双方同时开启，默认为开启 remote-address 2.2.2.10 //对端地址为NAT后的地址。采用IKE方式时由于对端地址为单个地址，所以要求NAT设备的地址池中只有一个地址。模板方式时无此要求。 remote-address authentication-address 172.16.0.1 //认证地址为NAT前的地址 |
ike peer zongduo pre-shared-key tiandihui1 ike-proposal 10 remote-address 1.1.1.1 nat traversal //双方同时开启，默认为开启 |
|
IPSec安全策略 |
ipsec policy policy1 isakmp security acl 3000 proposal pro1 ike-peer fenduo |
ipsec policy policy1 1 isakmp security acl 3000 proposal pro1 ike-peer zongduo |
场景三：NAT设备提供NAT Server功能，总舵使用IKE方式主动访问分舵
该场景中，NAT设备位于分舵网络之内，提供NAT Server功能，对外发布的地址是2.2.2.20，映射成私网地址是分舵网关B接口GE0/0/1的地址172.16.0.1。总舵网关A上使用IKE方式来配置IPSec，即可实现总舵--->分舵方向的访问。在NAT设备上配置NAT Server，将2.2.2.20的UDP 500端口和4500端口分别映射到172.16.0.1的UDP 500端口和4500端口，具体配置如下：
nat server protocol udp global 2.2.2.20 500 inside 172.16.0.1 500
nat server protocol udp global 2.2.2.20 4500 inside 172.16.0.1 4500
同时，由于NAT设备上配置NAT Server时会生成反向Server-map表，所以分舵的网关B也可以主动向总舵发起访问。报文到达NAT设备后，匹配反向Server-map表，源地址转换为2.2.2.20，即可实现分舵--->总舵方向的访问。
总舵和分舵网关的关键配置如下：
|
关键配置 |
总舵 |
分舵 |
|
IPSec安全提议 |
ipsec proposal pro1 transform esp |
ipsec proposal pro1 transform esp |
|
IKE对等体 |
ike peer fenduo pre-shared-key tiandihui1 ike-proposal 10 nat traversal //双方同时开启，默认为开启 remote-address 2.2.2.20 //对端地址为NAT后的地址 remote-address authentication-address 172.16.0.1 //认证地址为NAT前的地址 |
ike peer zongduo pre-shared-key tiandihui1 ike-proposal 10 remote-address 1.1.1.1 nat traversal //双方同时开启，默认为开启 |
|
IPSec安全策略 |
ipsec policy policy1 isakmp security acl 3000 proposal pro1 ike-peer fenduo |
ipsec policy policy1 1 isakmp security acl 3000 proposal pro1 ike-peer zongduo |
下面以第二种场景为例，分别介绍一下采用IKEv1和IKEv2时是如何进行NAT穿越。
- IKEv1协商NAT穿越大揭秘
1. 开启NAT穿越时，IKEv1协商第一阶段的前两个消息会发送标识NAT穿越（NAT Traversal，简称NAT-T）能力的Vendor ID载荷（主模式和野蛮模式都是）。用于检查通信双方是否支持NAT-T。
当双方都在各自的消息中包含了该载荷时，才会进行相关的NAT-T协商。
2. 主模式消息3和消息4（野蛮模式消息2和消息3）中发送NAT-D（NAT Discovery）载荷。NAT-D载荷用于探测两个要建立IPSec隧道的网关之间是否存在NAT网关以及NAT网关的位置。
通过协商双方向对端发送源和目的的IP地址与端口的Hash值，就可以检测到地址和端口在传输过程中是否发生变化。若果协商双方计算出来的Hash值与它收到的Hash值一样，则表示它们之间没有NAT。否则，则说明传输过程中对IP或端口进行了NAT转换。
第一个NAT-D载荷为对端IP和端口的Hash值，第二个NAT-D载荷为本端IP和端口的Hash值。
3. 发现NAT网关后，后续ISAKMP消息（主模式从消息5、野蛮模式从消息3开始）的端口号转换为4500。ISAKMP报文标识了“Non-ESP Marker”。
4. 在第二阶段会启用NAT穿越协商。在IKE中增加了两种IPSec报文封装模式：UDP封装隧道模式报文（UDP-Encapsulated-Tunnel）和UDP封装传输模式报文（UDP-Encapsulated-Transport）。通过为ESP报文封装UDP头，当封装后的报文通过NAT设备时，NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换。UDP报文端口号修改为4500。
- IKEv2协商NAT穿越大揭秘
1. 开启NAT穿越后，IKE的发起者和响应者都在IKE_SA_INIT消息对中包含类型为NAT_DETECTION_SOURCE_IP和NAT_DETECTION_DESTINATION_IP的通知载荷。这两个通知载荷用于检测在将要建立IPSec隧道的两个网关之间是否存在NAT，哪个网关位于NAT之后。如果接收到的NAT_DETECTION_SOURCE通知载荷没有匹配数据包IP头中的源IP和端口的Hash值，则说明对端位于NAT网关后面。如果接收到的NAT_DETECTION_DESTINATION_IP通知载荷没有匹配数据包IP头中的目的IP和端口的Hash值，则意味着本端位于NAT网关之后。
2. 检测到NAT网关后，从IKE_AUTH消息对开始ISAKMP报文端口号改为4500。报文标识“Non-ESP Marker”。
IKEv2中也使用UDP封装ESP报文，当封装后的报文通过NAT设备时，NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换。UDP报文端口号修改为4500。
在第二种场景中，配置完成后PC1可以ping通PC2。在总舵网关A上查看IKE SA和IPSec SA的建立情况：
<FW_A> display ike sa
current ike sa number: 2
---------------------------------------------------------------------
conn-id peer flag phase v*n
---------------------------------------------------------------------
40014 2.2.2.10:264 RD v1:2 public
40011 2.2.2.10:264 RD v1:1 public
在总舵网关A上查看会话：
<FW_A> display firewall session table
Current Total Sessions : 2
udp v*n:public --> public 2.2.2.10:2050-->1.1.1.1:4500
udp v*n:public --> public 2.2.2.10:2054-->1.1.1.1:500
在分舵网关B上查看会话：
<FW_B> display firewall session table
Current Total Sessions : 2
udp v*n:public --> public 172.16.0.1:4500-->1.1.1.1:4500
udp v*n:public --> public 172.16.0.1:500-->1.1.1.1:500 //刚开始协商时端口号还是500
因为中间NAT设备上配置了源NAT转换，所以分舵网关B上只有分舵到总舵方向的会话，没有总舵到分舵方向的会话。
IPSec与NAT同处一墙，不同流量泾渭分明
前面讲了IPSec穿越NAT的情况，当IPSec和NAT同时配置在一台防火墙上时，由于两者处理的流量不同，只要保证两种流量互不干扰，便可相安无事。如下图所示，分舵网关B上同时配置了IPSec和NAT，IPSec用于保护分舵跟总舵通信的流量，NAT处理的是分舵访问Internet的流量。
按理说两种流量应该是泾渭分明，互不相干。其实不然，在防火墙处理流程中，NAT在上游，IPSec在下游，所以IPSec流量难免会受到NAT的干扰。IPSec流量一旦命中NAT策略就会进行NAT转换，转换后的流量不会匹配IPSec中的ACL，也就不会进行IPSec处理。
注：强叔后续会推出防火墙处理流程的介绍，敬请期待。
解决这个问题的方法就是在NAT策略中配置一条针对IPSec流量不进行地址转换的策略，该策略的优先级要高于其他的策略，并且该策略中定义的流量范围是其他策略的子集。这样的话，IPSec流量会先命中不进行NAT转换的策略，地址不会被转换，也就不会影响下面IPSec环节的处理，而需要进行NAT处理的流量也可以命中其他策略正常转换。
NAT策略的配置如下：
nat-policy interzone trust untrust outbound
policy 0 //需要IPSec保护的流量不进行NAT转换
action no-nat
policy source 172.16.1.0 mask 24
policy destination 192.168.0.0 mask 24
policy 5 //访问Internet的流量进行NAT转换
action source-nat
policy source 172.16.1.0 mask 24
address-group 1
若分舵网关B上还配置了NAT Server，配置NAT Server时生成的反向Server-map表也干扰IPSec流量。分舵中的服务器访问总舵时，流量会命中反向Server-map表，然后进行地址转换，转换后的流量不会匹配IPSec中的ACL，也就不会进行IPSec处理。此时就需要在配置NAT Server时指定no-reverse参数，不生成反向Server-map表，关于此问题的具体说明请参见“NAT
Server 三十二字真言（上篇）”。
前面的讲解中，总舵和分舵进行身份认证时采用的都是预共享认证方式。预共享**还是需要手工配置的，跟总舵对接的分舵数量少的时候没有问题，当分舵数量多的时候，为每个分舵跟总舵规划和配置预共享**的工作量还是不小的。对于这种情况，采用证书认证就非常合适。