数据包未在 VPN 的 ASA 端解封装

网络工程 思科 思科-ASA 虚拟专用网
2022-02-07 16:59:01

我有一个远程管理的 ASA。在该设备上，大约有 6 个 IPSec 隧道。

它们都按预期工作。最近我不得不为新办公室创建一个。我有这个问题。我无法弄清楚问题出在哪里。

ASA 不会解密从隧道远端到达的数据包。在我们的环境中，我们使用 Fortigate 和 Cisco 防火墙。我们拥有的大多数隧道都在这两个供应商之间，它们都可以工作，除了这个！

信息：多伦多 = Fortigate（192.168.185 网络）伦敦 = ASA 9.x（10.101.0.0 网络）

如果我从多伦多 ping 到伦敦，它将失败。如果我在通往伦敦的 VPN 接口上进行捕获，我会看到数据包正在流出。所以他们被派到隧道里。

如果我从伦敦 ping 到多伦多，它也会失败。但是，在多伦多，如果我在我正在 ping 的主机上进行捕获，我可以看到 ping：

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:48:47.938568 IP 10.101.0.199 > 192.168.185.120: ICMP echo request, id 51263, seq 36, length 64 17:48:47.938595 IP
192.168.185.120 > 10.101.0.199: ICMP echo reply, id 51263, seq 36, length 64

But on the London host we don't see these replies.


On the ASA it indicates that it is encrypting outbound packets but not inbound:

LON-NET-FW01(config)# show cry ipsec sa peer 2x.1x.2x.13x
peer address: 2x.1x.2x.13x
    Crypto map tag: crypto-outside, seq num: 5, local addr: 8x.1x.4x.9x

      access-list TUN-LONGS-TORQQ extended permit ip 10.101.0.0 255.255.255.0 192.168.185.0 255.255.255.0
      local ident (addr/mask/prot/port): (10.101.0.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.185.0/255.255.255.0/0/0)

      #pkts encaps: 1072, #pkts encrypt: 1072, #pkts digest: 1072
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 1072, #pkts comp failed: 0, #pkts decomp failed: 0

===snip===（两个网络都列出了，但这里只显示一个长度）

Some bits of the config:

object-group network DHX-QQ-NETWORKS
 network-object 10.180.0.0 255.255.252.0
 network-object 192.168.185.0 255.255.255.0


LON-NET-FW01(config)# show run nat | inc QQ
nat (inside,outside) source static LONGS-101NET LONGS-101NET destination static DHX-QQ-NETWORKS DHX-QQ-NETWORKS route-lookup

show nat:

10 (inside) to (outside) source static LONGS-101NET LONGS-101NET  destination static DHX-QQ-NETWORKS DHX-QQ-NETWORKS route-lookup
    translate_hits = 410, untranslate_hits = 410

run-access-list:

access-list TUN-LONGS-TORQQ remark Tunnel to TOR Service and Desktop networks
access-list TUN-LONGS-TORQQ extended permit ip object-group LONGS-101NET object-group DHX-QQ-NETWORKS

LON-NET-FW01(config)# show access-list TUN-LONGS-TORQQ
access-list TUN-LONGS-TORQQ; 2 elements; name hash: 0xfa13240a
access-list TUN-LONGS-TORQQ line 1 remark VPN to TOR SRV and Desktop networks
access-list TUN-LONGS-TORQQ line 2 extended permit ip object-group LONGS-101NET object-group DHX-QQ-NETWORKS (hitcnt=7) 0x8d68f010
  access-list TUN-LONGS-TORQQ line 2 extended permit ip 10.101.0.0 255.255.255.0 10.180.0.0 255.255.252.0 (hitcnt=3) 0x4a18a364
  access-list TUN-LONGS-TORQQ line 2 extended permit ip 10.101.0.0 255.255.255.0 192.168.185.0 255.255.255.0 (hitcnt=15) 0xd9e13e75




