PAN-OS 11.1.13 Predefined reports displaying IPv4 addresses in IPv6 format

[A.DeLarisch176960]

We have been experiencing an intermittent problem with our nightly predefined reports displaying IPv4 addresses in IPv6 format.
An IPv4 address like 192.168.1.1 is being displayed as an IPv6 address like ::0101:a8c0:ffff:0

We are currently running PAN-OS 11.1.13 but we have seen this same behavior under 11.1.12.

Behavior like this apparently has been seen before PAN-234560
We do not have any IPv6 configured on our firewall.

Anyone else seeing this behavior?

P.S. This is my first posting in the LIVEcommunity forum, hopefully if I've posted in the correct area.

[kiwi]

Hi @A.DeLarisch176960 ,

The bug you mentioned, PAN-234560, was a known issue where the management plane would occasionally mis-index the log database, causing IPv4 addresses to be rendered in a mapped IPv6 format. Even though you don’t have IPv6 enabled, the firewall's underlying OS uses a unified 128-bit structure to store all IP addresses.

If the report generator pulls the "raw" data without applying the proper "v4 mask," you get that weird ::ffff: style string.

Since you are seeing this on 11.1.12 and 11.1.13, it’s possible there has been a regression. 

Before you call it a bug, check these two things:

• Log Viewer vs. Reports: Go to Monitor > Traffic. Do the IPs look normal there? If the Traffic Logs look fine but only the Predefined Reports look weird, then the bug is specifically in the Reporting Service, not the logging engine itself.

• Panorama vs. Local: If you are using Panorama to generate these reports, check if a local report generated directly on the Firewall (under Monitor > Reports) shows the same behavior. This helps pinpoint if the "mangling" is happening during log forwarding or during report generation.

Occasionally, the management plane cache for reports gets "stuck." A reboot of the management plane (debug software restart process management-server) can sometimes reset the rendering.

Since you have a specific PAN-ID (PAN-234560) and clear examples, TAC can quickly check if this is a known regression in 11.1.x.

If your Traffic Logs look normal but the Reports are "IPv6-ified," it is almost certainly a software bug in how the reporting engine is parsing the hex values from the database. I would recommend getting a TSF to TAC so they can verify if this needs a new PAN-ID.

Hope this helps,

[A.DeLarisch176960]

Thank you for the timely response.

Monitor > Traffic and all of the administrative web functions display the IPv4 addresses correctly it is only seen (so far) on my nightly run of predefined reports.

So I'm guessing that the issue is in the reporting service.

As mentioned, I saw this behavior intermittently under PAN-OS 11.1.12 and recently upgraded to 11.1.13 requiring a reboot.

The IPv6 issue appeared on our nightly report a few hours after reboot.

I'm generating the reports directly from the firewall, not thru Panorama.

The curious thing is is it's inconsistency. 

On last night Threat report, for example the Top 5 Users has addresses in IPv6 format but Top Attacker Sources is in proper IPv4 format.

Opening up a call with Ingram Micro... will let you know what they come up with!

[A.DeLarisch176960]

Some additional information about IPv6 formatted IPv4 addresses

First started to occur when I upgraded our Firewall's PAN-OS from 11.1.10 to 11.1.12 and remains after upgrading to 11.1.13

If I use the GUI to display the predefined reports, the IPv6 formatting issue is consistent with the emailed nightly reports..

Issue appears to be during report generation.

It is random from day to day if we get real IPv4 addresses or IPv6 formatted IPv4 addresses in the predefined reports..

Sure sounds like a bug!

[Raido_Rattameister]

Open case with Palo as most likely old bug has been resurfaced.

From my old notes when I had this issue few years ago.

Bug: PAN-190448 and PAN-234560
Example, the report shows: ::dcdc:43d0:ffff:0
DC = 220, DC 220, 43 = 67, D0=208 and the tail of :ffff:0 can be tossed.
Those octets of the IP are flipped, so the actual IP address in the report is: 208.67.220.220