ASA5540 in multiple-context SNMP/icmp doesn´t work

aporcaro01 · ‎06-11-2013

Hi there,

I need some help in order to understante what´s going on with an asa540 configure in multiple-context mode.

I Have a cacti server on my lan and now I´m try to monitoring the interface with snmp. When I try to get this information returns the error message:

CISCOASA/CONTEXTA#

JUN 11 2013 01:52:00: %ASA-1-1-6021: Deny UDP reverse path check from 10.6.6.6 to IP_SRV_CACTI on interface inside

JUN 11 2013 01:52:01: %ASA-1-1-6021: Deny UDP reverve path check from 10.6.6.6 to IP_SRV_CACTI on interface inside

If I try to ping returns the same error:

CISCOASA/CONTEXTA#

JUN 11 2013 01:56:09: %ASA-1-1-6021: Deny icmp reverse path check from 10.6.6.6 to IP_SRV_CACTI on interface inside

Following attached the conf of my asa

My question is Why I can´t ping or even use snmp ???

If anyone could me help with a tip or a document about it ...

My best regards

Adriano

Jouni Forss · ‎06-11-2013

Hi,

The reason is this configuration command

ip verify reverse-path interface inside

And also the reason that you dont have a route configured on the Security Context that would tell where the host 10.6.6.6 is located at.

You would need a route command like

route inside 10.6.6.6 255.255.255.255 x.x.x.x

Or something similiar

The command mentioned before ip verify reverse-path interface inside basically means that the ASA will always check that traffic coming from behind the specified interface has a route in the ASAs routing table. If there is not then that traffic is not supposed to enter the ASA through that interface according to ASA and the ASA drops the traffic.

Please remember to mark the reply as the correct answer if it answered your question. Ask more if needed.

- Jouni

aporcaro01 · ‎06-11-2013

Hi Jouni,

I check the information and try the command no ip verify reverse-path interface inside and add a static route to the server but the same error message...

Tks

Adriano

Jouni Forss · ‎06-11-2013

Hi,

Can you provide the "packet-tracer" command output of the traffic you are trying to get through and naturally the command you use.

For example

packet-tracer input inside icmp 10.6.6.6 8 0

And can you share the current configuration so I can see the route you added.

- Jouni

aporcaro01 · ‎06-11-2013

CISCOASA/CONTEXT# packet-tracer input inside icmp 10.132.0.25 8 0 10.6.72.2

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:

Additional Information:

in 10.6.72.2 255.255.255.255 identity

Phase: 4

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in IP_SRV_HSLCACTIP01 255.255.255.255 inside

Phase: 5

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Phase: 6

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 453866627, packet dispatched to next module

Phase: 10

Type: ROUTE-LOOKUP

Subtype: output and adjacency

Result: ALLOW

Config:

Additional Information:

found next-hop 0.0.0.0 using egress ifc identity

adjacency Active

next-hop mac address 0000.0000.0000 hits 22196

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

Route information:

route inside 10.132.0.0 255.255.252.0 10.6.72.1 1

route inside IP_SRV_HSLCACTIP01 255.255.255.255 10.6.72.1 1

CISCOASA/CONTEXT# sh route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is 200.206.50.233 to network 0.0.0.0

C 200.206.50.232 255.255.255.248 is directly connected, outside

S 10.132.0.0 255.255.252.0 [1/0] via 10.6.72.1, inside

S IP_SRV_HSLCACTIP01 255.255.255.255 [1/0] via 10.6.72.1, inside

S* 0.0.0.0 0.0.0.0 [1/0] via 200.206.50.233, outside

Regards,

Jouni Forss · ‎06-11-2013

Hi,

I dont see why you would be getting reverse path check error still when you have the route to the source host.

I guess the 10.6.6.6 wasnt the actual IP address of the source host? Seems you already had the route for the host mentioned in the above packet-tracer already in the original configuration.

I guess you could try to do "clear conn all" to clear all connections on the firewall and then try again.

Unless ofcourse its in some kind of active use which would mean you would be distrupting connections naturally.

- Jouni