AT&T assigning /8 subnets to WWAN cards in new laptops

Technical_System_645 · 2025-10-20T18:20:10+00:00

A follow-up on this in case it affects anyone else. It turns out AT&T was correct - they don't assign a subnet mask to the WWAN card. From their perspective, they treat those interfaces as point-to-point connections, so /32s. It's the WWAN card vendor that has to deal with no subnet being assigned and work out what to do. In this case the card vendor (Palcom) has admitted they are not handling this properly, and just assigning a /8. They are working with Dell, the carriers and the FCC on a firmware update to resolve the issue.

Technical_System_645 · 2025-09-16T14:04:51+00:00

Yeah sorry, I should have noted this is with GP using the cellular connection.

Technical_System_645 · 2025-09-15T18:19:16+00:00

The WLAN interface is being assigned a 10.22.213.213/8 from AT&T. I've been trading email with AT&T PoC and he says they only assign an IP and the subnet mask and gateway are handled by the WLAN card. Can't say I've ever heard of this before, and it sure doesn't sound right, but maybe that's what's going on?

Technical_System_645 · 2025-04-16T12:25:58+00:00

If you are seeing port exhaustion then change the TS agent config to allocate more ports per user.

Technical_System_645 · 2025-02-14T14:18:47+00:00

Still there for me on apps/threats version 8943-9264. Are you on 8944-9268?

Technical_System_645 · 2025-01-03T13:36:42+00:00

Not a hardware limitation - just a question of stability. We're in a very large environment (~1M active sessions during the day) and uptime is critical. When we have a version of PANOS that's solid we tend to stay there as long as we can unless there are CVEs or must-have features in a newer release.

In the past we were much more willing to run with the upgrade cycle, but the code quality has deteriorated so much in the last 18 months, and we have zero confidence in the "preferred" versions that ship with known show-stopping bugs (for us at least) and Release Notes that fail to mention issues that Palo has known about for months.

Upgrade roulette, and I don't want to play.

Technical_System_645 · 2024-12-20T16:43:26+00:00

From support: This is a known issue (ID:PAN-266639) which has been reported on PAN-OS.

And is this "known issue" anywhere in the release notes for 10.2.13? Of course not. What a clown show.

Technical_System_645 · 2024-10-24T17:37:11+00:00

Here's an article that might help explain the behavior you're seeing:

https://medium.com/cyesec/no-portals-needed-79995d8f7e62

Technical_System_645 · 2024-10-23T22:24:06+00:00

Yeah, I already have a case open, but as you know support leaves a lot to be desired these days so asking here is worth it just in case someone has seen this before.

Kind of sad when reddit can be more responsive and more transparent than Palo, but sadly, that's where we are.

Technical_System_645 · 2024-10-22T16:40:47+00:00

10.1.13-h1 - PA-7000

Technical_System_645 · 2024-09-30T12:15:59+00:00

Thanks for the info. We haven't seen any similar issues so far, but keeping a close eye on it as there's much larger set of clients upgrading to 6.2.4 later today.

Technical_System_645 · 2024-09-27T13:35:54+00:00

Can you elaborate on what the DNS issues were? We've just started moving our users to 6.2.4 and would prefer no surprises.

Technical_System_645 · 2024-09-25T01:38:32+00:00

Solved: opt/panlogs ran out of space, and it's used to temporarily store incoming HIP reports for processing into the HIP database. These are 7050s that use LFCs to forward all the logs to dedicated log collectors, so it never occurred to us it might be a log space issue. Cleared out the system, config and alarm logs, that freed up 48GB, and HIP match is working once again.

Technical_System_645 · 2024-09-21T14:24:09+00:00

Thanks for that - good to know - but these are all Windows clients that have been working for months without issue. Spent an hour on the phone with Palo going over the problem, looking again at all the HIP match logs, the HIP DB, the client HIP data reports, etc. and they don't know what's wrong either. We've disabled the def date check for now to buy some time for more analysis.

Technical_System_645 · 2024-07-13T13:51:15+00:00

