cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1409
Views
0
Helpful
3
Replies

ASA Packet inspection function

Bova_1980
Level 1
Level 1

Hi All,

 

I have a kind of basic question.

1)Firewall model -> Cisco Adaptive Security Appliance Software Version 8.2(5)

2)nat-control enabled

3)Inbound connection (initiated from the outside direct to inside)

3)regular static NAT configured

static (inside,outside) x.x.x.x 172.17.32.50 netmask 255.255.255.255

ASA-5540# show xlate detail | include 172.17.32.50
NAT from inside:172.17.32.50 to outside:x.x.x.x flags s

4)inside interface sec-level -> 100

5)outside interface sec-level -> 0

6)ACL applied to outside interface

access-group outside-in in interface outside

 

6)pubblic IP which start the connection is: y.y.y.y

7)show conn is

TCP outside:y.y.y.y/55400 (y.y.y.y/55400) inside:172.17.32.50/443 (x.x.x.x/443), flags SaAB, idle 3s, uptime 6s, timeout 30s, bytes 0
TCP outside:y.y.y.y/55375 (y.y.y.y/55375) inside:172.17.32.50/443 (x.x.x.x/443), flags SaAB, idle 13s, uptime 16s, timeout 30s, bytes 0
TCP outside:y.y.y.y/55376 (y.y.y.y/55376) inside:172.17.32.50/443 (x.x.x.x/443), flags SaAB, idle 13s, uptime 16s, timeout 30s, bytes 0

 

Problem:

1)As you can see from the flag, the firewall is

A -> awaiting inside ACK to SYN

Investigation done:

1)Routing between the firewall and the server is in place

2)the xlate is ok, and checking the "Cisco Firewall´s seequence of Packet Inspection Functions",

 

asa.pngit seems to me that after the xlate lookup there is nothing else preventig this request to hit the server.

 

Am I wrong or should I further check something else on the firewall that might block the connection (ACL )?

 

Thanks.

 

1 Accepted Solution

Accepted Solutions

Why don't you use packet-trace command on ASA to see what is happening. You
need to simulate the return ACK from inside. If its allowed, use packet
capture on ASA inside interface to see if return packet is coming

View solution in original post

3 Replies 3

Why don't you use packet-trace command on ASA to see what is happening. You
need to simulate the return ACK from inside. If its allowed, use packet
capture on ASA inside interface to see if return packet is coming

right, done and problem solved. With the packet-trace i verified that nothing was blocking the communication from both side. I than moved my investigation to the next-router and i discovered an ACL in inbound to the default-gateway of the server which was blocking the ack.
Even if I performed all these check before reading your answer, i will mark in any it as correct. Thanks.

Good news
Review Cisco Networking for a $25 gift card