USG5500和USG2200配置GRE VPN业务段不通

发布时间:  2014-11-23 浏览次数:  490 下载次数:  0
问题描述
总部USG5500和分中心USG2200通过公网固定IP互通,两端配置GRE VPN,要实现业务网段总部192.168.0.x,分中心192.168.3.x互通,总部和分中心的业务段网关都分别在防火墙上。现在客户的GRE VPN两端内网互ping不通。
处理过程
客户配置:
ip address-set zzx type group
address 0 address-set zongzhongxin
#
ip address-set fzx type group
address 0 address-set fenzhongxin
#
ip address-set fenzhongxin type object
address 0 192.168.3.0 mask 255.255.255.0
#
ip address-set zongzhongxin type object
address 0 192.168.0.0 mask 255.255.255.0

nat-policy interzone trust untrust outbound
policy 0
  action source-nat
  address-group ip
policy 1
  action no-nat
  policy source address-set fzx
  policy destination address-set zzx

处理思路:

首先请客户检查网络是否是通的,USG5500去ping运营商网关能否ping通 ,能通;ping对端的公网ip,能通;说明公网网段是通的。
usg5500内网的pc去ping本端的tunnel口,能通;ping对端的公网口,不通;ping对端的tunnel口,也不通。
以上两点可知,公网可通;本端内网到本端tunnel是通的,本端tunnel口到对端就不通了。问题应该就出在tunnel口到公网口之间。检查客户的配置。
4.     发现客户做域间的nat-policy的时候,本该不做nat转换的vpn私网报文却被优先的policy 0做了到公网的nat,丢给了公网,而没有走vpn的私网通道。而且,客户匹配的源/目的地址段policy source/destination address-set xxx的地址集的名称也和ip address-set xxx的名称不匹配,导致匹配不上。
根因
做域间的nat-policy的时候,本该不做nat转换的vpn私网报文却被优先的policy 0做了到公网的nat,丢给了公网,而没有走vpn的私网通道。而且,客户匹配的源/目的地址段policy source/destination address-set xxx的地址集的名称也和ip address-set xxx的名称不匹配,导致匹配不上。
客户的GRE配置有问题,是私网到对端的私网,客户把GRE隧道放在了普通的nat之后,到对端的包先被做了nat,地址变成了公网ip,不行的。让客户把需要走GRE的段放到nat-policy的第一位,并且no-nat,保持用私网ip走GRE隧道经tunnel口互通,而不是nat成公网互通。

解决方案
更改policy source/destination address-set xxx的地址集的名称和ip address-set xxx的名称的匹配关系,nat转换的时候,vpn私网报问的no nat 的policy 1放到policy 0 之前进行优先匹配,才能保证vpn数据不被nat 到公网。
建议与总结
做VPN对接常用处理思路:
1.网路是否正常可通,路由是否可达;
2.看域间包策略是否放开,是否有acl误配置了网段的限制,或者acl配置的范围/掩码太大;
3.查看Tunnel接口的工作状态:display  interface  tunnel  xxx
    Tunnel接口状态是否为Up,Tunnel接口是否之间可以Ping通;
4. 查看路由表:display ip routing-table 看使用Tunnel接口去往对端用户侧网段的静态路由;
5. 查看隧道两端是否能互通:ping   -a  source-ip-address   dest-ip-address;
6. 使用display  firewall  session  table   verbose  看是否有会话信息;
7.检查NAT的策略,看是否需要配置no-nat;需要互通的网段地址集是否配置正确;
4.最后可以抓包分析。

END