Category Archives: ICMP/ICMPv6

It was MTU! Zscaler over GRE behind Palo, blocking ICMP Frag Needed

ICMP/ICMPv6, Palo Alto Networks, , , , , , , ,

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 →

Wireshark Feature Added: Connecting ICMP Errors

ICMP/ICMPv6, Wireshark, , , ,

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 →

Quizauflösung: Fehlersuche mittels ICMP-Rückmeldungen

ICMP/ICMPv6, , , , , , , ,

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 →

ICMP-Meldungen zur Fehlersuche im Netz einspannen

ICMP/ICMPv6, Internet Access, Routing, , , , , , , , , , , ,

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 →

ICMP ‘Destination Unreachable’ Messages @ SharkFest’24 EU

Conference Talks, ICMP/ICMPv6, Internet Access, , , , , , ,

I did a presentation at SharkFest’24 EU in Vienna, the “Wireshark Developer and User Conference“, about the topic: “Unveiling Network Errors – A Deep Dive into ICMP ‘Destination Unreachable’ Messages“. It covers the following:

“Effective troubleshooting of network issues is a critical concern for network technicians. While many are familiar with basic ICMP tools like ping and traceroute, the breadth of ICMP capabilities often goes underutilised. This session delves into ICMP messages, specifically the ‘Destination Unreachable’ type, and the insights they provide into network errors.

We will explore methods for capturing and analysing network traffic, highlighting practical tips and tricks for using Wireshark to diagnose and resolve issues efficiently. Attendees will gain a deeper understanding of ICMP message functions and how to leverage them for improved network troubleshooting.”

You can watch the whole session and download the slides. And you can do the six challenges at the end of the session as well. (The answers are not in the PDF, but shown in the video.)

Continue reading ICMP ‘Destination Unreachable’ Messages @ SharkFest’24 EU →

Path MTU Discovery

ICMP/ICMPv6, Internet Access, Routing, , , , , , ,

One of the mysteries for me in IP networks was the Path MTU Discovery (PMTUD) process. I’ve seldom seen any problems with the MTU at all. Fortunately, while troubleshooting some router issues, I captured several ICMP “packet too big” errors along with the original packets. 👍🏻

Let’s have a look at those PMTUD processes for IPv6 and legacy IP with Wireshark. Of course, these captured connections are part of the Ultimate PCAP as well, hence, you can download the most current version of it and analyze it by yourself.

Continue reading Path MTU Discovery →

Who sends TCP RSTs?

Design/Policy, ICMP/ICMPv6, Security, , , , , , , , , ,

At SharkFest’22 EU, the Annual Wireshark User and Developer Conference, I attended a beginners’ course called “Network Troubleshooting from Scratch”, taught by the great Jasper Bongertz. In the end, we had some high-level discussions concerning various things, one of them was the insight that TCP RSTs are not only sent from a server in case the port is closed, but are also commonly sent (aka spoofed) from firewalls in case a security policy denies the connection. Key question: Can you distinguish between those spoofed vs. real TCP RSTs? Initially, I thought: no, you can’t, cause the firewalls out there do a great job.

It turned out: you can!

Continue reading Who sends TCP RSTs? →

Advanced Tracerouting

ICMP/ICMPv6, Memorandum, Ping/Traceroute, Routing, Security, , , , , , , , , , ,

A common misunderstanding of traceroute is that it fully relies on ping. “If I block ping at my firewall, no one can use traceroute to reveal my internal routing path”. Unfortunately, this is not true. If traceroute is used with TCP SYN packets on permitted TCP/UDP ports, all intermediary firewalls will handle the IP packets with TTL = 0 corresponding to the RFCs and will reply with an ICMP time exceeded packet to the source.

In this post, I am listing an example that uses traceroute with TCP port 25 (SMTP) to traverse a firewall. A sample pcap file can be downloaded while some Wireshark screenshots show a few details.

Continue reading Advanced Tracerouting →

Why Ping is no Security Flaw! (But your Friend)

Design/Policy, ICMP/ICMPv6, Ping/Traceroute, Security, , , , , , , , ,

One core topic when designing firewall policies is the following question: Is ping a security attack? Should ICMP echo-request messages be blocked in almost any directions?

My short answer: Ping is your friend. :) You won’t block hackers if you block ping. Instead, ping is quite useful for network administrators checking basic network connectivity. That is: I suggest allowing ping anywhere around, accept incoming connections from the Internet to the trusted networks.

Here comes a discussion:

Continue reading Why Ping is no Security Flaw! (But your Friend) →