两台Nokia IP防火墙做成cluster，平时两台防火墙都会处理流量，所以在重启的时候需要注意重启的设备是否还有流量在处理。如果其正在处理流量而重启，这样就会导致这部分流量的session中断。所以需要先将此防火墙处理的流量移交给cluster的其他member，接着停止其checkpoint的服务，然后重启。

1，将其处理的流量移交：可以通过其退出cluster来达到此目的。在Nokia的voyager配置cluster的界面里面可以查看到都是哪些端口被监控了，可以将其中的某一个端口（内外网口）down掉，其就会退出cluster。这时可以通过查看cluster的监控来看出其是否退出了cluster。

2，停止此防火墙的checkpoint服务：通过ssh或者telnet登陆防火墙的控制台，输入cpstop回车就可以停止此服务。

3，重启防火墙：通过ssh或者telnet登陆防火墙的控制台，输入reboot回车重启。

4，重启完成后，防火墙自动打开checkpoint服务。然后将第一步down掉的端口up起来，就能自动加入cluster。

前几天我公司与一家银行建立IPsecVPN，双方使用的都是Nokia的CP。在所有配置相同的情况下，通过如下测试确认双方的隧道已经建立起来：

我方先主动测试对方业务，通讯OK；然后由对方测试我方业务，也OK。

可是第二天过来对方反映隧道建立不起来了。

然后我从我方进行业务测试，发现隧道可以建立，我让对方再测试一下，此时对方也OK了。这就说明当隧道清除后，只有我方主动建立隧道，双方的通讯才OK。否则如果由对方先主动建立隧道，则隧道建立不起来。

研究了很久，发现对方有一处配置有问题：

对方在Network Objects/Check Point里的本地对象中主IP是内网ip，而不是公网ip（假如为A）。但是在此对象中的VPN/Link Selection却选择了Main address。这就表明此对象的VPN的link是Main address（也即那个内网ip：A），而没有与我方进行通信的那个公网ip。这样当然不能主动建立隧道。

需要如此修改：点选此对象的VPN/Link Selection中的Selected address from topology，然后选择那个公网ip即可。

Nokia&CP建立IPsecVPN有很多奇妙的地方，所以需要一点一滴的积累。

1，场景分析：

某公司A内部有一台主机a需要通过VPN访问公司B的一主机b的FTP服务，同时这台主机a还需要通过此防火墙访问外网。但是双方都不能爆楼自己的内网地址，也就是说主机a需要在流出本地端后经过NAT成另外一个地址到公司B与主机b通讯。这就涉及到了需要在CheckPoint上建立VPN，NAT（非host的nat）以及不同策略等。下面假设拓扑图如下：

例如：Host1到host4的数据流应该是192.168.11.1到192.168.111.1的，但是需要在checkpoint上面做好nat和vpn的访问策略，所以在192.168.11.1访问192.168.112.1（对端会将192.168.111.1经过nat到192.168.112.1）在CP上会将源地址经过NAT成192.168.12.1然后经过vpn加密的策略路由到192.168.112.1，到达对方后先进行VPN的解密然后将目的地址NAT成192.168.111.1。

2，NAT策略安装

NAT策略安装如下图：

策略1表示192.168.11.1访问192.168.112.1的数据模型；

策略2表示192.168.112.1返回到192.168.12.1的数据模型；

策略3就是192.168.11.0/24访问其他网段的需要将源地址NAT成1.1.1.0/29网段的模型。

3，VPN配置

这里需要注意的就是VPN_Domain。本地端VPN_Domain_loc包含192.168.11.1-3和192.168.12.1-3。而对端VPN_Domain_rem包含192.168.112.1-3。VPN的其他参数请参考“CheckPoint 建立NATed的VPN实现方法一”。

4，访问策略部署

访问策略应该为源地址为192.168.11.1-3，目的为192.168.112.1-3的80服务，经过上面的VPN加密。而返回的数据则是源地址为192.168.112.1-3到192.168.11.1-3经过上面的VPN解密。策略的其他部署信息请参考“CheckPoint 建立NATed的VPN实现方法一”。

5，日志检测

Host访问其他internet网络的日志信息如下：

从此日志很明显可以看出访问internet的网络经过NAT“XlateSrc”，匹配策略14。

而host1访问对方host4的日志如下：

同样可以明显看出经过来NAT“XlateDst”，匹配了策略13和NAT策略2。

需要注意的是后面的几个图不是此场景分析中的图例，只是那这些做一个示例而已。

