防火墙在部署IPSec时候，安全策略该如何放行？

从IKE/IPSec建立阶段分析

IPSec建立是分为两个阶段，第一个阶段是IKE来处理的，而IKE使用的是UDP，端口号是500，而IPSec第二个阶段则根据实际采用的协议来确定， 有AH与ESP，AH是IP协议号51、ESP是协议号50，实际环境都以ESP进行，那么这里就可以知道，至少要放行UDP的500，以及ESP协议，但是怎么放行，放行哪到哪的？

1、IPSec隧道建立是BJ_FW到CS_FW之间建立，那么就是防火墙自身发起或者接收报文，以图上为例，那需要放行Local与untrust双方的流量，源目地址为各自的公网地址，用到的UDP500与ESP。

2、实际业务流量的转发是在IPSec建立之后，由防火墙身后的网络发往对方，这个时候需要放行防火墙身后接口所在安全区域到出接口所在区域的流量放行，还要放行对方过来的流量，所以需要双向放行。（比如图上面需要放行trust与untrust之间两个业务网段之间的流量放行）

实验验证

关于IKE/IPSec的配置在32与33篇都有，而且拓扑用的是一样的，这里就不在重复介绍与配置了，这里分享一个经验，如果实际在不知道如何放行IPSec以及业务流量，在之前介绍过一个方法就是把策略临时改为全放，然后通过会话表信息就能够查到需要放行的。

触发IPSec建立，ping成功了，说明隧道已经建立成功，我们先用默认策略来看下需要放行什么样的流量。

可以通过display  firewall session table verbose来查看，这个一定要在触发建立的时候第一时间查看，不然有些会话会消失，这里在提一个经验，在工作中肯定是会话非常多，如果直接用这个命令会很多，找自己需要的会很麻烦，建议在后面加参数，比如source地址、destination地址以及端口号、协议号等来匹配，过滤自己需要的。

这个会话是从BJ_FW这边发起的，看到了三个会话信息，一个是192.168.10.1去往192.168.20.2的实际业务信息，这个方向是trust到untrust，第二个是触发了IPSec的建立，所以BJ_FW有一个Local_untrust 源地址是BJ_FW的公网地址（202.100.1.1源端口号是UDP500，）目的地址是CS_FW的公网地址（202.100.2.1，目的端口号UDP500），这个防火墙之间建立IPSec的第一阶段用到的IKE，端口号是源目UDP500。第三个是ESP协议，IPSec的第二阶段，但是在防火墙上面只显示了untrust_local的，并没有显示Local_untrust的，但是在安全策略是建议放行，整体看下来也验证了上面从IKE/IPSec分析的内容，这里来实际配置下。

default  action deny ：两边都改成默认deny，重新配置策略。

当策略全部配置完毕，在来测试发现了通了的。

IKE与IPSec的SA信息都有，可以发现策略都是双向做的，比如Local与untrust之间不仅仅写了出去的方向，也写了进入的方向，还有Trust到untrust的也是，这是因为在实际中，可能存在两边都会发起建立IPSec的可能性，如果不双向放行的话，可能对方发送过来建立IPSec报文会被丢弃导致隧道建立不起来的情况。

博主这里分享下经验

这里主要针对一些常见的策略放行一些建议，减轻配置量与出错率。

对于中小型环境安全策略要求不是特别严格的来说，local_untrust可以直接any，而untrust_local按需求放行。如果甲方要求按严格策略实施，就按实际情况进行放行。

对于Trust_untrust方向的策略来说，通常情况下是直接允许全部，不做限制，因为Trust_untrust会包含上网流量。

如果在实际中有拒绝某些网段上网的情况下，又需要放行IPSec的网段，一定要先允许互访业务网段，在拒绝上网流量，否则会出现访问业务网段不通的情况。

如果有策略路由以及NAT Server的情况下，主要排除掉双方IPSec业务网段的流量，否则有可能造成业务不通的情况。（这个实际案例会视频讲解）

防火墙在部署IPSec时候，有NAT上网策略会出现什么情况？

