About BenKnorr2

I've been doing mixes of internal and external gateways with customer forever (I usually forget that "always-on" must be enabled for internal gateway detection to even be allowed in the first place).   I'm working on a pre-logon implementation that also would benefit from leveraging internal gateways/no-tunnel while inside the enterprise network. I'm seeing some wild behavior at the moment...   THIS TEST IS OCCURRING WITH CLIENT CONNECTED TO CELLULAR HOTSPOT WITH IP ADDRESS ON PUBLIC INTERNET, OUTSIDE MY NGFW   Device, while on internet/outside UNTRUST zone on my NGFW, is configured to connect to my portal as "prelogon" : me.example.com. Device successfully connects to prelogon portal, then EXTERNAL GP gateway, and is shown in NGFW GP-Gateway remote-users pane as "pre-logon" user as expected. On the device at logon screen, however, it shows "Internal Gateway (Connected)".  ... [this is curious since the device is outside my WAN boundary] NGFW globalprotect external gateway status internal gateway, while pre-logon is outside WAN I am able to login successfully on client, and GP client immediately shows that it is connected to internal gateway. On NGFW, it still shows "pre-logon" user on the external gateway. gateway status On client, doing test to www.ifconfig.co , it shows WAN address of my GP external gateway, as if it were connected to the external gateway. The GP settings show no IP information, consistent with it thinking it is connected to internal GW. ipconfig /all shows NO tunnel interfaces, no tunnel information, no IP address other than the wifi address and gateway of my LTE hotspot I am connected to. ROUTE INFO ON CLIENT DURING THIS EVENT: C:\Users\me>route print =========================================================================== Interface List 3...94 65 9c 1b be 1d ......Microsoft Wi-Fi Direct Virtual Adapter 15...94 65 9c 1b be 1c ......Intel(R) Dual Band Wireless-AC 7265 1...........................Software Loopback Interface 1 =========================================================================== IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.83.144 192.168.83.138 35 127.0.0.0 255.0.0.0 On-link 127.0.0.1 331 127.0.0.1 255.255.255.255 On-link 127.0.0.1 331 127.255.255.255 255.255.255.255 On-link 127.0.0.1 331 192.168.83.0 255.255.255.0 On-link 192.168.83.138 291 192.168.83.138 255.255.255.255 On-link 192.168.83.138 291 192.168.83.255 255.255.255.255 On-link 192.168.83.138 291 224.0.0.0 240.0.0.0 On-link 127.0.0.1 331 224.0.0.0 240.0.0.0 On-link 192.168.83.138 291 255.255.255.255 255.255.255.255 On-link 127.0.0.1 331 255.255.255.255 255.255.255.255 On-link 192.168.83.138 291 =========================================================================== Persistent Routes: None IPv6 Route Table =========================================================================== Active Routes: If Metric Network Destination Gateway 1 331 ::1/128 On-link 15 291 fe80::/64 On-link 15 291 fe80::a107:9e6c:1abc:8153/128 On-link 1 331 ff00::/8 On-link 15 291 ff00::/8 On-link =========================================================================== Persistent Routes: None 192.168.83.0 is the internal network on my cellular hotspot and exists entirely outside of NGFW. NGFW knows nothing about this network from security, routing, NAT etc. NGFW logs show no traffic from source IP of this client. The only indications of connectivity on this client from the NGFW side is that I see a "pre-logon" user connected on this device through the external GP gateway. No traffic logs are generated from anything this client does. From the client side, I am able to access all "internal" resources as if I were connected via external GP gateway. ifconfig.co web page shows IP egress address as if I were connected to external GP gateway.   My concern and misunderstanding is with how internal gateway detection works. It seems like at the pre-logon stage, the client successfully reaches the portal, gets a portal config which includes an internal gateway detection element and internal gateway defined. It seems like it is reaching out to an internal DNS server at the pre-logon stage (which I need it to be able to do in order to talk to Active Directory for user authentication at login prompt), and it thinks it is actually inside. The user supplies credentials at login window and GlobalProtect shows "internal" after they login.   Is there some other way to handle this "internal detection" phase with pre-logon in the mix such that "pre-logon" is able to access AD for auth, but not allow the PTR lookup to succeed? Short of some DNS trickery where I create a zone that cannot be resolved in my pre-logon CIDR, I can't imagine how else to make this work. I've seen nothing in PAN documentation that suggests anything other than including an internal gateway is possible. ... View more

I am trying to do some rule enhancement on stuff that is in Prisma. I know that Prisma can export filtered syslogs and Expedition can consume those logs, but the last mile isn't as clear. I want to plug in these logs for machine learning purposes- but I can only do so if I can first import Prisma device groups/rules into an Expedition Project, which isn't as clear if that is possible.   Anybody know if one can see any Prisma config, especially rules, in Expedition if pulling the config via Panorama? A better question might be, can machine learning in Expedition leverage these syslog imported traffic logs and prisma config? ... View more

Viewing through Panorama 10.0.6, while looking at my Mobile_Users_Device_Group, I see various rules showing their levels of usage. What is difference (if any?) between rules that show "unused" vs. those that show "-" in their Rule Used state? Toggling "highlight unused rules" shades both types of rules out, but would be great to understand what difference if any there is between them, if any.     ... View more

Reading the Expedition Log Analysis Guide (1.0.2), it has a tiny blurb about the "flow" in the Learning Results: The Flow has been calculated after figure it out who are the servers on the networks.   In the resulting potential rules, there are mixes of "Client_to_Server" and "Server_to_Server". I import rules to my project and when merging rules to group similar sources or destinations together with common apps, I'm at a loss to understand how Expedition or PanOS calculated the flows. Case in point, I have many rules that come up when merging that all have same src zone, same dst zone, same apps, only src or dst hosts are different. Without knowing more about actual clients that are listed, I would be inclined to group them all in the same policy. But if PanOS or Expedition is seeing an OS fingerprint or something in the traffic and throwing the "client_to_server" or "server_to_client" flow and then tag onto the rule, I would consider leaving them separate.   Assuming same src/dst zones , what would make Expedition call one flow server to client or vice versa? ... View more