cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
310
Views
0
Helpful
4
Replies
Beginner

PBR issue on ASA 5515 tcp no connection

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 

 

Everyone's tags (3)
4 REPLIES 4
Highlighted
Beginner

Re: PBR issue on ASA 5515 tcp no connection

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".

 

log.PNG

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

----------------------------------------------------------------

https://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/show_asp_drop/show_asp_drop.html#pgfId-324239

Highlighted
Beginner

Re: PBR issue on ASA 5515 tcp no connection

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

Highlighted
Beginner

Re: PBR issue on ASA 5515 tcp no connection

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.

 

Highlighted
Beginner

Re: PBR issue on ASA 5515 tcp no connection

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