Network Encryption with MACsec: Basics & Cases

Security, Switching, , , , , , , , , ,

Modern networks are not only threatened by external attacks but are increasingly exposed to internal risks as well. These include unauthorized physical access to network components or manipulated data streams within the LAN. Classic Network Access Control (NAC) based on IEEE 802.1X-2004 often only provides one-time authentication but does not ensure continuous protection of transmitted packets. For companies and authorities requiring higher security standards, this gap becomes a risk factor.

This is where MACsec (Media Access Control Security) comes into play. The protocol encrypts and verifies the integrity of data at Layer 2, directly at the point of entry into the network. Thus, it protects not only against external attacks but also against internal manipulations and unauthorized access to sensitive communication paths.

Continue reading Network Encryption with MACsec: Basics & Cases →

Packet Capture of a Post-Quantum Site-to-Site VPN

IPsec/VPN, Post-Quantum (PQC), , , , , , , ,

After using several post-quantum secure VPN tunnels (here and there), I was interested in how this key exchange with ML-KEM looks on the wire. Especially in direct comparison to a classical VPN setup with just ECDH (group 21). Spoiler: since it does not fit in a single packet, it has to use a new form of fragmentation. 😳 Here we go:

Continue reading Packet Capture of a Post-Quantum Site-to-Site VPN →

PQC VPN-Tunnel between Palo Alto <-> FortiGate

Fortinet, IPsec/VPN, Palo Alto Networks, Post-Quantum (PQC), , , , , ,

Since we have learned the basics of post-quantum secure VPN tunnels, let’s configure a site-to-site VPN between a Palo Alto Networks firewall and a FortiGate with PQC ciphers to verify vendor interoperability. Spoiler: it works like a charm. ;)

Continue reading PQC VPN-Tunnel between Palo Alto <-> FortiGate →

PQC VPN-Tunnel with Palo

IPsec/VPN, Palo Alto Networks, Post-Quantum (PQC), , , , , ,

As the advent of practical quantum computing draws closer, security vendors are increasingly introducing post-quantum cryptographic (PQC) algorithms to protect existing security architectures against future threats. One important use case is site-to-site VPN connectivity, where organisations must address the “harvest now, decrypt later” risk – the possibility that encrypted traffic captured today could be decrypted by quantum computers in the future.

To mitigate this threat, Palo Alto Networks has implemented several approaches for quantum-resistant VPN tunnels, including Post-Quantum Preshared Keys (PPK), Key Encapsulation Mechanisms (KEM), and Quantum Key Distribution (QKD). Each method offers a different balance of security, complexity, and operational requirements.

In this blog post, we will examine these approaches in detail, with a particular focus on KEM-based solutions, which are generally considered the preferred path forward. We will also demonstrate how to configure a site-to-site VPN tunnel that combines traditional Diffie-Hellman (DH) key exchange with post-quantum algorithms such as Kyber (standardised by NIST as ML-KEM), providing both classical and quantum-resistant security.

Continue reading PQC VPN-Tunnel with Palo →

FortiGate Enables NAT for IPv6 by Default 🤦

Fortinet, IPv6, , , , , , ,

Fortinet has a misstep in its IPv6 settings: NAT66 is enabled by default for every policy. Not only does this make no technical sense and go against established best practices, but in my view, there’s an even bigger issue at play here:

Given the widespread use of FortiGate devices and the still limited level of IPv6 expertise among many administrators, this default setting risks creating false knowledge. Many admins may come away believing that NAT for IPv6 is just as normal as it is for IPv4 – after all, it’s enabled out of the box. And as with any default, people will quickly get used to it.

In this blog post, I’ll therefore look at a few practical workarounds to move away from this approach as quickly as possible.

Continue reading FortiGate Enables NAT for IPv6 by Default 🤦 →

Palo Alto Networks NGFW “SSL Inbound Inspection” with different Certificate

Certificate, Palo Alto Networks, , , ,

I had a use case where I wanted to use the SSL Inbound Inspection on a Palo, but with a different X.509 certificate than the one on the server itself. That is: the backend server has its self-signed (or internal PKI-signed) certificate along with its hostname, while the decryption policy on the Palo uses a publicly trusted signed certificate for the same hostname. Just like a reverse proxy / load balancer / WAF.

TL;DR: While it would be technically feasible, this configuration is not working. :(

Continue reading Palo Alto Networks NGFW “SSL Inbound Inspection” with different Certificate →

Basic IPv6 Messages (v2): Wireshark Captures

IPv6, Memorandum, , , , , , , , , , ,

In my IPv6 classes, I always teach the basic IPv6 messages as seen on the wire. There’s so much new stuff, such as Router Advertisements, Duplicate Address Detections, Neighbour Solicitations, and so on. Therefore, I’m using a rather simple packet capture showing the starting process of a client getting its addresses.

For the last 10 years, I used this capture, which I took on a Knoppix Linux along with a German Speedport router, in which SLAAC was used for getting the addresses. However, it turned out that in enterprise-grade networks, stateful DHCPv6 is used more commonly. Hence, I did it again and captured the very first IPv6 messages as seen on an IPv6 node, but this time on a Windows 11 PC and a Debian 13, along with stateful DHCPv6.

Continue reading Basic IPv6 Messages (v2): Wireshark Captures →

Introducing FortiNite: Fortinet’s Low‑Latency Power‑Up for Fortnite

Bandwidth/Delay, Fortinet, , , , ,

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 →

Protocol Independent Multicast (PIM) Capture

Routing, , , , , , , , , , ,

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 →

Multicast Routing w/ Palo

Palo Alto Networks, Routing, , ,

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:

Continue reading Multicast Routing w/ Palo →

Don’t Trust Packet Captures on Firewalls

Packet Capture, , , ,

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.

This proves again what the TAP vendors always claim: Don’t use internal packet captures / SPAN ports at all when you’re really serious about the truth. You MUST use network TAPs!

Continue reading Don’t Trust Packet Captures on Firewalls →

OSPFv3 Authentication on a Palo Alto (Logical Router)

Authentication, IPv6, Palo Alto Networks, Routing, , , , , ,

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) →

DNS Tunneling: iodine

DNS/DNSSEC, Security, Tutorial/Howto, , , , , , , , ,

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.

Continue reading DNS Tunneling: iodine →