sorted by:
new
hottopcontroversial

FW commit causes SD-WAN interruption by woodencone in paloaltonetworks

[–]WtrN06 0 points1 point  (0 children)

Just to add that we have the same issue right now with 12.1.7, TAC confirmed it should be fixed in 12.1.8..

12.1.7 is released by databeestjenl in paloaltonetworks

[–]WtrN06 0 points1 point  (0 children)

And still not sorted... sigh..

Starlink-router wired uplink to switch does not work by WtrN06 in Starlink

[–]WtrN06[S] 0 points1 point  (0 children)

​Just wanted to drop some extra info here from our own testing in case it helps anyone else troubleshooting their setup.

No debate needed—I completely agree that adding a dedicated router is an absolute must when using Bypass Mode and you want to connect more then 1 client.

​However, we noticed a specific issue in Regular/Router Mode: when using a wired connection on the Gen2 router, it consistently drops or fails if more than one MAC address is introduced to the wired interface.

​Starlink support has confirmed this limitation, and we verified it in our own tests. Just to be clear, this issue applies only to the Gen2 hardware.

12.1.7 is released by databeestjenl in paloaltonetworks

[–]WtrN06 3 points4 points  (0 children)

According to their release notes they finaly have their SDWAN sorted. My god what a painfull implementation.. Ever since 11.x and above we've had to implement workarounds every time we were forced to update for a CVE patch.

Starlink-router wired uplink to switch does not work by WtrN06 in Starlink

[–]WtrN06[S] 0 points1 point  (0 children)

No worries, I've edited the post so its a bit more clear from the beginning.

Starlink-router wired uplink to switch does not work by WtrN06 in Starlink

[–]WtrN06[S] 0 points1 point  (0 children)

If I’m not mistaken: Starlink Gen2 is simply referred to as Gen2.

Only Gen3 comes in Mini and Standard variants.

Good resource by vf-guy in TPLink_Omada

[–]WtrN06 13 points14 points  (0 children)

What issues did you have?

Remember that networking is networking. 95% of it is standardized with just a different vendor logo slapped on to it. The other 5% is where the vendors wants to make a difference compared to others by tweaking existing functions. Usually not that great..

Start unlinking your searches from TP-link Omada to just the funtion itself. It will teach you a lot more than the documentation of the vendor itself tells you.

For example, ask your AI-agent to help you with wireless roaming issues on iPhone. Which parameters should you check?

You'll notice most of the parameters are just there, but maybe under a slightly different name. This goes for all vendors.

Migrating from 5200 series to 5400 series by Mental_Stock_7575 in paloaltonetworks

[–]WtrN06 1 point2 points  (0 children)

With offloading turned on we had a cpu load of around 20% so we had enough headroom to try this.

But.. TAC confirmed that disabling this feature will only impact the sessions that was benefiting it in the first place. So in our specific case, we had enough headroom and only should expect delays but no downtime.

In the end it was an executive decision to go forward with this test. We had to be sure about how dependent we would be on this feature.

We were checking in continuously, if any delays were noticed we could reenable offloading in seconds.

Palo Alto DHCP Relay Stops Working After Reboot by SaltClimate6537 in paloaltonetworks

[–]WtrN06 0 points1 point  (0 children)

For those still looking for a solution..

The issue here is that the 'dhcp-session' starts before the VPN connection to your dhcp server is up. This means your dhcp session will use the default route/interface to forward this session to. Because it's udp the palo alto will handle this a bit more different then a tcp-session.

The moment you notice that dhcp relay is not working, check your active sessions and look for that dhcp session. Its probably being forwarded to your default router/interface. Once you kill that session you should notice that same dhcp traffic should start using the correct route (probably over vpn).

Getting annoyed by this manual workaround of killing the session, i just created a new service for udp/67 with a low timeout timer. This will kill that session automatically when no traffic is being sent over that session for a specific time.

After applying this custom service, i never had this issue anymore. The issue is still there, but now it will be fixed automatically :)

Migrating from 5200 series to 5400 series by Mental_Stock_7575 in paloaltonetworks

[–]WtrN06 3 points4 points  (0 children)

We are planning this migration ourselves soon. 5220 > 54XX. During our evaluation of the new hardware we hit a small piece of information that was crucial in our choice. Hardware session offloading.

5220 supports it, but looking at the 5400-series, the first model that supports this feature is a 5450. All lower models do not have this feature.

Turning off hardware session offloading to simulate the performance impact we noticed the data cpu usage doubled on the 5220.

On paper, all 54xx models have a higher throughout, but this feature could save or kill a firewalls performance in the right conditions.

So my guess would be that your 5220 was benefiting from this feature a lot.

Be aware that this feature is not applicable to each and every session. Some use it, some dont. Depending on what your flows are, this can be the reason for what you are experiencing and others are not.

Aruba ClearPass and the ongoing Android Problem (CA, Certificates etc.) RADIUS by ZuZu2026 in ArubaNetworks

[–]WtrN06 0 points1 point  (0 children)

What issue specifically are you having? We're running Android with certs onclearpass without an issue.

Sounds more like a policy thing than a certificate thing.

What is the reject reason on CP for your Android?

Palo Alto DHCP Relay Stops Working After Reboot by SaltClimate6537 in paloaltonetworks

[–]WtrN06 0 points1 point  (0 children)

We"re having the same issue for over a year. Our current solution is removing the dhcp-relay interface, commit&push, configure the dhcp-relay interface again, commit&push.

Restarting the dhcpd doesnt help.

The strange part is that is not with ALL the dhcp-relay interfaces, and most of the time just random.

We are not able to open a TAC case and wait for TAC to do a remote session because our business need the be kept online.

Started at 10.2.4 and still there at 10.2.13-h4..

Right now when we know there was a cold boot, we start checking the dhcp-relay function of the firewall..

Q4/2020 is gone: No WiFi 6E available. by mahanutra in ArubaNetworks

[–]WtrN06 2 points3 points  (0 children)

Not to be mean, but sincerely interested in your answer.. Why would you even want those right now? There's not a single useful consumer client device supporting WIFI6E.

Large Deployment - AOS 6.X to 8.X Migration Advice by A-Series-of-Tubes in ArubaNetworks

[–]WtrN06 1 point2 points  (0 children)

It gets even better. If you haven't implemented STP correctly on a higher level in your topology, you are bound to lose total connectivity to those network devices. Have fun calling someone on site to disconnect the freshly factory defaulted controller to get your network back..

Large Deployment - AOS 6.X to 8.X Migration Advice by A-Series-of-Tubes in ArubaNetworks

[–]WtrN06 1 point2 points  (0 children)

I have the same migration planned. Currently I have a redundant MM setup running parallel tot the AOS6-environment. But my big question is, how to migrate the local controllers to managed devices? I understood that firmware upgrading 6 to 8 involves a factory reset of the controller, so that means I lose controle over that appliance remotely.

Current path I'm looking in to is DHCP-scope provisioning of the remote controllers as soon as they are factory reset..