What are the right steps to locate a neighboring device adjacent to a Cisco ASA firewall? Can anyone help me with the steps please, one by one?

  • Hi Souvik Bhattacharya, In addition to what Ron said, if you want to generally see what is flowing through the ASA then you could run the Packet Capture Wizard via the CLI or ASDM. This will help identify what IP Addresses are speaking to what IP Addresses. cisco.com/c/en/us/support/docs/security/… – ssedwards Oct 18 '17 at 15:20
  • The OP was asking about neighboring devices, not traffic flowing through the ASA (such as client computers and servers). – Jesse P. Mar 7 '19 at 0:51

This answer by Cisco that "we don;t support it because it is a security device" is fairly poor.

The Device, if it's a good security device, could easily have this implemented as a passive-only feature if they are concerned about it.

IN FACT: The ASA already receives all of the CDP/LLDP packets from it's neighbors, it just doesn't respond to them and has no ability to show their info to you directly.

However you can still use the ASA to Capture the broadcasts coming to it, and then use wireshark to see their content to know what the neighbors are.

Whether you do that manually or they implement it as a feature to passively report on them, there is no information given to the other hosts about the existence of the ASA.

That said, security through obscurity is anything but.

We have about 23 ASAs give or take in our environment and they're good, but some of the official word from cisco why things are the way they are "for security" is more than a bit disingenuous.

For instance:

They STILl do not support Secure Renegotiation, they used to but a bug was found 5+ years ago, and their oficial solution was to remove this security feature instead of fixing the bug.

When we have audits we have to explain this.

They also fully support these protocols out of the box which is great:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS 128

However if you enable the free license of Anyconnect they provide you, then they purposefully drop the supported Encryption without warning, and the handshake to many new browsers doesn't correctly support Forward secrecy when connecting using them.

  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits FS
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits FS

Furthermore ASDM doesn;t support Forward Secrecy at all (at least as of 7.8.11) so to use ASDM to manage their firewall, they seem to require you to leave this enabled (as all other options are worse #DES/RC4 etc):

  • TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) WEAK

And to be clear the RA Anyconnect Client software does not change I use the same client to connect to a system with a "free"license as I do to one where the free license is disabled.

Now, you might be thinking well they only want you to use good TLS security with the paid license because they had to code to support the better TLS protocols.

Well then limit us to IPSEC VPN tunnels, since we already use those, since they are more secret then the HTTPS protocols you do allow on the free license.

In that scenario it's only the external web page which users access to log in and download the client initially which is being compromised by this.

So it actually makes us more vulnerable on the ASA and not on our RA VPN connections themselves, which might have been what they were trying to do?

Regardless this is clearly a "Go To" answer for them if they can make more money by not implementing a feature, or fixing a bug, or trying to force you to purchase another license after having sold you a product with an intentional flaw in the feature you were specifically selling us "includes 750 free RA VPN licenses, no need to buy premium if you don't need to put a Firewall on the end user"

Okay I am getting a little grip-y here.

The long and short of it is there is a way to get this info if you need it, but it takes a lot of work to get at it so you'd only bother if you REALLy needed to get it that way.

Another way to get some of the info you want, from the switch side (find your firewalls) which I like to use is to change the MAC address of your Firewall to be something you can easily find (especially for our clusters) and make sure you make them in such a way which tells you their interface, which makes it a snap to find them by using sh mac add and sh ip arp on the switches.

Yes CDP would be better, and like I said you can get it if you need it, but only fro the firewall side.

And yes, most of the info the info LLDP/CDP provide can be determined through a bunch of work, and if you were a security threat, you might be interested in getting some of that info, although some would be useless, but you could absolutely find it through some muscle work on your own, and a hacker, they're gonna have time, they're gonna do that anyway, everyone makes the argument about not making it easier for them but look if they are going to open all of your kitchen drawers anyway, having a label that says "spoons" on one and "Plates" on another isn't a realistic problem.

And even assuming the broadcast of this info was dreaming to be coming from the ASA, they could still change the devices capture and report it so you could see it's neighbors, which are probably all switches YOU control and run CDP on and see other things the ASA can not, like the ISP router.


On most Cisco equipment you say

show cdp neighbor

But my undestanding is that ASA devices don't do CDP.


I believe you can look at the learned ether address tables in SNMP, but it's hard work in comparison.

  • Or show lldp neighbor if LLDP is enabled (which it isn't by default on Cisco equipment). And, yes, you're correct that ASAs do not support CDP (or LLDP). They also don't have SSH or Telnet clients for the same reason: security. If the device is compromised the attacker is more limited in what they could do next to further penetrate the network. – Jesse P. Mar 7 '19 at 0:50
  • If your ASA is compromised they already own the network, there is nothing that owning the ASA itself would prevent them from doing that would be more than a minor speed bump versus having that feature on the device. (CDP/LLDP/SSH client) Consider that the ASA allows SCP and SFTP commands to be sent from it alreay which means you can still log into any Scp server and grab whatever you want, and that CDP/LLDP packets are easily captured by the ASA and reviewed in Wireshark. and an attacker would be prepped to do these things while for an admin they're a pain. – Ben Personick Mar 7 '19 at 6:29
  • @BenPersonick That is not true. Just because a firewall has been penetrated does not imply that the rest of the network has, too. Also, there may be more than just one perimeter device just for that sort of risk (a firewall that leads to another firewall, for example). Also, having SCP or SSH (or other types of clients) and access to the firewall doesn't imply that traffic would be permitted further up/down-stream. Not allowing CDP and LLDP is to prevent someone from seeing an exact model of neighboring devices to then be able to look for exploits pertaining to that specific model, or such. – Jesse P. Mar 7 '19 at 14:54
  • Many organizations also use different brands of equipment to help mitigate exploits of one brand so they don't automatically apply to other gear. For example, Cisco firewalls on the WAN edge but Juniper firewalls on the LAN edge. – Jesse P. Mar 7 '19 at 14:57
  • Yes, but you chose to do that for security as appropriate, not because the features didn't exist on the devices. CDP and LLDP can be configured to listen only and on a per-interface basis Furthermore as I stated in my full answer if you if the next hop down the line is running LLDP or CDP on the next device down the packets are still being received by the ASA and can easily be captured and reviewed causing more headache for the admin to do on a rare occasion than a malicious party who would be prepped to do so if they wanted that info. – Ben Personick Mar 11 '19 at 12:49

The ASA is a security device, so it was designed to communicate with untrusted devices. That means it doesn't send or receive any more information than necessary. So things like CDP are not available.

Generally, the only information on a neighboring device you can get is the MAC addres, via arp.

show arp

will list all the MAC addresses the ASA has recently communicated with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.