假设拓扑中有一个114.114.114.114属于公网信息，Client与Server需要访问114，这个时候在BJ_FW与CS_FW要部署NAPT才能够访问成功，当配置完后，看看会出现什么样的情况，这也是实际环境中必须要了解的事情，因为实际环境，防火墙既充当上外网的功能，又部署了IPSec。

reset ike sa

reset  ipse sa

先把两边的IKE与IPSec清空下。

BJ_FW

nat-policy

rule name internet

source-zone trust

destination-zone untrust

source-address 192.168.10.0 mask255.255.255.0

action source-nat easy-ip

CS_FW

nat-policy

rule name internet

source-zone trust

destination-zone untrust

source-address 192.168.20.0 mask255.255.255.0

action source-nat easy-ip

访问114测试下

Client与Server访问都没问题，下面来试试IPSec的互访。

可以发现不通了！！！，访问外网没问题，但是访问IPSec不通，来看看IPSec的状态。

查看后发现没有任何状态信息，来看看会话信息。

会话表里面发现了192.168.10.1访问192.168.20.2的时候被转换成202.100.1.1了，回想下IPSec触发建立的流程是，当一个会话抵达出接口后，由于接口配置了IPSec策略，会查询该会话信息是否匹配IPSec策略里面写的感兴趣流量（ACL）如果匹配则触发建立，显然这里由于192.168.10.1被转换了，自然就匹配不上ACL，所以数据包直接转发到公网去了，而公网路由器收到发现是去往192.168.20.2的私网地址直接丢弃。

这个时候就明白了IPSec查看的时候没有任何信息出现的原因，这是因为数据包没有匹配上触发的条件，那么是不是可以这样，不让192.168.10.0/24访问192.168.20.0/24网段的时候做NAPT转换呢？，以及192.168.20.0/24回包的时候也不转换。

BJ_FW

nat-policy

rule name internet

source-zone trust

destination-zone untrust

source-address 192.168.10.0 mask255.255.255.0

action source-nat easy-ip

rule name nopat

source-zone trust

destination-zone untrust

destination-address192.168.20.0 mask 255.255.255.0

action no-nat

CS_FW

nat-policy

rule name internet

source-zone trust

destination-zone untrust

source-address 192.168.20.0 mask255.255.255.0

action source-nat easy-ip

rule name nopat

source-zone trust

destination-zone untrust

destination-address192.168.10.0 mask 255.255.255.0

action no-nat

NAT策略里面各加了两个策略，都是名字为nopat，去往各自内网网段匹配，然后动作是no-pat，也就是不转换，这个时候应该行了吧，来在测试下。

还是失败。

还是发生了转换，说明做的NAT策略没生效，重点排查下NAT策略。

通过display nat-policy rule all，可以发现nopat的ID是2，而internet的ID是1，那nopat永远不会生效，因为NAT策略也是从上往下开始匹配的，匹配上了1，自然就不会在匹配2了，这个时候需要把顺序调整下。

nat-policy

rule move nopat top

两边都执行这个命令，让nopat的策略往上面提，这样就可以匹配上了。

顺序变了，继续测试下。

这个时候就通了。

IKE与IPSec也正常建立了SA信息。

总结

在正常组网中，防火墙充当外网出口设备，既要允许内网去上网，又部署了IPSec业务的时候，一定做一个nopat策略，就是当访问对方IPSec业务网段的时候，执行动作为nopat，也就是不转换，这样就能够让该数据匹配上IPSec策略里面的感兴趣流（ACL）从而触发IPSec的建立，一定要记得nopat的策略在最前面，这样能够保证数据包匹配上该策略，否则配置了不生效，IPSec也无法建立。

“承上启下”

IPSec在遇到防火墙的安全策略与NAT策略的问题解决了，但是在实际中多数处于这样的环境，比如总部人多拉了专线，其他分支可能就用的普通的拨号宽带那种，那么这个时候IPSec要如何配置跟建立呢？

以上就是防火墙在部署IPSec时候，安全策略该如何放行？的介绍，Vecloud除了IPSec组网外，还提供MPLS企业组网、SD-WAN网络专线、IPLC国际专线、IEPL海外专线等云专线业务。