crytomap:
crypto map crypto-outside 5 match address TUN-LONGS-TORQQ
crypto map crypto-outside 5 set pfs
crypto map crypto-outside 5 set peer 2x.1x.2x.1x
crypto map crypto-outside 5 set ikev1 transform-set ESP-3DES-SHA
crypto map crypto-outside 5 set reverse-route


LON-NET-FW01(config)# show run tunnel-group 2x.1x.2x.1x
tunnel-group 2x.1x.2x.1x type ipsec-l2l
tunnel-group 2x.1x.2x.1x ipec-attributes
  ikev1 pre-shared-key *********



Routing table:

LON-NET-FW01(config)# show route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is 8x.1x.4x.8x to network 0.0.0.0

S*       0.0.0.0 0.0.0.0 [1/0] via 8x.1x.4x.8x, outside
D EX     10.3.0.0 255.255.0.0
           [170/25605376] via 172.16.101.2, 02:15:21, transit
S        10.3.2.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
S        10.10.10.0 255.255.255.0 [1/0] via 10.101.0.2, inside
C        10.45.16.0 255.255.255.0 is directly connected, lync_dmz
L        10.45.16.1 255.255.255.255 is directly connected, lync_dmz
C        10.101.0.0 255.255.255.0 is directly connected, inside
L        10.101.0.1 255.255.255.255 is directly connected, inside
S        10.112.0.0 255.240.0.0 [250/0] via 8x.1x.4x.8x, outside
D        10.112.0.0 255.255.255.0
           [90/25608448] via 172.16.101.2, 02:15:22, transit
D EX     10.113.0.0 255.255.255.0
           [170/25603072] via 172.16.101.2, 02:15:21, transit
D EX     10.114.0.0 255.255.255.0
           [170/25605376] via 172.16.101.2, 02:15:21, transit
D EX     10.115.0.0 255.255.255.0
           [170/25605376] via 172.16.101.2, 02:15:22, transit
D EX     10.116.0.0 255.255.255.0
           [170/25605376] via 172.16.101.2, 02:15:22, transit
D EX     10.117.0.0 255.255.255.0
           [170/25603072] via 172.16.101.2, 02:15:22, transit
S        10.118.0.0 255.255.0.0 [1/0] via 8x.1x.4x.8x, outside
S        10.118.0.0 255.255.255.0 [250/0] via 8x.1x.4x.8x, outside
S        10.180.0.0 255.255.252.0 [1/0] via 8x.1x.4x.8x, outside
S        10.230.4.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
S        10.255.255.1 255.255.255.255 [1/0] via 8x.1x.4x.8x, outside
C        85.133.42.88 255.255.255.248 is directly connected, outside
L        85.133.42.92 255.255.255.255 is directly connected, outside
S        172.16.5.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
D EX     172.16.11.0 255.255.255.0
           [170/25602816] via 172.16.101.2, 02:15:24, transit
D EX     172.16.12.0 255.255.255.0
           [170/25613056] via 172.16.101.2, 02:15:23, transit
D        172.16.21.0 255.255.255.0
           [90/25607936] via 172.16.101.2, 02:15:24, transit
C        172.16.101.0 255.255.255.128 is directly connected, transit
L        172.16.101.1 255.255.255.255 is directly connected, transit
C        172.16.101.128 255.255.255.128 is directly connected, dmz
L        172.16.101.129 255.255.255.255 is directly connected, dmz
D        172.16.112.0 255.255.255.128
           [90/25608192] via 172.16.101.2, 02:15:23, transit
S        172.16.118.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
D        172.19.101.1 255.255.255.255
           [90/130816] via 172.16.101.2, 02:15:24, transit
D        172.19.112.1 255.255.255.255
           [90/25735936] via 172.16.101.2, 02:15:23, transit
D EX     172.19.113.1 255.255.255.255
           [170/25730816] via 172.16.101.2, 02:15:22, transit
D EX     172.19.114.1 255.255.255.255
           [170/25730816] via 172.16.101.2, 02:15:22, transit
D EX     172.19.115.1 255.255.255.255
           [170/25730816] via 172.16.101.2, 02:15:22, transit