今天突然接到VPN对方说测试数据过不来了，于是登录到CP上，查看日志，确实他们那边过来的数据报都drop了，日志信息显示：Wrong peer gateway for decrypted packet (VPN Error code 01)。
根据Wrong peer gateway进行Google，查的的结果为：可能是vpn domain引起的，查了许久没有找到原因。于是我查看日志看到刚好从2008-3-10 17:44开始出现丢包，这个时间好像我刚好在此CP上面新建了一个vpn的domain为net_48_28(48/255.255.255.240)的domain，然而匹配此vpn的目的地为net_48_31(48/255.255.255.254)。这样新建的vpndomain中48为网络号，而后面的策略的目的地又为48，所以导致报这个错误Wrong peer gateway。删除这个net_48_28然后重新install这个vpn的rule就好了。

知识总结：Nokia&CP建立VPN隧道需要确定VPN Domain，即给需要加密传输的源或者目的地址分别规整到一个地址域内，可以是一个网段或几个地址的集合（集合成group）。当VPN Domain为一个网段时候，其网络地址号和广播号不能用作主机地址来做数据传输（上次分析的可能有错误了，下次做实验证明之）。

追加之：今天做vpn同样遇到了报Wrong peer gateway for decrypted packet (VPN Error code 01)这个错误。经过仔细推敲分析，应该得出结论如下：
各个spokes的vpn domain不能一致。

故障查找经验总结：
1，先想办法恢复故障；
2，查看故障显示日志；
3，查找故障开始发生时刻点，并想此时是否做过相关变更；
4，根据经验排查。

1， 需求：

SiteA与SiteB之间需要通过CP建立VPN，但是双方都不能暴露自己的内网地址给对方，双方协商约定VPN建立的相关参数如下：

SiteA公网ip：1.1.1.1   
SiteA服务地址为192.168.111.111:80 感兴趣流量
SiteB公网ip：2.2.2.2
SiteB服务地址为192.168.112.111:80 感兴趣流量

Pre-Shared key : 123456
Phase1：
Perform key exchange : 3des                        
Perform date : md5                                 
Use DH : group 2                                   
Renegotiate IKE time : 3600 minutes                
Phase2:                                            
Perform ipsec date : 3des                          
Perform date : md5                                 
Use perfect forward secret                         
Use DH : group 2                                   
Renegotiate IKE time : 36000 seconds 

2， Site-to-site VPN建立视图参考

根据上面的参数可以得出双方必须把本地的真实服务器经过NAT后通过VPN隧道与对方进行交互。下面针对SiteA方进行详细过程介绍。

2.1，首先建立VPN DOMAIN

VPN DOMAIN解释：CP建立VPN时必须先将需要经过VPN的IP地址段通过VPN DOMAIN的形式告知CP，包括源和目的网段。假定此方案中针对SiteA方源为192.168.111.0/24网段，目的为192.168.112.0/24网段。如图：

确定即可，同理建立VPN_DOMAIN_REM 192.168.112.0 255.255.255.0的VPN DOMAIN。

2.2，建立本地CP的GateWay

本地CP GW依照防火墙的是否为cluster等来建立，本例依照cluster来建立，如图：

Topology结构如果是本地GW可以通过Get获取，如果是对段的GW则需要手工建立（或者不建立也可以）。然后手工选定VPN DOMAIN，其它保持默认即可。

2.3，建立对端GW

如果对段也是CP，就按照2.2所述进行配置即可。这里要讲的是其他设备的GW建立。首先需要明确的是默认情况下CP的左边可能没有Interoperable Device这一项，所以需要添加这一项，如图：

Topology结构需要手工建立，或者不建立。VPN DOMAIN手工指定，其它保持默认即可。

2.4，建立site-to-site VPN

我们这里例举site-to-site VPN的建立过程，如图：

点击进去后，在General输入名称即可，在Center Gateways选刚建立的Local_GW，Satellite Gateways选择SiteB_GW，VPN Properties如图：

其它选项都保持默认，即可。

到这里为止，site-to-site的VPN已经建立好，但是还没有做匹配策略。

3， 匹配策略建立

3.1，建立Notes

建立Notes，配置NAT选项，如图：

其中10.1.1.1为真实主机。

注意：这样NAT后的该主机路由到防火墙后都会先进行NAT然后匹配策略，不管是否为VPN的策略。即假如此主机通过防火墙还有其他应用（不需要进行NAT的策略）要做，则不能这样做NATed的VPN，不过貌似好像也没有其他办法来实现NATed的VPN。需要指明的是这个NAT与旁边的Security策略是独立的，即假如在这上面做了NAT后不会再去匹配Security策略了。同样建立对端的Notes。

3.2，建立匹配策略

需要注意的是，这里源和目的地址要包括数据流的两个方向，然后加上log好针对日志进行排障。

3.3，Install 此策略即可：

3.4，打开日志，进行检测：

到此为止，经过NAT的VPN已经建立好，然后就是通讯测试过程了。

阐述的比较肤浅，没怎么讲原理性的东西。也许会有不正确的地方，仅供参考，同时更希望参阅者能提出宝贵意见。多谢了。