Drop with Packet Capture?help

[Ibrahim Jamil]

Hi Folks

how to start troubleshoot the Below:

the user source address 172.16.3.2 (Behind ASA-1

the destination SIP Server: 10.100.100.100 (Behind ASA-2)

packet-tracer input outside udp 172.16.3.2 4263  10.100.100.100 sip

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
             
Phase: 4
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: DMZ
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

[m.kafka]

ibrahim.jamil wrote:
Hi Folks
how to start troubleshoot the Below:
the user source address 172.16.3.2 (Behind ASA-1
the destination SIP Server: 10.100.100.100 (Behind ASA-2)
packet-tracer input outside udp 172.16.3.2 4263  10.100.100.100 sip
Phase: 1
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: FLOW-LOOKUP
Subtype: 
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow
Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
              
Phase: 4
Type: ACCESS-LIST
Subtype: 
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: DMZ
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Look at you access lists. normally packet-tracer will write the acl-statement which is blocking the connection

rgds,

MiKa

[Ibrahim Jamil]

on witch asa should i check ASA-1 or ASA-2 ? on asa-1 i have an access-list permit ip any any,pls tell where?

[m.kafka]

on the asa where you did the packe-trace

then repeat on the other asa (packet-tracer and acl-verification)

[Ibrahim Jamil]

Dude,on the asa where i did packet-trace there is an access-list that match all traffic permit ip any any

access-list cached ACL log flows: total 0, denied 0

[m.kafka]

Hi Ibrahim,

then its somewhere else, the packet-tracer output "denied by implicit rule" doesn't neccessaryly point to the implicit "deny any" of the acl, it was just so tempting.

I have seen this message pointing to following problems:

1. Interfaces having the same security level without "same-security-traffic permit..."
2. NAT issues, I don't see an phase for NAT ont your packet-tracer output

what does the show xlate detail and show conn detail tell you for 172.16.3.2?

maybe you should post a sanitized sh run (obfuscate public IPs, keys and passwords, even the encrypted)

rgds,

MiKa

[Ibrahim Jamil]

Hi

What do mean below?

1. NAT issues, I don't see an phase for NAT ont your packet-tracer output

sh xlate

1. Global 50.50.50.10 Local 172.16.3.2

thanks

[Kureli Sankar]

Ibrahim,

So, the topology is like this?

host(172.16.3.2)-- (in)ASA-1(out)----(out)ASA2(in)---SIP server (100.100.100.100)

Now, pls. verify the following:

On ASA1:

1. Do you have a route for 100.100.100.x pointing to ASA2?

2. What translation are you using for this host 172.16.3.2?

3. what do the syslogs show on ASA when it fails?

5. Do you have SIP inspection enabled?

6. Is 100.100.100.100 the mapped IP of the SIP server behind ASA2?

On ASA2:

1. what do the syslogs show when the connection fails?

2. What kind of translation is the SIP server IP configured to use on ASA2. It has to be static if you will be trying to reach it from the outside.

enable logging and post the output:

conf t

logging on

logging buffered 7

sh logg | i x.x.x.x

where x.x.x.x is 172.16.3.2 on ASA1 and 100.100.100.100 on ASA2

-KS

[Ibrahim Jamil]

1. 'yeah i can ping 100.100.100.100 form asa-1
2. Global 50.50.50.10 Local 172.16.3.2
3. Teardown TCP connection 2687341 for outside:100.100.100.100/4443 to inside:172.16.3.2/3128 duration 0:00:00 bytes 0 TCP Reset-O
4. SIP is enable under policy
5. no mapping
6. BTH the coonection betweeen two sites r MPLS

Pls Help

[Kureli Sankar]

Reset-O means the reset came from the lower security interface.

We need captures to see which mac address is responsible for the reset.

It would be better to gather the capture on the ingress and egress interface of ASA-2.

It would be better to open a TAC case as we will need simultaneous captures ingress and egress on both ASAs as well as gather the debug level syslogs from both the ASAs during the problem to figure out where the reset is coming from.

-KS

[Ibrahim Jamil]

Hi Sankar!

might the AIP-SSM sensor block traffic? if so how to check that?

[Kureli Sankar]

You can certainly try to remove the IPS module from the policy-map from ASA2 and try the flow.

-KS

[Ibrahim Jamil]

Hi Sankar

I realy Appreciate ur Help and ur Professional Support; how can i check that from the IPS module itself?

so to remove the IPS from the policy-map

so i need the below:

policy-map global_policy

no class ips-module

[Ibrahim Jamil]

Hi Sunkar

PLs chexk the below

5510# sh logg | in 10.0.4.25
%ASA-7-609001: Built local-host outside:100.100.100.100
%ASA-6-302013: Built outbound TCP connection 2697766 for outside:100.100.100.100/4443 (100.100.100.100/4443) to inside:172.16.3.2/3602 (50.50.50.10/3602)
%ASA-6-302014: Teardown TCP connection 2697766 for outside:100.100.100.100/4443 to inside:172.16.3.2/3602 duration 0:00:00 bytes 0 TCP Reset-O
%ASA-7-609002: Teardown local-host outside 100.100.100.100 duration 0:00:00

[Kureli Sankar]

Ibrahim,

Pls. enable logging timestamp.

conf t

logging timestamp

This will give you a time stamp of when these syslogs are getting printed.

Now, I see that it is immediately getting torn down and there is no bytes passed "duration 0:00:00 bytes 0".

So, this may very well be reset by the IPS module

Why don't you exempt this traffic from being scanned by the module?

You can do this via MPF. As to how to check this in the IPS GUI, you should be able to see these event under the monitoring tab in the IDM GUI.

-KS