Solved: Severity 1 traps, "Deny ICMP reverse path check from"

3moloz123 · ‎04-21-2011

Hi,

I have 1.2.0.0/19, but the 1.2.24/whatever is not in use (I actually only use the first few /24 in the /19 network).

I do not have 172.16.0/whatever on any interface either.

My wan interface is simply called wan.

I get these as severity 1:

<161>%ASA-1-106021: Deny ICMP reverse path check from 172.16.0.3 to 1.2.24.168 on interface wan

The router (2821) in front of my ASA drops all packets comming from 10/8, 172.16/16 and 192.168/16 networks from its wan, so Im not sure how this can be.

How serious is this? What exactly does it mean? How can I find out who is actually doing this so I can prevent it from getting in my logging?

Christopher Dreier · ‎04-22-2011

Hello 3moloz123,

How often does this happen? If it happens often enough, you can do a packet capture on the outside of your ASA and match all traffic sourced from 172.16.0.3.

If you are certain that no traffic with a source address of 172.16.0.3 egresses your router, destined for your ASA, having originally ingressed on a different router interface, the traffic may be egressing your ASA with a source address of 172.16.0.3, destined to 1.2.24.168, with a MAC of your router, hairpining off of your router, and heading back to your ASA. The ASA then drops the packet due to the RPF check.

If your router supports egress (out) ACLs, you can apply one to the interface that faces the ASA. However, this should only be applied temporarily until you can track down the true source of the traffic. Have you done a packet capture on 172.16.0.3 (or the inside of your ASA) to see if 172.16.0.3 is sending traffic to 1.2.24.168?

Thank you,

Blayne Dreier

Cisco TAC Escalation Team

**Please check out our Podcasts**

TAC Security Show: http://www.cisco.com/go/tacsecuritypodcast

TAC IPS Media Series: https://supportforums.cisco.com/docs/DOC-12758

View solution in original post

rhermes · ‎04-22-2011

Is the only source of 172.16.0.0/16 traffic that your ips sensor sees through your router?

You can enable ACL logging in your router to see if it is receiving traffic from 172.16.0.0/16, or you can make a more specific ACL to log traffic from 172.16.0.3

The destination IP address is routeable in your network, so the packet is being carried past your IPS. Tracing it back to it's source may not be so easy.

- Bob

Christopher Dreier · ‎04-22-2011

Hello 3moloz123,

How often does this happen? If it happens often enough, you can do a packet capture on the outside of your ASA and match all traffic sourced from 172.16.0.3.

If you are certain that no traffic with a source address of 172.16.0.3 egresses your router, destined for your ASA, having originally ingressed on a different router interface, the traffic may be egressing your ASA with a source address of 172.16.0.3, destined to 1.2.24.168, with a MAC of your router, hairpining off of your router, and heading back to your ASA. The ASA then drops the packet due to the RPF check.

If your router supports egress (out) ACLs, you can apply one to the interface that faces the ASA. However, this should only be applied temporarily until you can track down the true source of the traffic. Have you done a packet capture on 172.16.0.3 (or the inside of your ASA) to see if 172.16.0.3 is sending traffic to 1.2.24.168?

Thank you,

Blayne Dreier

Cisco TAC Escalation Team

**Please check out our Podcasts**

TAC Security Show: http://www.cisco.com/go/tacsecuritypodcast

TAC IPS Media Series: https://supportforums.cisco.com/docs/DOC-12758

3moloz123 · ‎04-26-2011

Hi,

Thanks for the replies. As it turns out, I do not filter incoming traffic from reserved networks for a specific provider.

So I guess that mean either my provider does not ingress filtering, and thus allowing spoofing, or the 172-network is their network (from which they may or may not be probing me to see If I use all of my ip addresses).

Thanks for the replies.

3moloz123 · ‎05-02-2011

Even with my bogons filter applied to all neighbours, I still get the icmp reverse path checks.

My bgp config is as follows:

router bgp 39302
bgp router-id 1.2.3.4
no bgp fast-external-fallover
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 2.3.65.10 remote-as 123
neighbor 2.3.65.10 description ISP 1
neighbor 2.3.65.10 ebgp-multihop 3
neighbor 2.3.65.10 password 7 123
neighbor 2.3.65.10 version 4
neighbor 3.4.23.149 remote-as 234
neighbor 3.4.23.149 description ISP 2
neighbor 3.4.23.149 password 7 123
neighbor 3.4.23.149 version 4
neighbor 4.5.183.66 remote-as 345
neighbor 4.5.183.66 description peer 1
neighbor 4.5.183.66 password 7 123
neighbor 4.5.183.66 version 4
neighbor 4.5.183.71 remote-as 456
neighbor 4.5.183.71 description peer 2
neighbor 4.5.183.71 password 7 123
neighbor 4.5.183.71 version 4
neighbor 4.5.183.72 remote-as 567
neighbor 4.5.183.72 description peer 3
neighbor 4.5.183.72 password 7 123
neighbor 4.5.183.72 version 4
!
address-family ipv4
no synchronization
network 7.8.0.0 mask 255.255.224.0
neighbor 2.3.65.10 activate
neighbor 2.3.65.10 prefix-list bogons in
neighbor 2.3.65.10 prefix-list ournet out
neighbor 2.3.65.10 route-map isp1 in
neighbor 2.3.65.10 maximum-prefix 10
neighbor 3.4.23.149 activate
neighbor 3.4.23.149 prefix-list bogons in
neighbor 3.4.23.149 prefix-list ournet out
neighbor 3.4.23.149 route-map isp2 in
neighbor 3.4.23.149 maximum-prefix 1000
neighbor 4.5.183.66 activate
neighbor 4.5.183.66 prefix-list bogons in
neighbor 4.5.183.66 prefix-list ournet out
neighbor 4.5.183.66 maximum-prefix 100
neighbor 4.5.183.71 activate
neighbor 4.5.183.71 prefix-list bogons in
neighbor 4.5.183.71 prefix-list ournet out
neighbor 4.5.183.71 maximum-prefix 100
neighbor 4.5.183.72 activate
neighbor 4.5.183.72 prefix-list bogons in
neighbor 4.5.183.72 prefix-list ournet out
neighbor 4.5.183.72 maximum-prefix 100
default-metric 1
no auto-summary
exit-address-family

!

ip prefix-list bogons seq 400 deny 172.16.0.0/12 le 32

On the cisco ASA, I configured a wan access rule for allowing 172-net, and then logging it:

asa01(config)# access-list wan_access_in line 1 extended permit ip 172.16.0.0 255.240.0.0 any log debugging interval 300 (hitcnt=0) 0xba9efced

asa01(config)# logging enable

asa01(config)# logging buffered debugging

I then waited for the message to appear in the logs again, and when it did there was nothing in the console of the ASA, although I see hit count in the access-list:

access-list wan_access_in line 1 extended permit ip 172.16.0.0 255.240.0.0 any log debugging interval 300 (hitcnt=26) 0xba9efced

3moloz123 · ‎05-12-2011

It just hit me that the prefix-lists are routes that are denied from the bgp neighbors, and not denied traffic (where src address matches).

I guess I'll just create an access-list and apply to each incoming interface!