Unexpected Private Access rule after rebuilding Global Secure Access v2

Hello everyone,

I'm rebuilding a Microsoft Entra Global Secure Access / Private Access POC after initially creating several configurations while learning the platform.

I performed a clean functional rebuild: removed the previous application segments and assignments, reinstalled the Private Network Connector, created a new connector group, rebuilt Quick Access, and created a new custom Private Access traffic forwarding profile assigned only to my test account.

My intended Quick Access configuration currently contains only three TCP destinations on the same private server: ports 80, 445 and 9000.

However, the effective forwarding profile received by the Global Secure Access Client also contains an unexpected rule:

192.168.1.208 | All protocols | 54-65535 | Tunnel

This rule existed in the original default Private Access profile and continues to appear even in a newly created custom profile.

There is another unusual behavior in Acquisition Rules. An internal GUID reference is displayed in the profile, but the application selector shows Selected (0). The GUID cannot be removed through the UI, is not visible as a normal Enterprise Application, and I could not resolve it as either an Application or Service Principal through Microsoft Graph.

I also found:

• ZTNA Network Access Client -- Private, which previously contained segments and assignments that I have since removed;
• two different objects named Carbomix - Rede Interna, with different identifiers;
• an error when attempting to remove an inherited link from the system-created profile: Only Profiles with IsCustomProfile set to true can be updated with bulk policy links.

The connector itself appears healthy. I completely reinstalled it and the official Connector Diagnostics Tool passes certificate, TLS, CRL, Bootstrap, Trust Renewal, Service Bus, SLB and endpoint connectivity checks.

Private Access also works for normal TCP traffic. TCP 445 and 9000 are successfully tunneled, including a sustained TCP session on port 9000.

I'm mainly trying to understand:

1. Where does the unexpected All protocols / 54-65535 rule come from?
2. Why does it survive a clean custom Private Access profile?
3. What are these internal application references that appear in Acquisition Rules but are not selectable/removable or resolvable through Graph?
4. Could this be configuration inherited during migration to Traffic Forwarding Profiles v2?
5. Is there a supported way to inspect and clean this inherited state?

Has anyone working with Microsoft Entra Private Access v2 seen similar behavior?

I have screenshots, effective forwarding-profile data, Connector Diagnostics results and Graph tests available and can share the relevant details as needed.

Thanks!