Symptom

1) VPN users are unable to reach certain services behind the firewall. 2) Packets are dropped with the ASP code "no-adjacency". This can be confirmed by applying a capture with trace enabled. # show cap capture vpn type raw-data trace interface outside include-decrypted [Capturing - 188 bytes] match ip any host 192.168.20.150 Phase: 21 Type: SUBOPTIMAL-LOOKUP Subtype: suboptimal next-hop Result: ALLOW Config: Additional Information: ifc selected is not same as preferred ifc Doing route lookup again on ifc dmz Result: input-interface: outside input-status: up input-line-status: up output-interface: dmz output-status: up output-line-status: up Action: drop Drop-reason: (no-adjacency) No valid adjacency

Conditions

1) To have remote users or VPN tunnels using the ASA or FTD as Headend. 2) Traffic coming from the VPN tunnel using an interface to route the destination traffic different to the one preferred by the routing table. For example, a NAT rule without route-lookup. nat (dmz,outside) source static 192.168.20.0-net 192.168.20.0-net destination static RAVPN RAVPN 3) A tunneled static route added for the destination interface while the routing table is using a specified entry. S 192.168.20.0 255.255.255.0 [1/0] via 192.168.2.11, inside S 0.0.0.0 0.0.0.0 [255/0] via 192.168.1.11, dmz tunneled 4) Floating-conn timeout configured (disabled by default with a value of 0:0:0). timeout floating-conn 0:00:30

Workaround

A route can be added to the destination that is less general than the one in the routing table. This will force the suboptimal lookup while it won't affect the routing table decision for any other traffic. Ensure that the wider entry doesn't affect any other network. route dmz 192.168.0.0 255.255.224.0 192.168.2.11 If floating-conn timeout is changed to its default value (disabled), this bug can be avoided. timeout floating-conn 0:00:00

Further Problem Description