About ACieszkowski

@hedery_hl, Yes, PANW has a dedicated sandbox service - https://www.paloaltonetworks.com/products/secure-the-network/wildfire; it can be integrated with PA firewall, used directly through WidlFire Portal (https://wildfire.paloaltonetworks.com/wildfire/dashboard) or brought on-premise as a dedicated WF-500 Appliance (https://docs.paloaltonetworks.com/content/dam/techdocs/en_US/pdf/hardware/wf-500/wf-500-hardware-reference-guide.pdf). ... View more

@raji_toor, Good to know 🙂 Internal Gateway has to be reachable in the Internal Network, but without the tunnel mode, answering your previous question. ... View more

@raji_toor, As far as I know you need to have an Internal Gateway inside the Internal Network to get the User-ID mapping (and HIP Reports) via GlobalProtect. In the logs I see: " Gateway count is 0 for internal network." and "NetworkDiscoverThread: PortalStatus is 1, HasLoggedOnGateway is 0" Are those logs from the time you tested with or without Internal Gateway configured? ... View more

@raji_toor Could you possibly provide more details about your setup - Chrome version, Firefox version, PAN-OS version? Configuration of Decryption Profile used in the Decryption Rule this traffic is hitting (from CLI: show profiles decryption <decryption-profile-name>)? Have you checked the ciphers negotiated by Chrome and Firefox through packet-sniffing the TLS/SSL handshake? @OtakarKlier  Wouldn't you agree that properly implemented HPKP for a website would result in error reported by browser, not by PA? Also it looks this website does not implement it (according to the https://gf.dev/hpkp-test). ... View more

Hi @vnt90,   If the connection is correctly working they should not drop it. Is the " Automatically Use SSL When IPSec Is Unreliable (hours)" option enabled (value > 0)? Have you looked into GlobalProtect Agent/Service logs gathered from the machine with those symptoms? Reason for the IPSec > SSL switch should be identifiable there.   To my knowledge timers for GlobalProtect tunnels, keepalives and timeouts, are hard-coded. ... View more

Hi @raji_toor,   Tough to say as multiple factors may play a role and information is scarce. I would guess that machine with GlobalProtect was moved from External to Internal Network in a way that did not trigger Network Discovery so Internal Gateway was never contacted.   But troubleshooting should start from inspecting the GlobalProtect Agent/Service logs from the system in question. ... View more

@OtakarKlier,   In the 1 VR environment you lose a bit from the dual-ISP setup - precisely tying the PA-originating packets to the interface-ISP pair.   My most-loved is the 3 VRs setup with EBGP - most control and granularity, especially if VPN is setup with 3-rd Party 😉 ... View more

@Joshan_Lakhani,   " PBF does not function for IPSec Tunnel traffic to the Palo Alto Networks firewall." - yes, but from what you wrote thus far it seems that it is not relevant to your situation because you are working on passing traffic from/through Palo Alto Networks firewall. Also in mentioned KB: "The PBF will only work for the traffic sourced from a machine behind the firewall and not for the traffic sourced from the firewall.".   Maybe a drawing of the topology...? ... View more

@Joshan_Lakhani,   I think you misunderstood me. If "192.168.12.17" is the IP address behind the VPN tunnel, traffic inside the tunnel, not the IKE Peer (looks that way) then you have to direct it into the tunnel interface assigned to the tunnel (tunnel.109, I presume). You have to direct the traffic to be tunneled through the VPN Tunnel into the tunnel interface or it will not be, err..., tunneled.   "As i have add the static route for 192.168.12.17 towards DHCP(192.168.0.1) link" - this is an error, will not work. ... View more

Hi @MinSeob-KWON,   Not sure about the requirement - SSL Decryption or Decryption Mirror or Decryption Broker, assume the first. https://beacon.paloaltonetworks.com/student/catalog/list?category_ids=15475-ssl-decryption - this should help. ... View more

Hello @hedery_hl,   I have taken a look at "Virus/Win32.WGeneric.akrgog" in the PANW Threat Vault and cross-checked the SHA256s in the VirusTotal - only 2/10 were identified as malicious and with low detection rates (7/61, 9/62): https://www.virustotal.com/gui/file/7903b51a0840b64c00f6a39ab3e9b4b1a4880a46bc0bdca8b3bba4abf3392def/ https://www.virustotal.com/gui/file/85b51b37e403a7e760b146f26f63f1774b5a041b533b152bb6781e596c4e546a/ By no means should you trust this file to be safe based only on VirusTotal.   I can recommend, if possible, uploading it into sandbox solution to get a bigger picture.   Is this file publicly available? Could you possible share the URL or, at least, SHA256?   @BPry have you seen a lot of FPs on AV/WF signatures? ... View more

Hi @Joshan_Lakhani,   As I understood: two ISPs, two VRs. After you moved IKE Gateway from interface connecting to ISP A to interface connecting to ISP B the VPN Tunnel is "up" (SAs between peers are successfully negotiated) however traffic FROM your internal network TO remote network "behind" the VPN Tunnel is not passing through to the remote site. I assume the Virtual Router "VR ADSL1 Internet VPN and LAN" (from the screenshot you provided) is the one to which "my PC" from your first post is connected to. The beauty in design of Virtual Routers is that they are separated. Every one has its own routing table. Routing lookup you are doing are per-VR, not device-level. Traffic from your PC will "arrive" and use the routes present in the "VR ADSL1 Internet VPN and LAN"; as there is no specific route for the network behind the VPN route toward ISP, the default one, will be used to forward those packets. You have to "push" the packets from "VR ADSL1 Internet VPN and LAN" to "VR for New ADSL" and from there - to the tunnel. Easiest solution to do so would be to add static route in the "VR ADSL1 Internet VPN and LAN" to 192.168.12.17/32 (or whatever the remote network behind tunnel is) with Next Hop - Next VR "VR for New ADSL". PBF you mentioned is also an option - you would have to define a PBF Rule for Destination 192.168.12.17/32 (or whatever the remote network behind tunnel is) with egress interface tunnel.105 (basing on your screenshot). I must mention that egress interface used in PBF Rule must have an IP address (does not matter what address, it is not actively used, any valid will do).   Personally I like to create three VRs for such a setup - one per ISP and one for Internal LAN then do traffic steering with PBF or static routes, where needed. ... View more

@Sec101,   " Allow traffic to specified fqdn when Enforce GlobalProtect Connection for Network Access is enabled and GlobalProtect Connection is not established" looks to be a not-ready feature as it is not documented, yet. I assume this is something related to PAN-OS 10.0 and its associated GlobalProtect Client version (6.0?). ... View more