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
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
The Network Time Protocol (NTP) is widely used to synchronize computer clocks. The Precision Time Protocol (PTP) can be used as a time source as well, which is expected to be accurate within microseconds. However, at Microsoft Azure VMs, PTP-derived time-of-day errors could exceed 50,000 microseconds, which may be inadequate. Let’s go into some details:
I just got a few emails from an administrator of a medium-sized company, asking some IPv6 questions. They want to use IPv6 to reach the Internet, using two ISPs, while remaining IPv4-only on their internal networks. For whatever reason, they came across three different ideas that were almost completely wrong, speaking of a sound IPv6 design. But why? Maybe because IPv4 thinking is a bigger problem than we ever thought? Or because admins rely on firewall vendors (like Fortinet) that suggest completely wrong network approaches?
Let’s dig into some misconceptions concerning IPv6:
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.
You can use a FortiGate to connect to the Internet (that is: Dual-Stack!) directly in various ways. In my current setup, I’m using a PPPoE residential xDLS connection. It’s not that easy to configure everything correctly since it requires the use of many different protocols such as PPPoE and PPPoEv6 (PPP IPV6CP) along with DHCPv6-PD. But here it is:
I got DHCPv6-PD aka prefix delegation up and running on a FortiGate. Yes! ✅ Configuring it is tricky since it’s not always clear which options to use. You cannot see everything in the GUI (it even changes depending on other options made later on or selects hidden and wrong default values), hence, you must set specific options via the CLI. I navigated around some bugs and finally got it running. Here we go:
Continue reading DHCPv6 Prefix Delegation on a FortiGate Firewall