Paket wurde nicht in den VPN Tunnel bewegt. Debug Flow zeigt ‚packet dropped, no way(tunnel) out‘
Problem:
Packet von trust side eines route-based VPN wurde nicht durch das VPN bewegt. Im debug flow wurde dieser Fehler angezeigt:
packet dropped, no way(tunnel) out.
EF-SSG-1(M)-> get dbuf stream
****** 22471471.0: <Trust/ethernet0/0> packet received [36]******
ipid = 20171(4ecb), @2d417910
packet passed sanity check.
flow_decap_vector IPv4 process
ethernet0/0:10.136.61.1/14->192.168.15.15/125,1(8/0)<Root>
no session found
flow_first_sanity_check: in <ethernet0/0>, out <N/A>
chose interface ethernet0/0 as incoming nat if.
flow_first_routing: in <ethernet0/0>, out <N/A>
search route to (ethernet0/0, 10.136.61.1->192.168.15.15) in vr trust-vr for vsd-0/flag-0/ifp-null
cached route 28 for 192.168.15.15
[ Dest] 28.route 192.168.15.15->192.168.15.15, to tunnel.12
routed (x_dst_ip 192.168.15.15) from ethernet0/0 (ethernet0/0 in 0) to tunnel.12
policy search from zone 2-> zone 2
policy_flow_search policy search nat_crt from zone 2-> zone 2
RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 192.168.15.15, port 28991, proto 1)
No SW RPC rule match, search HW rule
swrs_search_ip: policy matched id/idx/action = 542/101/0x9
Permitted by policy 542
No src xlate NHTB entry search not found: vpn none tif tunnel.12 nexthop 192.168.15.15
packet dropped, no way(tunnel) out
Lösung:
Dies kann passieren, wenn 2 VPN an dasselbe Tunnel Interface gebunden werden. Wenn man sich ‚get interface tunnel.1‚ anschaut, erkennt man, dass nur 1 Next-Hop Tunnel Binding Entry existiert.
- Entfernen des nicht benötigten VPN
- Ein anderes Tunnel Interface für das andere VPN benutzen.