Category Archives: Vendor/Device/OS

Misusing Palo’s Captive Portal as a Guest Wi-Fi Welcome Page

I was faced with an interesting customer requirement: An existing guest Wi-Fi should be prefaced with a welcome page for accepting the terms and conditions. Since there was already a Palo Alto Networks firewall in place, could we perhaps use its captive portal directly for this purpose? It’s not about authenticating the users, but only for a single webpage with a simple check button that should appear once a month per device.

TL;DR: While we were able to redirect every device to a welcome page, we were not able to extend the lifetime of those sessions to longer than 24 hours. This might fit for short-term guest Wi-Fis, but is not appropriate for long-term connections aka BYOD. However, this is how we have done it:

Continue reading Misusing Palo’s Captive Portal as a Guest Wi-Fi Welcome Page

Dynamic DNS on a Palo

With PAN-OS 9.0 (quite some time ago), Palo Alto Networks has added Dynamic DNS for a firewall’s interfaces. That is: If your Internet-facing WAN interface gets a dynamic IP address via DHCP or PPPoE (rather than statically configured), the firewall updates this IP address to a configured hostname. The well-known DynDNS providers such as Dyn (formerly DynDNS), No-IP, or FreeDNS Afraid are supported. Since the Palo supports DHCP, PPPoE (even on tagged subinterfaces) as well as DHCPv6 respectively PPPoEv6, we can now operate this type of firewall on residential ISP connections AND still access it via DNS hostnames. Great. Let’s have a look at the configuration steps.

Spoiler: The DynDNS feature on a Palo only supports static IPv6 addresses rather than dynamic ones. 🤦🤦🤦 Yes, you haven’t misread. The DYNAMIC DNS feature does not support DYNAMIC IP addresses, but only STATIC ones. D’oh!

Continue reading Dynamic DNS on a Palo

Palo’s Mgmt-Intf is not usable with IPv6 anymore

Wow, that was unexpected: With PAN-OS 11.1 the out-of-band management interface of Palo Alto Networks firewalls doesn’t accept an IPv6 default route pointing to one of its own data interfaces anymore. That is: In most setups, you can’t use IPv6 for management purposes anymore. “Works as expected.” Wow. Really?

Continue reading Palo’s Mgmt-Intf is not usable with IPv6 anymore

How to install Palo Alto’s PAN-OS on a FortiGate

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

Optimized NAT46 Config 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.

Continue reading Optimized NAT46 Config on a FortiGate

DHCPv6 Prefix Delegation on Palo Alto’s NGFW

Finally! With PAN-OS 11.0 a long missing IPv6 feature was introduced: DHCPv6-PD aka prefix delegation. For the first time, we can now operate a PAN-OS firewall directly on the Internet (the IPv6-Internet that is) on many kinds of ISP connections. Remember: To get a routed IPv6 prefix requires DHCPv6-PD (if you’re not a BGP-homed enterprise). Hence, without that feature, we could not connect to the Internet with a Palo directly.

With DHCPv6-PD, the firewall can receive a prefix from the ISP (commonly a /48 or a /56), while handing out /64s to downstream layer 3 interfaces. Here we go:

Continue reading DHCPv6 Prefix Delegation on Palo Alto’s NGFW

Contributing to Wireshark (without any coding skills!)

For many years I was afraid to open new issues for open-source tools since I am not a coder at all and won’t ever be able to fix some of the problems. Many times I got answers like “The source is open, go ahead and fix it yourself”. This brought me to a point where I simply stopped proposing new ideas and features.

This has changed since I was at SharkFest’22 EUROPE (the Wireshark Developer and User Conference), especially at a session from Uli Heilmeier called “Contribute to Wireshark – the low hanging fruits” [PDF].

TL;DR: You don’t need to be a programmer to contribute to Wireshark! E.g., submit new feature requests, report bugs or write at the wiki.

And that is exactly what I would like to recommend to you. This post is about giving examples, that even minor errors and thoughts are appreciated by the Wireshark team. But, of course, if you actually have coding skills, please go ahead and fix some of the issues. ;)

Continue reading Contributing to Wireshark (without any coding skills!)

Basic NTP Client Test on Windows: w32tm

When implementing NTP servers, it’s always an interesting part to check whether the server is “up and running” and reachable from the clients. While I’ve done many basic NTP checks out of Linux, I lacked a small docu to do this with Windows. It turned out that there’s no need for third-party software because Windows already includes a tool to test NTP connections: w32tm.

Continue reading Basic NTP Client Test on Windows: w32tm

Minor Palo Bug: ICMPv6 Errors sourced from Unspecified Address

During my IPv6 classes, I discovered a (minor) bug at the NGFW from Palo Alto Networks: ICMPv6 error messages, such as “time exceeded” (type 3) as a reply of traceroute, or “destination unreachable” (type 1) as a reply of a drop policy, are not correctly sourced from the IPv6 address of the data interface itself, but from the unspecified address “::”. Here are some details:

Continue reading Minor Palo Bug: ICMPv6 Errors sourced from Unspecified Address

Meinberg LTOS: “syslog-ng” and the Observed Implementation Pitfalls

Meinberg, with the great help of Mr Weber, has implemented “syslog over TLS” in the LTOS version 7.06. The following report describes the general advantages of “syslog over TLS” and the implementation of it in the LTOS.

Continue reading Meinberg LTOS: “syslog-ng” and the Observed Implementation Pitfalls

Palo Alto: Instant Commit

Finally! With PAN-OS 11.0 Palo Alto Networks introduced an “instant commit”. That is: You no longer have to commit (and wait and wait and wait) until your changes are live, but everything you do is IMMEDIATELY active. Just as on any other firewall, e.g., the Fortis.

Here is how you can enable it along with some use cases and drawbacks:

Continue reading Palo Alto: Instant Commit

Accessing IPv6-only Resources via Legacy IP: NAT46 on a FortiGate

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

Palo Packet Capture: Choosing the Right Filter

Palo Alto firewalls have a nice packet capture feature. It enables you to capture packets as they traverse the firewall. While you might be familiar with the four stages that the Palo can capture (firewall, drop, transmit, receive), it’s sometimes hard to set the correct filter – especially when it comes to NAT scenarios. (At least it was hard for me…)

I am using the packet capture feature very often for scenarios in which the IP connections are in fact working (hence no problems at the tx/rx level nor on the security policy/profile) but where I want to verify certain details of the connection itself. I’m simply using the Palo as a capturing device here, similar to a SPAN port on a switch. (Yes, I’m aware of all disadvantages of not using a real TAP and a real capture device.) In the end, I want a single pcap which shows all relevant packets for a client-server connection, even if NAT is in place. Wireshark should be able to correlate the incoming/outgoing packets into a single TCP stream. Furthermore, I definitely want to use a filter to limit the amount of captured packets. This is how I’m doing it:

Continue reading Palo Packet Capture: Choosing the Right Filter