USG2200与USG2100建立IPSEC隧道后,内网一个IP地址无法与远端网段通信
2014/11/10 13:50:44点击:
问题描述
USG2200与USG2100对接IPSEC VPN已经成功,USG2200下连192.168.13.0/24网段与USG2100下连192.168.103.0/24网段已经可以互访,但是USG2200下连IP为192.168.13.11的PC无法访问远端的设备,远端设备主动访问192.168.13.11可以成功访问
处理过程
处理过程
使用192.168.13.11 ping USG2100接口IP 192.168.103.1,在USG2200上查看会话表信息如下:
[USG2200]display firewall session table verbose source inside 192.168.13.11
Current Total Sessions : 1
icmp VPN:public --> public
Zone: trust--> untrust TTL: 00:00:20 Left: 00:00:18
Interface: GigabitEthernet0/0/0 NextHop: 192.168.103.1 MAC: 00-00-00-00-00-00
<--packets:0 bytes:0 -->packets:1 bytes:60
192.168.13.11:43827[58.56.90.30:43827]-->192.168.103.1:2048
源IP地址出网时被转换成了公网口IP,检查nat配置发现域间nat配置没有问题
nat-policy interzone trust untrust outbound
policy 2
action no-nat
policy source 192.168.13.0 mask 24
policy source 192.168.12.0 mask 24
policy destination 192.168.100.0 mask 24
policy destination 192.168.101.0 mask 24
policy destination 192.168.102.0 mask 24
policy destination 192.168.103.0 mask 24
policy 1
action source-nat
policy source 192.168.10.0 mask 24
policy source 192.168.12.0 mask 24
policy source 192.168.13.0 mask 24
policy source 192.168.1.0 mask 24
easy-ip GigabitEthernet0/0/0
但是客户在设备上配置了一条nat server命令
nat server 11 protocol tcp global 58.56.90.30 3389 inside 192.168.13.11 3389
导致192.168.13.11去访问远端IP时,匹配反向server-map表,直接将源IP地址转换成58.56.90.30
修改nat server命令后问题解决
[USG2200]display firewall session table verbose source inside 192.168.13.11
Current Total Sessions : 1
icmp VPN:public --> public
Zone: trust--> untrust TTL: 00:00:20 Left: 00:00:18
Interface: GigabitEthernet0/0/0 NextHop: 192.168.103.1 MAC: 00-00-00-00-00-00
<--packets:0 bytes:0 -->packets:1 bytes:60
192.168.13.11:43827[58.56.90.30:43827]-->192.168.103.1:2048
源IP地址出网时被转换成了公网口IP,检查nat配置发现域间nat配置没有问题
nat-policy interzone trust untrust outbound
policy 2
action no-nat
policy source 192.168.13.0 mask 24
policy source 192.168.12.0 mask 24
policy destination 192.168.100.0 mask 24
policy destination 192.168.101.0 mask 24
policy destination 192.168.102.0 mask 24
policy destination 192.168.103.0 mask 24
policy 1
action source-nat
policy source 192.168.10.0 mask 24
policy source 192.168.12.0 mask 24
policy source 192.168.13.0 mask 24
policy source 192.168.1.0 mask 24
easy-ip GigabitEthernet0/0/0
但是客户在设备上配置了一条nat server命令
nat server 11 protocol tcp global 58.56.90.30 3389 inside 192.168.13.11 3389
导致192.168.13.11去访问远端IP时,匹配反向server-map表,直接将源IP地址转换成58.56.90.30
修改nat server命令后问题解决
根因
nat server后面没有配置no-reverse参数,就表示正反向server map都创建,且server map的优先级高于域间的NAT策略,因此该内网IP报文经过域间的是时候会命中反向server map表
解决方案
修改nat server命令为不创建反向server-map表
修改配置如下:
nat server 11 protocol tcp global 58.56.90.30 3389 inside 192.168.13.11 3389 no-reverse
修改配置如下:
nat server 11 protocol tcp global 58.56.90.30 3389 inside 192.168.13.11 3389 no-reverse
建议与总结
IPSEC VPN建立成功后两边用户无法互访需要注意以下几点:
1.两边用户数据是否在感兴趣流里面(security acl)
2.域间策略是否放开,一般IPSEC VPN互访的数据是从外网区域进来的,需要放开外网区域到内网区域之间的域间策略
3.NAT配置问题,走IPSEC VPN的数据不需要做nat,但是nat处理过程是在将数据放入隧道之前,所以需要修改配置让走隧道的数据不做nat,除了域间nat,还需要关注nat server的反向server-map表,具体可以通过查看会话表来看数据是否被转换了
1.两边用户数据是否在感兴趣流里面(security acl)
2.域间策略是否放开,一般IPSEC VPN互访的数据是从外网区域进来的,需要放开外网区域到内网区域之间的域间策略
3.NAT配置问题,走IPSEC VPN的数据不需要做nat,但是nat处理过程是在将数据放入隧道之前,所以需要修改配置让走隧道的数据不做nat,除了域间nat,还需要关注nat server的反向server-map表,具体可以通过查看会话表来看数据是否被转换了
- 上一篇:S6700交换机堆叠配置后堆叠不成功 2014/11/10
- 下一篇:没有串口线时如何通过网线Telnet到AP? 2014/11/10