Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ASA TCP state-byepass issue

Hi,

I have done the TCP bypassing as the response packet is being received on another interface but, it still doesnt work as it failed to locate the destination in route table. (Note both source & destination are hosted on the same firewall, so no routing to other hop!)

My actual target is:

source        - 10.100.0.95 (directly connected on ASA interface "Sentinel")

destination  - 10.210.0.165 port 22 ( directly connected on ASA interface "Sentinel_UAT")

When i try telnet from source 10.100.0.95 to destination 10.210.0.165:22, I used to get the following logs,

Sentinel-ASA1# sh log | i 10.210.0.165

Oct 18 2013 17:18:07: %ASA-6-302013: Built inbound TCP connection 214031452 for Sentinel:10.100.0.95/2802 (10.100.0.95/2802) to Sentinel_UAT:10.210.0.165/22 (10.210.0.165/22)

Oct 18 2013 17:18:07: %ASA-6-106015: Deny TCP (no connection) from 10.210.0.165/22 to 10.100.0.95/2802 flags SYN ACK  on interface Sentinel_Duplicate

Sentinel-ASA1# sh log | i 10.210.0.165

Oct 18 2013 17:18:07: %ASA-6-302013: Built inbound TCP connection 214031452 for Sentinel:10.100.0.95/2802 (10.100.0.95/2802) to Sentinel_UAT:10.210.0.165/22 (10.210.0.165/22)

Oct 18 2013 17:18:07: %ASA-6-106015: Deny TCP (no connection) from 10.210.0.165/22 to 10.100.0.95/2802 flags SYN ACK  on interface Sentinel_Duplicate

which indicates that ASA drops the packet as the response (SYN-ACK) from destination(10.210.0.165) is being received via another interface "Sentinel_Duplicate". I considered it as a asymetric routing and configured TCP state bypassing for this traffic and the results as below,

Sentinel-ASA1#  sh log | i 10.210.0.165

Oct 21 2013 11:10:10: %ASA-6-302013: Built inbound TCP connection  219653203 for Sentinel:10.100.0.95/1834 (10.100.0.95/1834) to  Sentinel_UAT:10.210.0.165/22 (10.210.0.165/22)

Oct 21 2013 11:10:10: %ASA-6-106100: access-list  Sentinel_Duplicate_access_in permitted tcp  Sentinel_Duplicate/10.210.0.165(22) -> Sentinel/10.100.0.95(1834)  hit-cnt 1 first hit [0x6d7a24fc, 0x0]

Oct 21 2013 11:10:10:  %ASA-6-302303: Built TCP state-bypass connection 219653204 from  Sentinel:10.100.0.95/1834 (10.100.0.95/1834) to  Sentinel_Duplicate:10.210.0.165/22 (10.210.0.165 /22)

Oct 21 2013  11:10:10: %ASA-6-110003: Routing failed to locate next hop for TCP from  Sentinel:10.100.0.95/1834 to Sentinel_Duplicate:10.210.0.165/22

Oct  21 2013 11:10:10: %ASA-6-302304: Teardown TCP state-bypass connection  219653204 from Sentinel:10.100.0.95/1834 to  Sentinel_Duplicate:10.210.0.165/22 duration  0:00:00 bytes 0 No valid  adjacency

Which indicates that the routing is failed and ASA is unable to find the next hop. But the thing is, destination is just hosted behind the same firewall (means directly connected via Sentinel_UAT).

Can you please help me in fixing this route lookup issue?

Thanks in advance.

Regards,

Kam

Everyone's tags (1)
1 REPLY
Super Bronze

ASA TCP state-byepass issue

Hi,

I would personally always rather fix the whole network setup so that I would have no need to allow traffic to flow in such a wierd manner.

I think the basic problem is that there seems to be 3 interfaces involved in this connection and that in itself seems to me to be (perhaps) an impossible scenario.

The most common situation where TCP State Bypass is used to correct a "problem" with traffic flow is that the local LAN is connected to a router and an ASA firewall. The ASA is the default gateway of the LAN but there is a remote network behind the router (also connected to the same LAN) to which ASA has to forward traffic from the LAN users. This creates a situation where the ASA sees the initial TCP SYN but the host on the LAN receives the TCP SYN ACK directly from the router connected to the LAN and therefore the ACK is sent to ASA (default gateway) and blocked. This is overcome with TCP State Bypass.

In your situation the connection is coming from "Sentinel" interface and is forwarded to the destination host through "Sentinel_UAT" but it seems that the default gateway of the device behind "Sentinel_UAT" is the interface "Sentinel_Duplicate" ?

Why is there such a setup even configured?

If there is a host behind "Sentinel_UAT" interface with 2 NIC connected to different networks then would it be possible for you to create an actual static route on the server/host itself and point the network 10.100.0.0/24 (if that is the network) towards the "Sentinel_UAT" interface IP address so that the traffic would never reach the ASA through the interface "Sentinel_Duplicate" but rather flow between interfaces "Sentinel" and "Sentinel_UAT"?

- Jouni

298
Views
0
Helpful
1
Replies