Solved: Re: Routing failed to locate next hop for ICMP from outside:8.8.8.8/0

Denniz2100 · ‎07-29-2021

Good day all.

My network setup.

WiFi Device > APs > PoE Switch > WLC(2504) > Core(3750) > ASA(PAT/NAT) > Internet

We have a wireless setup where users connects to our staff WiFi network and they authenticate via Microsoft RADIUS server(PEAP). Recently we started having issues, when we connect to staff WiFi it connects but shows "No internet, Secured", while it is connected we can access local resources(RDP, http/s etc.) but not the internet. When we connect an ethernet cable while the WiFi is connected on the same machine, the "No internet, Secured" status changes to Connected but when i remove the cable, it goes back to "No internet, Secured". I did some traces from our ASA and i see: Routing failed to locate next hop for ICMP from outside:8.8.8.8/0 to inside:172.31.40.85/1. We have PAT which we use to access internet and other NAT statements for other services. i checked our RADIUS server and WLC logs and i don't see any errors, i could be wrong. It seems like the traffic can go out, but no route back, i could be wrong.

When i run wireshark captures there no return traffic "no response"

Note: Wired network works well without issues, it's only the staff WiFi which gives issues even though it uses the same internet link as the the wired staff net.

Georg Pauwen · ‎07-29-2021

Hello,

which IP addresses do the WiFi clients get when connected through WiFi ? Can you ping these addresses from the ASA at all ?

The problem could also be with the wireless client computers themselves. Rather than paraphrasing, have a look at the article below and check if any of these 'fixes' work for you...

Fix “No Internet, Secured” WiFi Network Error

https://lazyadmin.nl/it/no-internet-secured-windows-10/

View solution in original post

Georg Pauwen · ‎07-29-2021

Hello,

which IP addresses do the WiFi clients get when connected through WiFi ? Can you ping these addresses from the ASA at all ?

The problem could also be with the wireless client computers themselves. Rather than paraphrasing, have a look at the article below and check if any of these 'fixes' work for you...

Fix “No Internet, Secured” WiFi Network Error

https://lazyadmin.nl/it/no-internet-secured-windows-10/

Denniz2100 · ‎07-29-2021

WiFi clients gets 172.31.40.0/24 ip addresses and the wired clients gets a different subnet. so what happens is that as soon as i connect ethernet cable to the client(Win10), the WiFi status changes to connected but traffic go out through the wired cable. this is how i tested this: i added route via CMD(route add 8.8.8.8 mask 255.255.255.255 172.31.40.1) to force 8.8.8.8 traffic to go via the WiFi gateway and generated traffic and then i inspected logs on asa and i saw the Routing failed to locate next hop for ICMP from outside error, It affects all traffic types not just ICMP. it seems to affect only the returning traffic into the outside interface because Wireshark shows traffic going out, but no response.
I checked the article that you suggested but it's no helping, the problem started when we tried to migrate our RADIUS server to the cloud, but it has been restored back into our network with the same settings, no errors generated on RADIUS and AD side.

Denniz2100 · ‎07-31-2021

A route back to wifi subnet was missing in the asa routing table. it has always been there and im not sure when it was removed. i only had to add it again.

Richard Burts · ‎07-31-2021

Thanks for the update. Glad to know that you have discovered that the problem was due to a missing route.

HTH

Rick

balaji.bandi · ‎07-29-2021

You may not have ICMP enable on ASA , that is ok. until you want to enable.

When you connected to Ethernet you see that Internet connected, that time are you able to browse internet no issue - and ping still have issue here since there no ICMP allowed, or is the ping to 8.8.8.8 works ?)

what is the IP Address for Wired network and Wireless network ?

what happends when you configured wireless device with static IP (one of the address from wireless pool ? - test is that works ?)

May be required some diagnosis here - take user wireless IP and open ASDM monitor the Logs ?

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Denniz2100 · ‎07-30-2021

