01-08-2020 06:51 AM - last edited on 02-24-2020 11:39 AM by Monica Lluis
Hello to all
I have a problem with my ASA 5515 configured in multicontext mode
I have a Test subnet that responds to the address 10.254.254.0/29 which must reach another subnet 172.21.22.0/26 on port 80 on another ASA in another location of my company.
The default routing 0.0.0.0 is addressed to 192.168.60.1 but to reach the subnet 172.21.22.0/26 I have to go through another router that has IP 10.0.91.68.
I have to use PBR because the destination would also be reachable through 192.168.60.1 but only for src 10.254.254.0/29 it must pass through 10.0.91.68
On the ASA I have configured a route map and an ACL that indicates that the 10.254.254.0/29 network will have as a next-hop for all destinations 10.0.91.68 (it is an ISR4431) which is in PTP with the ASA which has interface with IP 10.0.91.65
Instead for a local subnet 10.0.61.128/25 it will evaluate the normal route.
I debugged the policy routing on the ASA and everything seems correct as you can read:
pbr: First matching rule from ACL(19)
pbr: route map PBR_SD-WAN, sequence 1, permit; proceed with policy routing
pbr: evaluating next-hop 10.0.91.68
pbr: policy based routing applied; egress_ifc = SDWAN : next_hop = 10.0.91.68
pbr: policy based route lookup called for 10.254.254.5/13250 to 172.21.22.10/80 proto 6 sub_proto 0 received on interface TEST-HELPLINE
If I do a packet capture (see attachment) I see the packet transit and arrive on the Remote ASA but the return packet stops on the interface of the originating ASA and the ASA logs say (see attachment)
If instead I use a static route that indicates that for 172.21.22.10 the GW is 10.0.91.68 the telnet on port 80 is successful.
Can anyone help me by indicating if and where there would be an error?
Is it possible that it is an anomaly of the PBR?
It seems as if there was asymmetric routing but it is not so because the packet comes out and returns from the same interface as seen by the packet capture.
See too the wireshark attacchment
Thanks in advance
Daniele
01-08-2020 08:17 AM - edited 01-08-2020 08:23 AM
Hi,
Your ASA was built the session for your connection, but teared down afterward. And the return packet is arrived after your ASA cleared the session, so the log displayed "no connection".
Could you post your ASA software version?
And I guess you didn't issue 'clear local-host', then it might be a BUG.
---------------------------------------------------------------- Name: host-removed Host is removed: Flow removed in response to "clear local-host" command. Recommendation: This is an information counter. Syslogs: 302014, 302016, 302018, 302021, 305010, 305012, 609002 ----------------------------------------------------------------
01-08-2020 09:00 AM
Hello
Thanks for your answer.
My software version of ASA is 9.5 (2) and ASA is a 5515.
The test I do is a tcp ping from ASDM and not directly from a physical PC (see attachment). Could that be the problem?
But it is also true that with the static route it works perfectly with ping tcp .
Thanks again for the support
01-08-2020 09:48 AM - edited 01-08-2020 09:50 AM
Hi,
Oh, you were using ping tcp on ASDM. Could you try again with timeout value set to 5 seconds?
It would be great if you could try to "telnet x.x.x.x 3389" from your server as well.
From you log, the network latency is a little bit high (it takes 2 ~ 3 seconds for return packet).
I am not yet sure why using static route yield a positive result. But as you mentioned, it's not look like a asymmetric route issue.
01-13-2020 02:59 AM
Hello
Thank you for your suggestion.
I tried adding the 5 second timeout but the result is the same. After 5 seconds the host is removed from the connections table and therefore I get the tcp no connection.
Perhaps the only test to do would be to connect a PC on that VLAN to get a more reliable response.
Regards
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide