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
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
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 🤦
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.
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:
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
It happens occasionally that a customer has to choose between a Palo and a Forti. While I would always favour the Palo for good reasons, I can understand that the Forti is chosen for cost savings, for example.
Fortunately, there is a hidden way of installing PAN-OS, the operating system from Palo Alto Networks, on FortiGate hardware firewalls. Here’s how you can do it:
Continue reading How to install Palo Alto’s PAN-OS on a FortiGate
Johannes published a basic NAT46 configuration for a Fortigate firewall with FortiOS 7.0 some time ago. I run such a service (legacy IPv4 access to IPv6-only resources) since FortiOS 5.6, which means more than six years; lastly with FortiOS 6.4. It’s running for more than 100 servers without any other problems as we see them with IPv4 only or dual stack services.
But we weren’t happy with the basic configuration example by Fortinet. We wanted some NAT46 sample configuration with more details, that is: including the original source IPv4 address within the synthesized/SNATted IPv6 address. More in this post, after a short story about my way to a running nat46 configuration with port forwarding in FortiOS 7.2.x.
Again two more commonly used network protocols for the Ultimate PCAP: the Remote Authentication Dial-In User Service (RADIUS) and the Terminal Access Controller Access-Control System Plus (TACACS+) protocols. Captured with quite some details:
In general, Network Address Translation (NAT) solves some problems but should be avoided wherever possible. It has nothing to do with security and is only a short-term solution on the way to IPv6. (Yes, I know, the last 20 years have proven that NAT is used everywhere every time. ?) This applies to all kinds of NATs for IPv4 (SNAT, DNAT, PAT) as well as for NPTv6 and NAT66.
However, there are two types of NATs that do not only change the network addresses but do a translation between the two Internet Protocols, that is IPv4 <-> IPv6 and vice versa. Let’s focus on NAT46 this time. In which situations is it used and why? Supplemented by a configuration guide for the FortiGates, a downloadable PCAP and Wireshark screenshots.
Continue reading Accessing IPv6-only Resources via Legacy IP: NAT46 on a FortiGate
During the last weeks, I had an interesting request to publish NTP servers to client systems by using DHCPv6 in an IPv6 only network. Our Fortigate (or me?) had to learn how to publish the information. Hence this post is not only about NTP and IPv6, but a small guide on how to walk through RFCs and how to get out the relevant information. I’m very happy I got the possibility to share my experience here. Thank you, Johannes!
As we have just set up a TLS capable syslog server, let’s configure a Fortinet FortiGate firewall to send syslog messages via an encrypted channel (TLS). Let’s go:
More than 6 years ago (!) I published a tutorial on how to set up an IPsec VPN tunnel between a FortiGate firewall and a Cisco ASA. As time flies by, ASA is now able to terminate route-based VPN tunnels (which is great!), we have IKEv2 running everywhere and enhanced security proposals. Hence, it’s time for an update:
Continue reading Route-Based VPN Tunnel FortiGate <-> Cisco ASA
The NTP Pool is a volunteer organization that provides time synchronization service to hundreds of millions of computers worldwide. A typical client might query a particular NTP Pool server ~10-60 times/hour. Wikipedia lists some abusive clients that far exceeded the normal rate. This wastes NTP server resources, may interfere with other clients, and can trigger DDoS protections. In late 2019, a software update made some FortiGate firewalls very unfriendly to the NTP Pool.
Continue reading FortiGate bug: firewalls sending excessive requests to the NTP Pool