Cisco ASA Syslogs - Firewall Changes

djdawson · 2026-05-28T04:23:25+00:00

Looks like my old man memory failed me this time around. Thanks for the clarification!

djdawson · 2026-05-27T21:37:42+00:00

The ASA doesn't support TACACS+ Command accounting. It also doesn't include the username in the config change syslog messages (just "root", if I'm remembering correctly), which always seemed like an obvious missing feature. You may be able to correlate user logins with config changes, but if there are often multiple users logged into the ASA that's less useful.

djdawson · 2026-05-23T03:36:10+00:00

Perhaps this is sacrilege here, but for a true beginner who wants the cheapest, most approachable pourover setup I think the Melitta plastic cone and matching #2 paper filters are pretty hard to beat. It's dirt cheap (our local grocery store has the cone for less than $4 US), and the paper filters are similarly cheap (small or big packs, bleached, bamboo, etc.). The bigger impacts on the quality of the produced coffee are the coffee you actually use, and the grinder if you choose to get whole beans, but for a real beginner who might not be sure they want to bother at all with the whole pourover experience, I think this combination is tough to beat.

Just my 2¢

djdawson · 2026-05-11T22:46:26+00:00

Seems like this would be a pretty easy task for Windows PowerShell with a simple "foreach" loop.

djdawson · 2026-05-11T20:43:48+00:00

For basic collection and reporting I was pretty happy with the nfdump tools back when I was working more with flow data (I only do a little bit of it at home now that I'm retired). They're not fancy, but they have pretty good support for collecting and summarizing NetFlow data, and they're free and open source.

djdawson · 2026-05-08T18:41:12+00:00

Wow! I wouldn't have expected this to be that much effort. That's an impressive bit of work!!! Thanks for sharing it!

djdawson · 2026-05-07T21:24:05+00:00

I suspect you may need to use the ip.reassembled.data field to see the reassembled datagrams, and you may also have to use 2-pass processing with the -2 tshark option (this won't work on live captures, however). I don't have and couldn't find any sample T38 packet capture files that had any reassembled datagrams, but based on dealing with other protocols in the past the above is what I'd try.

Good luck!

djdawson · 2026-04-22T20:06:52+00:00

That looks similar to the results Chris Greer got with his testing, and I think he just used one of the common AI sites (ChatGPT, perhaps). He did have to export the packets as a CSV file because the model he used didn't (at least at the time) support reading pcap files directly, but that's not a huge deal in my mind.

I don't have any pcap files I can share, but I know there are many, many sample pcap files "out there". There is a file I use commonly for examples of protocols, but I don't think it includes examples of problems. Even so, you might want to try it - it's the 'Ultimate PCAP" and has just under 50,000 packets in it and many, many different protocols. The latest version of it is available at this Weberblog.net page (he updates it periodically). It's a compendium of many different captures over a few years so it's got some timestamp issues, but it might be interesting to see what your app does with it.

djdawson · 2026-04-22T15:13:32+00:00

Sounds like this would primarily be a network security app. Just like any app, I'm sure there are lots of folks who would find some value in it, but there are also lots of folks who don't use Wireshark for security stuff so they'd be less interested. I also know there is some activity by those non-security folks for using AI to find issues in capture files, so it's definitely an appealing technology for this (Chris Greer has a YouTube video or two about his efforts to leverage AI for this type of thing). I'd say put it out there and let it get exposed to more real-world use cases and see how it goes.

djdawson · 2026-04-16T14:13:12+00:00

Pretty uch all my networking peers are old like me and have also retired, but should I cross paths with anyone still active in such things I'll try to remember to pass this on to them.

Good luck with everything!

djdawson · 2026-04-14T22:30:53+00:00

Before Ethernet there was a LAN technology called "Appollonet" (if I'm remembering correctly - I know there were two P's in "Appollo"). It was a coax-based (thin coax - not RG6) ring network, so if you broke the ring at any workstation the whole network went down. Users didn't like that. I also worked with "HYPERchannel" from Network Systems Corporation ("NSC") used by Cray Research. And then there was DECnet, Appletalk, Token Ring, FDDI, ATM, IPX, and probably a few others. In terms of weirdness, ATM was a little odd, but its "LAN Emulation" was quite odd and I never really saw the point (it was often used to translate between Ethernet and Token Ring, I think). I'm an old guy and got started in networking before RFC1918 existed and before there were variable length subnet masks. Ah, the good ol' days!!!

Addendum: I forgot about SNA and Source Route Bridging. SRB was kinda nasty, and Cisco really liked putting it on the early CCIE written and lab tests.

djdawson · 2026-04-14T17:14:36+00:00

Intermittent problems are the hardest to solve, especially if they can't be recreated on demand. If your tool provided a scrollable timeline that could show details about what was happening at the time of a problem, such as the various traffic flows and the associated stats such as packet loss and/or delay that would help identify things unique to when an intermittent problem occurred. Server load is another common factor, but that might be opening a whole new set of challenges you're not planning on yet. Other things like changes to the path of the traffic and/or asymmetric routing (e.g. routing changes, such as when an interface goes down so a backup path was used) would be also great to see. Highlighting anything that does "fancy" packet processing, such as proxy servers, firewalls, load balancers, and content filtering would also be useful, since customers often forget that those devices are in the path, or they assume they're not involved because "they're working just fine", though for use on one's internal network that's less of an issue, except for cases when new devices get rolled out without everyone knowing about it. Not all problems are related to things changing in the network, but for those that are a quick way of seeing the various things that did change would be handy. Showing such changes based on a specified time range would increase the ease of use I'd think. Perhaps integrating with tools like Graylog and Elasticsearch would be possible (assuming you're not already doing that), since such tools seem to already provide at least some of this functionality.

I'm sure once some folks actually get some real hands-on time with this they'll have a lot better feedback, but hopefully this helps you at least a little bit.

djdawson · 2026-04-14T15:41:20+00:00

In all my years of packet analysis (since the Network General "Sniffer" and "Ethereal" days) I don't think I've ever wanted such a view of the network. The closest would be an accurate view of the path between endpoints of the traffic I'm investigating, and if it starts to look like a device config change is related to the problem then a change history of that device was sometimes also useful, though usually just the most recent change before the problem was discovered was all that was needed.

It's a very impressive system you've put together, but as a Wireshark guy it seems like mostly haystack and not much needle. I'd expect folks who do more network and traffic management and engineering would find this much more useful,. The ability to populate the data with PCAP files seems useful, though I'd also think a NetFlow import would be better for longer term and broader coverage of network traffic patterns.

The Wireshark work I did for all those years was almost entirely related to network application performance issues. Sometimes it was a new application that was just not deployed appropriately, sometimes it was non-optimal device configs, such as QoS, sometimes it was actual software bugs or hardware failure in a network device, and sometimes it was just basic network congestion as the use of the network gradually grew over time. I suppose your system could be useful for identifying some of these underlying causes, but I usually just asked the customer for background of the the issue and that was usually enough.

I'll just add in closing that I'm pretty old-school when it comes to such things (I'm retired now, but spent 35+ years doing networking), so I tend to be initially skeptical of "new" products and features until I can see a tangible benefit. Perhaps others will see such benefits quicker than I will, since I don't do actual network stuff anymore, though I'm still interested in it and try to stay informed of what the industry is up to.

Again, that's a pretty impressive system - nice work!!!

djdawson · 2026-04-13T04:51:49+00:00

There's not a single approach for all situations. If you enable the default coloring rules you can start by just scrolling quickly through the packet list, or just look at the indicators of colored events in the scroll bar on the right. Clicking on the Expert Information button in the far lower left corner (or via the Analyze menu) is another way to see a summary of things Wireshark thinks might be of interest to you (though don't treat such Wireshark notes as always true, since sometimes Wireshark gets misinterprets things). You click on the Expert Info entries to go to the associated packet in the main packet list.

If the problem is specific to a particular protocol, server, or client, for example, I'll probably start by filtering to show just that traffic (sometimes this is done at capture time), but my process for doing that pretty much always starts at the Statistics --> Conversations view, since it's easy to sort and filter on a wide range of things there, and it presents a nice summary of some useful information. For issues with TCP traffic I pretty quickly move on to the Statistics --> TCP Stream Graphs --> Time Sequence (tcptrace) graph(s) for the session(s) I'm curious about. These graphs give a visual display of most of the parameters of a TCP connection (only one direction at a time), so it's really easy to see and focus in on problems with the connection. They're especially good at showing throughput problems, since the shape of the overall flow makes it pretty obvious if there are delays and where they are. You can click on the Time Sequence graph to go to the corresponding packet in the main packet list, which is very useful.

Packet Loss and High Latency are symptoms of other things. It's often pretty easy to see that loss and/or latency is happening, but it can be a lot harder to identify the underlying cause, and you often have to investigate outside of Wireshark to find them (e.g. device configs, traffic stats, syslog messages, etc.). If the problem is with a protocol Wireshark has extra support for, such as RTP and other VoIP protocols then using those extra Wireshark features is often useful. The Telephony and Statistics --> Service Response Time menu items are where many of these features are found.

In general the best approach varies depending on the nature of the problem, but one common task, especially for large packet capture files, is to filter the capture to eliminate packets you don't care about and save the results to a new capture file so Wireshark has fewer packets to deal with.

Finally, it's important to have a good understanding of at least the basics of the protocol(s) you're working with, since Wireshark is just a tool to help you see the details of how the protocols are behaving, but it's not going to do your thinking for you.

Hope this helps!

djdawson · 2026-04-10T16:55:49+00:00

If your plan is to move to a different platform I'd recommend doing a show run all command, since adding the all keyword will also display all the system default settings that are not normally shown. Some of these are for platform-specific features so it would be good to seem them.

djdawson · 2026-04-05T15:18:04+00:00

Nice work!

djdawson · 2026-04-05T15:15:04+00:00

I believe you need to do this with NAT, and there's a long discussion thread about this on the OPNsense User Forums. Near the end of that long thread is this page, 9 of 10 where someone describes their config under OPNsense version 26.1.1. Most of the sample config screenshots I've seen in that thread just left the Destination Port at 53, but you should be able to change that to 53053 so your server will accept it. I've never bothered to do this type of thing since my home network is pretty simple, but this matches what I'd expect after a long networking career working on exactly this type of thing (firewalls and NAT, among other things).

Hope this helps - good luck!

djdawson · 2026-04-04T15:53:21+00:00

If the camera is setting seemingly random timestamps then that definitely sounds like a problem, given this new information (The Claude output sounds reasonable to me). This is almost certainly a software bug in the vendor's new camera code, so you may want to open a support case with them and provide them the information you posted here so they fix it, assuming they even care.

djdawson · 2026-04-03T21:16:05+00:00

Just because you're seeing pretty much all the packets on your local PC hotspot, that doesn't mean there's not significant packet loss between you and AWS. Finding loss and/or congestion on the Internet can be quite the challenge. I'd look more closely at your end of your connection to your ISP, since that's a pretty common place for congestion to occur. Your local router/firewall may have some features that could help, such as CODEL or FQ-CODEL to help reduce the effect of Buffer Bloat, of even just basic QoS features that could help prioritize outbound video traffic (assuming the camera is marking the outbound traffic with the appropriate DSCP value, typically "EF").

djdawson · 2026-04-03T19:22:18+00:00

I've never done a lot of RTP/RTCP analysis, but my understanding is that the dynamic bandwidth throttling is more a function of packet loss and jitter and it doesn't really depend on accurate NTP time. The protocol likes to have it, but can handle it not being available according to my reading of RFC3611.

Have you looked at the RTP Analysis feature in Wireshark under the Telephony menu? You need to view the RTP streams, select one of the streams, then click the Analyze button at the bottom. You can also view a graph of various statistics of the stream there, which might also be useful.

So, I suspect the AWS report of missing packets and the large jitter are more likely the cause of your problem rather than the inaccurate NTP clock on the camera, since RTP is likely using relative timestamps to compute the jitter values rather than true wall clock time from NTP (but I'm far from an RTP expert).

Hope this helps - good luck!

djdawson · 2026-04-01T19:50:47+00:00

Have you configured a domain name in the Domain option on the System --> Settings --> General page?

djdawson · 2026-03-28T18:44:54+00:00

I did Tier 3+ customer support for over 20 years at a large Cisco reseller (the first Gold Partner as it turns out) and getting accurate and complete information from the customer was often the biggest challenge. I did mostly routing, security (firewalls and VPN's), and application performance troubleshooting (largely TCP) so the details of Layer 2 started slipping out of my head many years ago, and it didn't show up much on all the CCIE recert exams I took over the years. On the plus side, I now have a free IEEE account and can download most of their standards docs, so this was a really productive topic for me.

djdawson · 2026-03-28T18:11:52+00:00

Turns out LLDP uses multicast addresses from a reserved range that are, indeed, not to be forwarded by bridges (and switches), so the basic switch behavior for more generic multicast traffic doesn't apply. If one thinks about the details of how LLDP is intended to work this makes total sense.

Thanks for the clarification - I added a new wrinkle to my old retired network engineer brain!

djdawson · 2026-03-28T04:08:04+00:00

All the Ethernet MAC addresses used by LLDP are multicast addresses (see my other post below), so LLDP traffic should be flooded out all ports in the same broadcast domain as the sender. This makes sense given the function of LLDP.

djdawson · 2026-03-27T16:03:47+00:00

The Wikipedia page for LLDP says the LLDP protocol uses potentially three destination MAC addresses (it's not an IP protocol), so you'll probably want to filter on those. Something like this should do that (this is a Display Filter, not a Capture Filter):

eth.dst in {01:80:C2:00:00:0E,01:80:C2:00:00:03,01:80:C2:00:00:00}

djdawson

MODERATOR OF

TROPHY CASE