WiFi clients gets 172.31.40.0/24 ip addresses and the wired clients gets a different subnet(192.168.0.0/24). so what happens is that as soon as i connect ethernet cable to the client(Win10), the WiFi status changes to connected but traffic go out through the wired cable. this is how i tested this: i added route via CMD(route add 8.8.8.8 mask 255.255.255.255 172.31.40.1) to force 8.8.8.8 traffic to go via the WiFi gateway and generated traffic and then i inspected logs on asa and i saw the Routing failed to locate next hop for ICMP from outside error, It affects all traffic types not just ICMP. it seems to affect only the returning traffic into the outside interface because Wireshark shows traffic going out, but no response. WiFi addresses gets allocated via DHCP.

Here are the logs:

6|Jul 30 2021|09:22:18|302014|13.107.4.52|80|172.31.40.85|64142|Teardown TCP connection 46743588 for outside:13.107.4.52/80 to Server_Net:172.31.40.85/64142 duration 0:00:03 bytes 0 TCP Reset-O from outside
6|Jul 30 2021|09:22:15|110003|13.107.4.52|80|172.31.40.85|64142|Routing failed to locate next hop for TCP from outside:13.107.4.52/80 to Server_Net:172.31.40.85/64142
6|Jul 30 2021|09:22:15|302013|172.31.40.85|64142|13.107.4.52|80|Built outbound TCP connection 46743588 for outside:13.107.4.52/80 (13.107.4.52/80) to Server_Net:172.31.40.85/64142 (41.180.2.226/64142)
6|Jul 30 2021|09:22:10|302014|13.107.4.52|80|172.31.40.85|64142|Teardown TCP connection 46743343 for outside:13.107.4.52/80 to Server_Net:172.31.40.85/64142 duration 0:00:03 bytes 0 TCP Reset-O from outside
6|Jul 30 2021|09:22:07|302013|172.31.40.85|64142|13.107.4.52|80|Built outbound TCP connection 46743343 for outside:13.107.4.52/80 (13.107.4.52/80) to Server_Net:172.31.40.85/64142 (41.180.2.226/64142)
6|Jul 30 2021|09:22:06|302014|13.107.4.52|80|172.31.40.85|64142|Teardown TCP connection 46743179 for outside:13.107.4.52/80 to Server_Net:172.31.40.85/64142 duration 0:00:03 bytes 0 TCP Reset-O from outside
6|Jul 30 2021|09:22:03|302013|172.31.40.85|64142|13.107.4.52|80|Built outbound TCP connection 46743179 for outside:13.107.4.52/80 (13.107.4.52/80) to Server_Net:172.31.40.85/64142 (41.180.2.226/64142)
6|Jul 30 2021|09:22:03|302014|13.107.4.52|80|172.31.40.85|64142|Teardown TCP connection 46743083 for outside:13.107.4.52/80 to Server_Net:172.31.40.85/64142 duration 0:00:03 bytes 0 <snp_drop_none>
6|Jul 30 2021|09:22:00|110003|13.107.4.52|80|172.31.40.85|64142|Routing failed to locate next hop for TCP from outside:13.107.4.52/80 to Server_Net:172.31.40.85/64142
6|Jul 30 2021|09:22:00|302013|172.31.40.85|64142|13.107.4.52|80|Built outbound TCP connection 46743083 for outside:13.107.4.52/80 (13.107.4.52/80) to Server_Net:172.31.40.85/64142 (41.180.2.226/64142)
6|Jul 30 2021|09:22:00|305011|172.31.40.85|64142|41.180.2.226|64142|Built dynamic TCP translation from Server_Net:172.31.40.85/64142 to outside:41.180.2.226/64142
6|Jul 30 2021|09:16:44|305012|172.31.40.85|64655|41.180.2.226|64655|Teardown dynamic TCP translation from Server_Net:172.31.40.85/64655 to outside:41.180.2.226/64655 duration 0:00:46
6|Jul 30 2021|09:16:44|305012|172.31.40.85|59366|41.180.2.226|59366|Teardown dynamic TCP translation from Server_Net:172.31.40.85/59366 to outside:41.180.2.226/59366 duration 0:00:46
6|Jul 30 2021|09:16:44|305012|172.31.40.85|64571|41.180.2.226|64571|Teardown dynamic TCP translation from Server_Net:172.31.40.85/64571 to outside:41.180.2.226/64571 duration 0:00:46
6|Jul 30 2021|09:16:13|302014|8.8.8.8|443|172.31.40.85|64655|Teardown TCP connection 46735326 for outside:8.8.8.8/443 to Server_Net:172.31.40.85/64655 duration 0:00:15 bytes 0 No valid adjacency
6|Jul 30 2021|09:16:13|302014|8.8.8.8|443|172.31.40.85|64571|Teardown TCP connection 46735318 for outside:8.8.8.8/443 to Server_Net:172.31.40.85/64571 duration 0:00:15 bytes 0 No valid adjacency
6|Jul 30 2021|09:16:13|302014|8.8.8.8|443|172.31.40.85|59366|Teardown TCP connection 46735319 for outside:8.8.8.8/443 to Server_Net:172.31.40.85/59366 duration 0:00:15 bytes 0 No valid adjacency
6|Jul 30 2021|09:16:09|110003|8.8.8.8|443|172.31.40.85|64571|Routing failed to locate next hop for TCP from outside:8.8.8.8/443 to Server_Net:172.31.40.85/64571
6|Jul 30 2021|09:15:58|302013|172.31.40.85|64655|8.8.8.8|443|Built outbound TCP connection 46735326 for outside:8.8.8.8/443 (8.8.8.8/443) to Server_Net:172.31.40.85/64655 (41.180.2.226/64655)
6|Jul 30 2021|09:15:58|305011|172.31.40.85|64655|41.180.2.226|64655|Built dynamic TCP translation from Server_Net:172.31.40.85/64655 to outside:41.180.2.226/64655
6|Jul 30 2021|09:15:58|110003|8.8.8.8|443|172.31.40.85|64571|Routing failed to locate next hop for TCP from outside:8.8.8.8/443 to Server_Net:172.31.40.85/64571
6|Jul 30 2021|09:15:58|302013|172.31.40.85|59366|8.8.8.8|443|Built outbound TCP connection 46735319 for outside:8.8.8.8/443 (8.8.8.8/443) to Server_Net:172.31.40.85/59366 (41.180.2.226/59366)
6|Jul 30 2021|09:15:58|305011|172.31.40.85|59366|41.180.2.226|59366|Built dynamic TCP translation from Server_Net:172.31.40.85/59366 to outside:41.180.2.226/59366
6|Jul 30 2021|09:15:58|302013|172.31.40.85|64571|8.8.8.8|443|Built outbound TCP connection 46735318 for outside:8.8.8.8/443 (8.8.8.8/443) to Server_Net:172.31.40.85/64571 (41.180.2.226/64571)
6|Jul 30 2021|09:15:58|305011|172.31.40.85|64571|41.180.2.226|64571|Built dynamic TCP translation from Server_Net:172.31.40.85/64571 to outside:41.180.2.226/64571
6|Jul 30 2021|08:45:39|305012|172.31.40.85|1|41.180.2.226|1|Teardown dynamic ICMP translation from Server_Net:172.31.40.85/1 to outside:41.180.2.226/1 duration 13:39:22
6|Jul 30 2021|08:45:08|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:45:07|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:45:03|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:45:02|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:58|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:57|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:53|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:52|110003|8.8.8.8|0|172.31.40.85|1|Routing failed to locate next hop for ICMP from outside:8.8.8.8/0 to Server_Net:172.31.40.85/1
6|Jul 30 2021|08:44:52|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:49|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:47|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:43|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:42|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:38|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:37|110003|8.8.8.8|0|172.31.40.85|1|Routing failed to locate next hop for ICMP from outside:8.8.8.8/0 to Server_Net:172.31.40.85/1
6|Jul 30 2021|08:44:37|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:33|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:32|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:28|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:27|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:23|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:22|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:18|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:17|110003|8.8.8.8|0|172.31.40.85|1|Routing failed to locate next hop for ICMP from outside:8.8.8.8/0 to Server_Net:172.31.40.85/1
6|Jul 30 2021|08:44:17|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0

