取消
显示结果 
搜索替代 
您的意思是: 
cancel
公告

December 2020

December 2020

2221
查看次数
0
有帮助
17
回复
linwei22403
Beginner

ASA 和飞塔防火墙ipsecVPN 单方向通

通道显示up ,只是ASA到飞塔的网络通,而飞塔到ASA不通,不知道为什么
ASA 可以敲什么命令 来验证哪里出问题了呢
1 个已接受解答

已接受的解答
l_enough
Beginner

飞塔处就飞塔看;
diagnose debug flow filter addr 10.10.10.100
diagnose debug flow filter proto 1
diagnose debug flow show console enable
diagnose debug flow show function-name enable
diagnose debug flow trace start 4
diagnose debug enable
完事记得
diagnose debug disable

在原帖中查看解决方案

17 条回复17
l_enough
Beginner

飞塔处就飞塔看;
diagnose debug flow filter addr 10.10.10.100
diagnose debug flow filter proto 1
diagnose debug flow show console enable
diagnose debug flow show function-name enable
diagnose debug flow trace start 4
diagnose debug enable
完事记得
diagnose debug disable

在原帖中查看解决方案

YilinChen
Advocate

本帖最后由 YilinChen 于 2021-3-1 19:03 编辑
这要看具体配置了,是传统的IPSECVPN,还是基于TUNNEL的,Forti可能叫RouteBase IPSEVPN。
Forti主动发起不通,优先查一下安全策略;
我能告诉楼主的是,肯定是能对接成功的。:)
limerez01
Beginner

飞塔过去的感兴趣流、nat排除等等检查一下呢
wyc_chao
Beginner

看看访问列表,查一下感兴趣的流量,还有路由
linwei22403
Beginner

l_enough1 发表于 2021-3-2 11:54
飞塔处就飞塔看;
diagnose debug flow filter addr 10.10.10.100
diagnose debug flow filter proto 1

飞塔发起不通,发现路由没走,vpn,走的默认路由去上层了,到了上层又走了缺省路由出路由器了。
linwei22403
Beginner

YilinChen 发表于 2021-3-1 19:01
这要看具体配置了,是传统的IPSECVPN,还是基于TUNNEL的,Forti可能叫RouteBase IPSEVPN。
Forti主动发起 ...

ipsec 目前单向通。 目前怀疑和路由有关,因为不通,tracert 发现 走的默认路由,上升到路由器了,而不是从防火墙接口走vpn通道
linwei22403
Beginner

limerez01 发表于 2021-3-1 19:47
飞塔过去的感兴趣流、nat排除等等检查一下呢

不涉及 nat
linwei22403
Beginner

思科端vlan是172.22.40.0
飞塔端是10.66.8.0
思科端到飞塔端通
C3750G_A21_CEN#ping 10.66.8.11 source 172.22.40.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.66.8.11, timeout is 2 seconds:
Packet sent with a source address of 172.22.40.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms
C3750G_A21_CEN_A_Internet2_CU100_Core_3.67#
现在飞塔端到思科端单向不通,抓包数据如下,发现没有reply
filters=[host 172.22.40.1 and icmp]
299.054980 x2 in 10.66.8.11 -> 172.22.40.1: icmp: echo request
299.054990 x1 out 10.66.8.11 -> 172.22.40.1: icmp: echo request
301.050939 x2 in 10.66.8.11 -> 172.22.40.1: icmp: echo request
301.050946 x1 out 10.66.8.11 -> 172.22.40.1: icmp: echo request
linwei22403
Beginner

飞塔端下连交换机路由
ip route 172.22.40.0/24 10.66.0.33
飞塔路由
linwei22403
Beginner

飞塔路由如下图,及架构图如下
linwei22403
Beginner

299.054980 x2 in 10.66.8.11 -> 172.22.40.1: icmp: echo request
299.054990 x1 out 10.66.8.11 -> 172.22.40.1: icmp: echo request
301.050939 x2 in 10.66.8.11 -> 172.22.40.1: icmp: echo request
301.050946 x1 out 10.66.8.11 -> 172.22.40.1: icmp: echo request
417.871726 x1 in 172.22.40.1 -> 10.66.8.11: icmp: echo request
417.871738 x2 out 172.22.40.1 -> 10.66.8.11: icmp: echo request
417.879275 x2 in 10.66.8.11 -> 172.22.40.1: icmp: echo reply
417.883844 x1 in 172.22.40.1 -> 10.66.8.11: icmp: echo request
417.883854 x2 out 172.22.40.1 -> 10.66.8.11: icmp: echo request
417.886381 x2 in 10.66.8.11 -> 172.22.40.1: icmp: echo reply
linwei22403
Beginner

为什么思科端172.22.40ping 10.66.8.11 就能有reply。反过来只有request没有reply呢
linwei22403
Beginner

4.Center设备没有配置回程去往分部网段的路由指向center-tunnel接口 (sniffer有请求报文的IN,无OUT)
5.Center内网核心交换机没有配置去往分部网段的回程路由 (sniffer有请求的IN和OUT,但没有回复的IN)
现在思科端通的那个方向抓包 匹配的是5的情况,
飞塔端通的那个方向抓包 匹配的是4的情况,
如何解读这个回程路由呢
linwei22403
Beginner

问题锁定在飞塔到飞塔下连的交换机问题,将10.66.8直连设定在飞塔上就没问题,双向互通
Content for Community-Ad


不能显示该小部件。