The packet capture wizard in ASDM is a great feature of the ASA platform. It allows a network administrator to easily debug an issue and export the capture right to Wireshark from the wizard.
However, as you use this you may notice something. Where are my arp packets? Any time Wireshark is ran from a layer-2 network, arp packets will inevitably be captured. Something I didn’t know is that the ASDM wizard does not capture broadcast packets (at least at the time this was written ASA version 9.4(2) and ASDM 7.6).
Unfortunately Cisco doesn’t really describe this in any of their capture documentation, so if you don’t typically capture through the command line, you’ll never see broadcasts and may wonder what’s wrong.
How can I capture arp broadcasts on my ASA for troubleshooting layer-2 issues?
You have to do this through the ASA command line.
- Log in to the ASA you want to capture/see ARP packets.
- Use the ‘capture’ command with the ethernet-type arp
An example would be:
ASA# capture arp-cap ethernet-type arp interface inside
Where arp-cap is the name of your capture, the ethernet-type filters the capture to only arp packets and the interface picks the interface where you want to see the broadcasts.
You can define a ‘buffer’ flag if you want, but don’t worry about overloading your ASA, the default is 512kb. The above command is typically what you want.
Now we can execute a show command to see the capture buffer:
ASA# sh cap arp
81 packets captured
1: 13:21:17.283554 arp who-has 192.168.10.1 (cc:3:ca:f8:34:50) tell 192.168.10.21
2: 13:21:17.283630 arp reply 192.168.10.1 is-at cc:3:ca:f8:34:50
3: 13:21:18.600005 arp who-has 10.4.49.190 tell 192.168.10.1
4: 13:21:20.053692 arp who-has 192.168.10.1 (cc:3:ca:f8:34:50) tell 192.168.10.167
5: 13:21:20.053784 arp reply 192.168.10.1 is-at cc:3:ca:f8:34:50
6: 13:21:21.069271 arp who-has 10.4.49.182 tell 10.4.48.25
7: 13:21:21.998391 arp who-has 10.4.49.182 tell 10.4.48.25
We now see who is broadcasting for what, and what hardware address they reside on. Use the detail flag to see more information.
We’ve got what we need, so its time to clean up. It’s very simple:
ASA# no cap arp-cap
The documentation that F5 provides for configuring OCSP stapling is pretty sparse. I decided to write up this quick tutorial to supplement their documentation. What is presented below worked for me in my environment, but may not work in all.
Configure a DNS Resolver
- Click Network > DNS Resolvers
- Click Create… on the right side
- Name it whatever you wish, I called mine resolver.
- Leave the rest of the settings as the default.
- Click Finished
Configure Forward Zones
- Once your resolver is created, click its name from the Resolver List page.
- Click Forward Zones on the top tab area
- Click Add…
- In the name area put a period “.”
- Place the DNS servers that your F5 will use for lookups
- Click Finished
Import Certificate Chain
Depending on where the certificate was purchased used by your virtual-server, a chain must be created that matches the server-certificate.
Collect the intermediate certificate(s) related to your certificate from the CA. This will contain the URL the F5 will use to validate the certificate using OCSP.
- Click File Management > SSL Certificate List
- Click Import…
- I like to take the chain and paste it in as text, but you can import the chain however you like.
- Click Import
Create OCSP Profile
- Click Profiles > SSL > OCSP Stapling
- Click Add…
- Click the Advanced drop-down
- Pick a name that makes sense to you
- In the DNS Resolver section pick the resolver we made above
- Under Trusted CA and Trusted Responders pick the chain we created above
- I use Comodo certificates, so the settings beginning at Sign Hash and below that are highlighted in yellow were changed to match Comodo’s and F5’s recommendations. These may or may not work for you.
Create SSL Profile with OCSP Responder
- Go to Local Traffic > Profiles > SSL > Client
- Click Create…
- Name it whatever makes sense to you
- Pick the Certificate, Key and Chain that you have imported already.
- In the OCSP Stapling Parameters pick the profile we created in the previous step
- Click Add for each certificate the profile will provide.
- Optional – To create a more secure profile:
- Change your Ciphers to; ECDHE+AES-GCM:ECDHE+AES
- Disable Renegotiation
- Click Finished
There are a few ways to test your profile to see whether OCSP responses are being sent from your virtual-server or not. I prefer to run a capture but you can check using the tool at SSL-labs also.
- Capture a SSL handshake between you and the virtual server
- Go to the packet where the vs responds with the Certificate
- Drill down to the Certificate Status Record Layer
- Expand until you see OCSP response with a responseStatus of Successful (0)
- Run a test using SSL-Labs
- Go to https://www.ssllabs.com/ssltest/analyze.html and enter your domain if it is pubic
- Wait for the test to complete and check for the OCSP Stapling line and make sure it says Yes
- I like this site to check for potential issues with your configuration, save it and use it in the future if you don’t already.
Important Note about Default Route
Initially I had an issue with lookups and the OCSP status check using the OCSP Resolver profile I configured. I use Auto-Last Hop on our F5, so my configuration has no default route.
When you have no default route, the default behavior of the F5 is to perform DNS lookups and pull the OCSP status from the virtual-server(s) VLAN self-IP with the OCSP profile assigned to it. If you are firewalling and don’t have a rule permitting this, you may see that OCSP is not working.
As of this version (11.6.0 HF5), the F5 will not use the MGMT interface which typically has its own IP with a gateway. You must have a self-IP assigned elsewhere and configure a default route for it.
There are a few solutions to this:
- Add a default route for an interface you want to perform lookups (syslog, snmp interface, etc.) and allow that IP to perform DNS lookups and pull the OCSP status from the Internet. The self IP(s) of the F5 on this VLAN must have Internet access.
- Add ACL’s to allow each virtual-servers VLAN self-IP to perform DNS lookups and pull the OCSP status. These IPs will all require Internet access.
- Change the OCSP profile to use proxy to perform lookups and pull status.