ASA 5516X w/ FTD, traffic being denied on interface nlp_int_tap from 169.254.1.2

[MauryJ]

Hello All,

We have setup a new ASA 5516X running FTD 6.2.3.2, and have certain events being logged to an external syslog server.   The ASA is sending events to our server every few seconds with events such as:

%ASA-2-106006: Deny inbound UDP from 169.254.1.2/57744 to {Domain Controller IP}/123 on interface nlp_int_tap

%ASA-2-106006: Deny inbound UDP from 169.254.1.2/40736 to {Syslog Server IP}/514 on interface nlp_int_tap

%ASA-2-106007: Deny inbound UDP from 169.254.1.2/35521 to {Domain Controller IP}/53 due to DNS Query

The referenced domain controller is both an NTP and DNS server, so I assume that some service on the ASA is attempting to contacting these servers.

I opened a case with TAC on it, and they said that something on or outside of our network is trying to send these requests through the ASA, where they are getting blocked.  But we don't have any 169.254.x.x networks -- I didn't think that range was even valid for routing, and we allow outbound NTP.   I attempted disconnecting all interfaces (except for the inside connection) and the messages continue to be sent to our syslog server from the ASA.

I haven't been able to find much on this interface nlp_int_tap and whats its related to - Any ideas?

Thanks

[Nikolaj Pabst]

Hi Maurice,

This could be a spoofed IP address.. What are attached on the interface: nlp_int_tap, is it only a tap or?

[dib-tawk@hotmail.com]

Dears,

Kindly note that we are facing the same problem on our newly installed FPR2120 (ASA image).

We are receiving continuous hits like below:

Deny inbound UDP from 169.254.1.3/36536 to {DNS SERVER} /53 due to DNS Query

Please note that this wasn't the case on ASA5540.

Can you please help. 

[Marvin Rhoads]

169.254.0.0 addresses are APIPA and non-routable - i.e., restricted to the local broadcast scope (usually meaning VLAN). Newer ASA or FTD code sometimes introduces changes in default inspection behavior that highlight the presence of such traffic which may have been silently ignored by earlier devices.

If you track back to the associated MAC address you generally will find a device with a problem getting an IP address via DHCP or having no address statically configured. It's generally not a problem beyond that one device.

[dib-tawk@hotmail.com]

Dear Marvin,

I really appreciate your reply.

Kindly note that I tried to find the originating MAC address but in vain.

As per the ASA logging, we are only getting the source/destination IPs and not even the source Zone.

Can you please help on how to get the MAC address or what are the steps to be taken.

Thank youin advance for your time and support. 

[Marvin Rhoads]

A packet-capture would reveal the source MAC address. Then you could check the mac address tables of the switch or switches in that VLAN/subnet for the device port.

[00ummhxj6ogAfkkys5d6]

我也遇到了同样的问题，请问您解决没。