D EX     172.19.116.1 255.255.255.255
           [170/25730816] via 172.16.101.2, 02:15:22, transit
D EX     172.19.117.1 255.255.255.255
           [170/25730816] via 172.16.101.2, 02:15:22, transit
S        192.168.2.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
D EX     192.168.5.0 255.255.255.0
           [170/25603072] via 172.16.101.2, 02:15:22, transit
D EX     192.168.7.0 255.255.255.0
           [170/25605376] via 172.16.101.2, 02:15:22, transit
D EX     192.168.9.0 255.255.255.0
           [170/25605376] via 172.16.101.2, 02:15:22, transit
S        192.168.130.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
S        192.168.170.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
S        192.168.185.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside

I have configured 5 or 6 other tunnels on this device,  most to foritnet devices, and they all work as expected:


LON-NET-FW01(config)# show cry ipsec sa | inc access-list
      access-list TUN-LONQCS-LONGS extended permit ip 10.101.0.0 255.255.0.0 10.118.0.0 255.255.0.0
      access-list TUN-LONDON-LOSANGELES extended permit ip 10.101.0.0 255.255.255.0 172.16.5.0 255.255.255.0
      access-list TUN-LONDON-LOSANGELES-CoreNet extended permit ip 10.101.0.0 255.255.255.0 192.168.130.0 255.255.255.0
      access-list TUN-LONDON-VAN01 extended permit ip 10.101.0.0 255.255.255.0 192.168.170.0 255.255.255.0
      access-list TUN-LONGS-TORQQ extended permit ip 10.101.0.0 255.255.255.0 192.168.185.0 255.255.255.0
      access-list TUN-LONGS-TORQQ extended permit ip 10.101.0.0 255.255.255.0 10.180.0.0 255.255.252.0
      access-list TUN-LONGS-LON extended permit ip 10.101.0.0 255.255.0.0 10.112.0.0 255.255.0.0
2个回答

我会说隧道的伦敦一侧很好，因为它正在加密数据包。但是，可以将 ASA 设置为不绕过 VPN 流量的接口 ACL。no sysopt connection permit-vpn如果在运行配置中指定，您将知道这一点。您可以通过否定此命令或允许 vpn 流量通过外部接口上的入站 ACL 来解决此问题。

由于防火墙是不同的供应商，这使事情变得更加复杂。我怀疑来自 Fortigate 的发往伦敦的流量正在被 NAT 到外部接口，或者第 2 阶段 ACL 在站点之间不匹配 100%。如果您在第 2 阶段 ipsec sa 上收到 recv 错误，那么可能就是这种情况。

我对 Fortigates 没有太多经验，但我做了一些研究，你的政策应该是这样的。

config vpn ipsec phase1

edit “asa”
        set interface "?"
        set ?
        set proposal ?
        set remote-gw x.x.x.x
        set psksecret ENC *******
    next
config vpn ipsec phase2
    edit “asa 191.168.185.0/24"
        set phase1name “asa”
        set proposal 3des-md5
        set dhgrp 2
        set dst-subnet 10.101.0.0 255.255.255.0
        set keylifeseconds ?
        set src-subnet 192.168.185.0 255.255.255.0
    next
    edit “asa 10.180.0.0/24"
        set phase1name “asa”
        set proposal 3des-md5
        set dhgrp 2
        set dst-subnet 10.101.0.0 255.255.255.0
        set keylifeseconds ?
        set src-subnet 10.180.0.0 255.255.255.0

在隧道的防火墙策略中，确保set natoutbound enable不在配置中。否则它将对 VPN 流量进行 NAT。

乔什

曾经使用相同的两个供应商防火墙有类似的问题。

它最终成为 PFS 默认不匹配。如果我没记错的话，ASA（我的，第 2 组）上的默认设置与 Fortigate 上的默认设置不匹配。

其它你可能感兴趣的问题
上一篇TCP：当限制器到位时，ACK 后的 RST 下一篇管理不同子网中的接入点