paul driver · ‎07-30-2021

Hello

@Denniz2100 wrote:

Built dynamic TCP translation from

Teardown TCP connection
no response. It affects all traffic types not just ICMP.

Check your NAT and ACL statements against the wired and wifi subnets, The above seems to suggest the wifi isnt correct

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Denniz2100 · ‎07-30-2021

Hi Paul,

We have not made changes on the firewall recently. Packet tracer shows that packet is allowed.

asa# packet-tracer input server_Net tcp 172.31.40.85 https 172.217.170.4 https detailed transmit

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 5.5.5.6 using egress ifc outside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group Server_Net_access_in in interface Server_Net
access-list Server_Net_access_in remark Google Traffic inactive
access-list Server_Net_access_in extended permit object-group DM_INLINE_SERVICE_23 any4 object-group DM_INLINE_NETWORK_17
object-group service DM_INLINE_SERVICE_23
service-object ip
service-object tcp destination eq www
service-object tcp destination eq https
object-group network DM_INLINE_NETWORK_17
network-object object Google
network-object object Google_132
network-object object Google_drive
network-object object Googletest
network-object object US_ip_range
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f325ef22cd0, priority=13, domain=permit, deny=false
hits=275619, user_data=0x7f32536a8cc0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=172.217.170.0, mask=255.255.254.0, port=0, tag=any, dscp=0x0
input_ifc=Server_Net, output_ifc=any

