Did you know that you can easily decrypt TLS (mostly HTTPS) traffic with Wireshark? Well, only if you have the keys. ;) This really is a game-changer if you’re stuck with troubleshooting encrypted data. Let’s do an example:
Did you know that you can easily decrypt TLS (mostly HTTPS) traffic with Wireshark? Well, only if you have the keys. ;) This really is a game-changer if you’re stuck with troubleshooting encrypted data. Let’s do an example:
After years of customers confusing Fortinet with Fortnite, the two companies finally decided to lean into the chaos. The result: FortiNite — a joint innovation designed to deliver “next‑gen latency acceleration” for Fortnite players worldwide, a groundbreaking collaboration with Epic Games’ Fortnite.
Continue reading Introducing FortiNite: Fortinet’s Low‑Latency Power‑Up for Fortnite
You never stop learning. One topic that hadn’t crossed my path in the past decade is: Multicast. Whew. Alongside all the technical literature, online presentations, and various blog posts, I decided to approach it the classic way – through packet captures. ;)
So here’s a new part of the #UltimatePCAP, which contains quite a bit of PIM traffic, including Hello, Join/Prune, Register (via unicast!), and more. Of course, for IPv6 and legacy IP (IPv4). Let’s have a look:
Continue reading Protocol Independent Multicast (PIM) Capture
A rare use case on a Palo (at least from my point of view): Multicast Routing. And it can become as complex as you want. Fortunately, the basics are relatively easy to configure, at least if you have a rough understanding of multicast and routing with PIM and IGMP. (Recommended YouTube session here.) Let’s have a look at the common configuration steps on PAN-OS, the needed security policies to the special destination zone type of “multicast”, as well as some “show” outputs that can be used for troubleshooting:
The other day, I was troubleshooting some network-related stuff, using the built-in Packet Capture on a Palo Alto Networks firewall. And while it did the job at a first glance, I stumbled upon some packets that were simply not correct, read: were not present on the Ethernet cable at all and/or were missing some content.
I had a hard time figuring out how to configure OSPFv3 authentication on a Palo Alto Networks NGFW due to its different configuration formats compared to a Cisco router.
TL;DR: The SPI must be set in hexadecimal, while the actual key (40 chars, hexadecimal) must be grouped in 5 sections, separated with hyphens.
Continue reading OSPFv3 Authentication on a Palo Alto (Logical Router)
This post guides through a basic DNS tunneling setup with the usage of the appropriate tool “iodine“. It shows how DNS tunneling works and lists the commands needed to run this type of attack. That is, you can tunnel IPv4 packets through this DNS channel via the (internal) recursive DNS resolver! Nice approach. ;)
In the end, I’m pointing out how to block these tunnelling attempts with the DNS appliances from Infoblox, and the firewalls from Palo Alto Networks and Fortinet.
On the Internet, it’s not only “always DNS” – it’s also about securing DNS. DNS faces a wide range of attack vectors, each requiring different defensive strategies. Here comes an overview of DNS security, which gives you all the keywords at a glance.
I was presenting at the annual “Wireshark Developer and User Conference“, the SharkFest’25 EU, talking about “Securing DNS – Attacks and Defences“. It covered all the buzzwords related to DNS security, such as malware using DNS, DNS spoofing, DNS exfiltration & tunnelling, while defending them with the keywords as DNSSEC, DoH/DoT, feeds & blocklists, and so on.
Quite many techniques. ;) Luckily, the whole session was recorded. So if you’re interested, have a look!
While I was working on my presentation about “Secure DNS” for this year’s SharkFest, the Wireshark Developer and User Conference, I recognised that I’m still missing some DNS-related packet captures in the Ultimate PCAP, that is DNS over TLS and DNS over HTTPS. And while working on it with the DNSDiag toolkit (thanks, Babak!), I came across DNS over QUIC and DNS over HTTP/3. 😂 Here we go:
The other day, I was troubleshooting an issue where users reported that “some websites are working while some are not“. Uh. This is almost the worst scenario to face from a networker’s perspective. It’s way easier if things do or don’t work at all, but not this “some don’t” situation.
The scenario: Using Zscaler for outbound Internet connections, connected via a GRE tunnel from a Palo Alto Networks firewall. TL;DR: If it’s not DNS, it’s MTU. 😂 The “Suppress ICMP Frag Needed” option within the ICMP Drop section of the Zone Protection Profile did what it is meant to do: block “ICMP fragmentation needed” messages. Unfortunately, this killed *some* sessions which had the “Don’t fragment” bit set but exceeded the (lower) MTU of the GRE tunnel.
Continue reading It was MTU! Zscaler over GRE behind Palo, blocking ICMP Frag Needed
This goes out to anyone who uses more than one Site-to-Site VPN tunnel between two locations that are secured by firewalls from Palo Alto Networks. Using two (or even more) VPN tunnels, you need an automatic way to failover the traffic flow from one VPN to the other in case of failures. Here’s how to accomplish that requirement:
It’s really just a small thing, but very practical for me: In Wireshark, a feature request I submitted has been implemented. Now, when you click on an ICMP error, the corresponding (original) packet is highlighted.
Previously, clicking on a packet belonging to a flow would show all related packets, including any ICMP errors. However, if you selected an ICMP error packet itself, nothing happened. If you had many ICMP errors from different sessions, you had to go through the cumbersome process of figuring out which sessions they actually belonged to.
Now, you can simply scroll through the packet list as usual and immediately see whether related packets are present — and if so, which ones. Very handy.
Continue reading Wireshark Feature Added: Connecting ICMP Errors
Die Fehlersuche in IP-Netzwerken fällt nicht leicht, denn einem Netzwerkschluckauf können viele Ursachen zugrunde liegen. Profi-Admins kennen aber Wege, um das klassische und meist aufwendige Troubleshooting abzukürzen. Beispielsweise kann man Fehlerquellen anhand von ICMP-Rückmeldungen der Netzwerkgeräte eingrenzen, die an einem fehlgeschlagenen IP-Dialog beteiligt sind. Welche Meldungen das sind und wie man sie interpretiert, haben wir hier ausführlich beschrieben.
Am Ende dieses Beitrags haben wir vier Netzwerkanalyse-Aufgaben gestellt. Die Grundlage dafür bildet ein Verkehrsmitschnitt, den man mit dem Analysetool Wireshark öffnet und mit einem Display-Filter siebt. Hier folgen die Antworten zu den Aufgaben.
Continue reading Quizauflösung: Fehlersuche mittels ICMP-Rückmeldungen
Sie sind Admin und Ihr Netz kränkelt. Wo fangen Sie an mit der Fehlersuche? Unser Tipp: Tasten Sie Ihre Netzwerkpatienten mal nach ICMP-Symptomen ab. Viele führen direkt zur Ursache.
Wenn man Netzwerkschluckauf behandeln muss, gilt Wireshark als eines der Lieblingswerkzeuge von Netzwerkadmins. Denn falsch angestöpselten oder fehlkonfigurierten Servern kommt man oft schon anhand eines Netzwerkmitschnitts auf die Spur und erspart sich so den Adminzugriff auf Abteilungsrouter oder -switches. Als behandelnder Admin müssen Sie das aufgefangene Paketkonfetti nur noch mit einem geeigneten Display-Filter sieben, um jene Paketsorte im Kescher zu behalten, die Fehlerhinweise gratis unter Ihre wissenden Augen bringt: die ICMP-Päckchen.
Continue reading ICMP-Meldungen zur Fehlersuche im Netz einspannen