Thanks @yannogrodowicz for confirming. Yes, of course re the "netstat -anob". I'm so used to looking at the Foreign Address in the results, I didn't stop to look at the Local Address. Another limitation I've found, at least on our PanOS revision, is that there are a limitation of 10 IP entries that can be entered into the INclude / EXclude fields for the GP Split tunnel "Access Route". Adding more entries just overwrites the existing ones! Unfortunately it doesn't support Address Groups either, so you're forced to enter address entries or point to existing entries in the Address objects table. I've reached out to PA support on my existing case to see if this still exists on all the PanOS versions. Otherwise some may be forced to widen the subnet range in the entries, which would obviously be quite risky. Thanks again for your help and confirmation. BTW: I'll post the info I get back from PA support here.
... View more
Thanks @yannogrodowicz That's some helpful insight there, and much appreciated. I'd already read the article re the split tunnel features (https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-new-features/globalprotect-features/split-tunnel-for-public-applications) but I couldn't find any mention of variable support. I'll take your word for it. 🙂 It's good news that you managed to bypass the MS Teams traffic using a mixture of the variables and subnets, I'll look to do the same. It's a shame that the Split Tunnel doesn't support EDL's as I could have utilised Minemeld for this without doubling up my work. Anyhoo, this is good news you got it to work! 🙂 Could you advise as to when you experienced the changes take effect on the VPN clients? From the general consensus it seems to be once a VPN client has made connection, disconnects and reconnects. This would make sense as if gives the client the chance to pull the policy update and apply it on next connection. Finally, and I ask this question because I couldn't seem to get it to work... It would be good to see if an excluded Client Application Process Name (not IP or domain) is bypassing the tunnel and going direct, or at least some of it's traffic. I know I could look at the FW logs, but that would obviously only show me traffic that the firewall is seeing and therefore routing over the GP VPN, not what traffic is going direct. I know I could run a netstat on the clients and get the apps process ID and see what connections it's making, but that wouldn't show the route the process is taking. Using tracert/traceroute isn't going to work either as that's not the App Process we're whitelisting. - It's Team.exe or Zoom.exe for example that the GP VPN client is looking out for to bypass and not tracert.exe I tried adding the paths to tracert.exe to the Client Application Process Name but this didn't seem to work, yet adding IP exclusions such as 126.96.36.199 happen pretty much straight away. So it made me wonder if the Client App bypass was working at all? Does anyone know of a way of proving the Client App Process is bypassing some traffic at least? I think I'm overlooking something quite simple? It's been a tough couple of weeks on the brain haha! Thanks! John
... View more
Hi all, Am I reading this right in that PanOS doesn't seem to support environment %Variables% in the path name of the executable you're trying to add to the "Include/Exclude Client Application Process Name" fields, be it with or without a GP license!? That's big oversight if that's the case. Has anyone got this confirmed by PA support? If it makes a difference to the PanOS, we're at 8.1.x and have a GP license. I'm basically also looking to add Teams and Zoom to the exclusion list by executable, but it's pretty pointless if neither will work? Or is Zoom working using the .exe path name in conjunction with the IP exclusions for it's IP blocks? Also, are you guys seeing the new GP config changes apply after reconnecting / disconnecting and then reconnecting the GP client again? - I asked PA support when the GP configs get applied and they weren't sure, and advised me that's it's best to uninstall the GP client and clear a registry key and remove the GP services following a config change, and referred me to the following article: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClJDCA0 This seems rather drastic! Thanks, John
... View more
Just a note on the suggesting of importing of the Office 365 config and overwriting your existing config which is a bit bizarre!!!
When this article says "T ake into account that this procedure will replace any configuration you might have with this new collection of nodes. Your old configuration will be lost. " it literally means ANY config... no matter if its an existing security feed config etc, it will be ovewritten!!!
HOWEVER, fear not...
1. You should have taken a backup of the system before-hand right? E.g:
* A VM snapshot if running on a VM.
* An export of the existing config to a text file.
2. Even if you do choose to OVERWRITE your config, you can roll it back by immediately pressing REVERT button in the Config section.
3. Despite what the article says, you do not need to OVERWRITE, but you can APPEND the config instead if you wish, therefore keeping your existing configs and complimenting them with the Office 365 config. - Just make sure you miners, processors and outputs aren't clashing.
Remember - you can REVERT.
Once you're happy, then you can COMMIT.
... View more