Phase: 3
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection decrement-ttl
service-policy global_policy global
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f326092b490, priority=7, domain=conn-set, deny=false
hits=5865376, user_data=0x7f32609299b0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Server_Net, output_ifc=any

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (Server_Net,outside) after-auto source dynamic inside_mpls_whitelist_blanket interface
Additional Information:
Dynamic translate 172.31.40.85/443 to 5.5.5.5/349
Forward Flow based lookup yields rule:
in id=0x7f325ef03b50, priority=6, domain=nat, deny=false
hits=48387, user_data=0x7f325edfeef0, cs_id=0x0, flags=0x0, protocol=0
src ip/id=172.31.40.0, mask=255.255.255.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Server_Net, output_ifc=outside

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f324e83c040, priority=1, domain=nat-per-session, deny=true
hits=9625208, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f325e616990, priority=0, domain=inspect-ip-options, deny=true
hits=85739755, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Server_Net, output_ifc=any

Phase: 7
Type: SFR
Subtype:
Result: ALLOW
Config:
class-map sfr
match access-list sfr_redirect
policy-map global_policy
class sfr
sfr fail-open
service-policy global_policy global
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f3260987670, priority=71, domain=sfr, deny=false
hits=5980725, user_data=0x7f326006c6a0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Server_Net, output_ifc=any

Phase: 8
Type: FLOW-EXPORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f326098d5b0, priority=18, domain=flow-export, deny=false
hits=45399070, user_data=0x7f32604db770, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Server_Net, output_ifc=any

Phase: 9
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f325fee9920, priority=13, domain=ipsec-tunnel-flow, deny=true
hits=45254890, user_data=0x0, cs_id=0x0, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Server_Net, output_ifc=any

Phase: 10
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (Server_Net,outside) after-auto source dynamic inside_mpls_whitelist_blanket interface
Additional Information:
Forward Flow based lookup yields rule:
out id=0x7f325ef04450, priority=6, domain=nat-reverse, deny=false
hits=49199, user_data=0x7f325edaa120, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=172.31.40.0, mask=255.255.255.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Server_Net, output_ifc=outside

