When connected to a SSL VPN on macOS sometimes you want to find which physical network interface the VPN is using. Listing network interfaces using ifconfig doesn’t help as it is just a list of adapters and if they are linked or not. Looking up the default route with route get 1.1.1.1 only shows you the tun adapter the VPN is using: ❯ route get 1.1.1.1 route to: one.one.one.one destination: default mask: default gateway: my-mac interface: utun0 flags: <UP,GATEWAY,DONE,STATIC,PRCLONING,GLOBAL> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1400 0 In this case the VPN is using “utun0” which is the virtual adapter.

Sometimes removing the .dat files from the GlobalProtect application folder is a good first troubleshooting step when looking into GlobalProtect client issues. The .dat files hold the authentication cookie (pre-auth and user auth) and portal configuration file. Folder locations can depend on if the portal is using pre-auth or not as pre-auth is not user specific. Windows The main user specific folder location to remove the .dat files can be found at the following folder path:

Windows 11 seems to come with a built-in instance of Microsoft Teams. If you are using Office 365 then you end with two versions. Use the following to check you have the default instance of Teams: Get-AppxPackage -Name teams If you have the default Teams installed you will get something like: To uninstall this package you can use Remove-AppxPackage, just pipe the output from the previous command: Get-AppxPackage -Name MicrosoftTeams | Remove-AppxPackage -ErrorAction stop If successful then running the original command should have no output:

I really would think before trying this in any form of production environment. It did however work for a VMware lab I was building today (05/04/2022). The issue occurred when upgrading esxi from 6.0 to 6.5 by booting to the install media. One machine worked as expected, the other for some unknown reason would only allow a new install, not an upgrade. After a very small amount of research I found this.

I was trying to install some software remotely today and was it wasn’t going well. All the others had worked fine, after some investigation I found: It has been a while since I have seen error code 1633. From distant memory 1633 is a 32 bit OS and a 64 bit installer? For the life of me I could not remember how to check that. After going through my random txt files I found:

After onboarding into Prisma Access, Cortex XDR live terminal connections were no longer working. There is an existing support document relating to these sort of issues: Enable Access to Cortex XDR There is a section for decryption issues (step 2); what is not clear on this page is that to allow live terminal to work you also need to exclude the following URL: lrc-eu.paloaltonetworks.com It is referred to in Step 3 but only from a point of view of access.

The Windows Graphics Tools are used for Direct3D application development. To install you need to open an elevated command prompt, then use the following to check if it is currently installed: dism /online /Get-Capabilities This will output the currently available options/packages and see if they are currently installed (state): To install the windows graphics tools use the following to download and install: dism /online /add-capability /capabilityname:Tools.Graphics.DirectX~~~~0.0.1.0 Which if successful should look like:

Due to a firewall issue, I needed to see if an update to PANOS was related to a change in behaviour. I wasn’t sure exactly when the firewall had been upgraded. Searching through the system logs did not seem to show PANOS version changes. Finally I found a mention in a support forum of debug swm history. In short: debug swm history | match 'install panos' Will give you the history of upgrades.

Sometimes you want to see exactly what a computer or application is trying to communicate with. Obviously you can take full a network packet capture and filter the results and correlate the behavior with the DNS traffic, but sometimes it is easier to watch these results live as they happen. One quick way to do this is use Wireshark, however not the full client but the command line version tshark. Tshark allows you to filter on specific facets of DNS giving you a cleaner output especially when you are only interested in domains that an application is talking to.

In a fully wired VMware lab using a virtual Palo Alto (PANOS 8.1.14-h2) VM-50 I could see really rather high latency: That did not make sense for a wired LAN. After some internet based digging I found this: Is higher latency normal on a VM compared to hardware? This referred to some rare issues with virtual Esxi Palo Alto’s and intel’s DPDK. Following the referenced link takes you to a Palo Alto support page showing you how to disable the DPDK which as it states in enabled as default.