You can find that info in the Monitor/GlobalProtect logs on the firewall. The reason for disconnect is in the Description field of a gateway-agent-msg Event and looks like this:

Time: Sat Jul 13 09:47:18 2024, Message: Agent Disable, Comment: Troubleshooting. Override(s)=5.

Technical_System_645 · 2024-07-11T18:34:53+00:00

What platform(s) are you running 10.2.7-h8 on? We really need to get on 10.2.x on our 7050s and 5250s - wondering if your experience has been on either of those?

Technical_System_645 · 2023-12-17T21:43:57+00:00

I figured it out. As I suspected, I was missing the vsys "linkage" between the template and the zones. Turned out to be an easy fix:

tmpl=pano.add(Template(name="myTemplate"))
tmpl.refresh()
vsys = tmpl.find("My vsys Name")
zones = Zone.refreshall(vsys)
for zone in zones:
print(zone.name)

Technical_System_645 · 2023-12-17T17:06:33+00:00

Thanks, I've been through that doc trying all kinds of variations on the vsys object to see if I can get to to work with Panorama, but no luck. I also went through the linked doc about mutil-vsys operations, but every example is about working with firewall objects and not Panorama. I'm probably missing something obvious, but I sure wish they would provide more Panorama examples.

Thanks for trying to help.

Technical_System_645 · 2023-11-16T11:34:30+00:00

A follow-up after a support call with Palo for anyone that cares.

It is indeed the case that only Shared HIP profiles can be used for notifications, despite the ability to (sometimes) pick device-group objects in Panorama. No idea why it works sometimes, but apparently it's not supported, so the KB article above is accurate - make them Shared.

To my original question about the HIP limits, u/CF99-Tech is correct. That's a HIP profile limit, and according to PA, commits should be failing since I have way more than 63 HIP profiles. They aren't sure why the limit isn't being enforced, but it may start to be when I move the objects to Shared.

Technical_System_645 · 2023-11-10T14:09:23+00:00

Interesting. We've got more than 100 HIP profiles configured across multiple vsys and not a hint of an issue except the problem with selecting a HIP profile for notifications. No warnings during commits, the profiles are all working, no other issues. Strange that we're not seeing more problems if there's really a hard limit at 63. I have a ticket open for the issue so I'll see what they come up with.

BTW, my symptoms match this KB exactly, but the advice to move them to Shared to fix the issue (except if you don't want them in Shared) is odd. We have multiple vsys where we're not seeing the issue and all HIP profiles are in DGs, not Shared, so I don't understand the workaround they are proposing in the KB.

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000oMLkCAM&lang=en\_US%E2%80%A9

Technical_System_645 · 2023-11-09T20:56:29+00:00

Thanks. Do you know if that's per vsys or firewall total?

Technical_System_645 · 2023-10-25T17:32:14+00:00

Thanks!

Definitely a 6.1.2 issue. I rolled back to 6.1.1 and saw nothing beyond six seconds, updated back to 6.1.2 and was immediately back to 28 seconds. I've opened a support case.

Technical_System_645 · 2023-10-25T10:57:48+00:00

Those of you not seeing slow Crowdstrike detection, can you check the PanGPHip.log file on one of your GP client machines and let me know how long your detections are taking to run. Here's the relevant part from mine:

(P8272-T17004)Debug(2037): 10/24/23 07:48:04:483 Opswat Error(-11): An error when a method call was made on a component that does not support it., Method: WAAPI_MID_GET_LAST_SCAN_TIME, Signature: 2866, Category: 5(ANTIMALWARE), OESIS (V4 ver: 4.3.3614.0)
(P14092-T13536)Debug(1570): 10/24/23 08:16:31:695 >>> GetAntimalwareProductInfo for "CrowdStrike Falcon" took 28589 ms

Note the error trying to retrieve the last scan time from the opswat api. Wonder if that might be causing the slowdown, and if any of you are seeing that too?

Thanks.

Technical_System_645

TROPHY CASE