Phase: 11
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0x7f324e83c040, priority=1, domain=nat-per-session, deny=true
hits=9625210, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 12
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0x7f325e75b600, priority=0, domain=inspect-ip-options, deny=true
hits=6154319, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=outside, output_ifc=any

Phase: 13
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 46978950, packet dispatched to next module
Module information for forward flow ...
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_sfr
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow ...
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_sfr
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Result:
input-interface: Server_Net
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

Denniz2100 · ‎07-30-2021

.

Richard Burts · ‎07-30-2021

The debug output is helpful. If you look in the output for the failed to locate next hop messages you will find messages before it that relates to that message like these

6|Jul 30 2021|08:44:42|302020|172.31.40.85|1|8.8.8.8|0|Built outbound ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0

6|Jul 30 2021|08:44:53|302021|8.8.8.8|0|172.31.40.85|1|Teardown ICMP connection for faddr 8.8.8.8/0 gaddr 41.180.2.226/1 laddr 172.31.40.85/1 type 8 code 0
6|Jul 30 2021|08:44:52|110003|8.8.8.8|0|172.31.40.85|1|Routing failed to locate next hop for ICMP from outside:8.8.8.8/0 to Server_Net:172.31.40.85/1

What this tells me is that there was an outbound ICMP packet that did have an address translation built (first of those messages). There may have been a response and then the ICMP connection was torn down. This is normal. Then there was another packet from 8.8.8.8 but at this point the translation (which is what is used to find the route to the source) has been torn down and the ASA is not able to find the route.

I am not saying that there is not an issue. But I am saying that the route not found is not causing the problem. I have seen the route not found message in ASA many times and it is pretty normal.

I would suggest that you look at sequences like this one

6|Jul 30 2021|09:22:18|302014|13.107.4.52|80|172.31.40.85|64142|Teardown TCP connection 46743588 for outside:13.107.4.52/80 to Server_Net:172.31.40.85/64142 duration 0:00:03 bytes 0 TCP Reset-O from outside
6|Jul 30 2021|09:22:15|110003|13.107.4.52|80|172.31.40.85|64142|Routing failed to locate next hop for TCP from outside:13.107.4.52/80 to Server_Net:172.31.40.85/64142

This is another instance of route not found but looking at the preceding message it is clear that the connection was torn down because 13.107.4.52 sent a TCP reset. And notice that bytes is zero. So the attempt to establish a TCP session was not successful. For some reason the remote server detected an error and terminated the connection. You need to do some investigation to see why the remote server did not accept the connection. I suspect that a similar kind of thing is happening with your ICMP traffic.

HTH

Rick

Denniz2100 · ‎07-31-2021

i did some ping tests to my outside interface and I get this error:

172.31.40.85 923 Failed to locate egress interface for ICMP from Server_Net:172.31.40.85/923 to 5.5.5.6/0

and

216.58.223.131 443 172.31.40.85 1029 Teardown TCP connection 57014448 for outside:216.58.223.131/443 to Server_Net:172.31.40.220/1029 duration 0:00:21 bytes 0 No valid adjacency

Maybe if i can resolve this one, the other error will be resolved as well,?

paul driver · ‎07-29-2021

Hello

Curious - on the ASA try the following as it may be you have icmp inspection for the wired traffic but not for the the wifi.

policy-map global_policy
class inspection_default
inspect icmp

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Richard Burts · ‎07-29-2021

I am thinking along the same line as Paul that this may be an issue with inspection of the traffic from wireless. I think it is significant that the error message in your post is an error about traffic from outside going to inside. This suggests that it is not associating what is probably the ping response coming in with the ping request that was sent out. Failure to associate response with the original request is frequently caused by issues with inspection.

HTH

Rick

Denniz2100 · ‎07-30-2021

It seems to affect the returning traffic into the outside interface because Wireshark shows traffic going out, but no response. It affects all traffic types not just ICMP. i ran the commands suggested by Paul to enable ICMP inspection but i still get the same error