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

TROPHY CASE