To Start the debug:
diagnose wireless-controller wlac sta_filter clear
diagnose wireless-controller wlac sta_filter [MAC address here in format xx:yy] 255
diagnose debug enable
diag debug console timestamp enable
To stop the debug:
diagnose wireless-controller wlac sta_filter clear
diagnose debug disable
diag debug console timestamp disableIf you are using the SSL VPN Web Portal, and you are allowing access to resources that are accessible over a site to site VPN tunnel from the FortiGate, there are several considerations to keep in mind.
With the web portal, the firewall will proxy the connection from the user to the actual resources. If the resource is on the local network and the firewall has a route to the destination, it will source traffic from one of it’s interfaces that is “closest” to the end device. This may be the local LAN/internal interface.
However, if the resource is available only across a site to site VPN tunnel, then the firewall will try and source this traffic from the “closest” IP to the site to site VPN tunnel. If there is no IP address explicitly configured on the VPN tunnel itself, then it will choose the public IP used in the VPN tunnel termination. Many times, the public IP isn’t allowed to pass traffic across the actual VPN, and so this will be rejected.
The best thing to do would be to assign an IP address to the tunnel interface itself. When this is configured, the firewall will use this IP address to proxy and source the traffic from. Additionally, you must make sure that this IP address is allowed on the VPN as far as the proxy-IDs, routes on the other end, and any security rules on both ends that control traffic access.
Radtest is a tool that is part of the FreeRadius server package that can be installed with HomeBrew on macOS: https://formulae.brew.sh/formula/freeradius-server
Install command:
brew install freeradius-serverOnce installed, you can run the command like this:
radtest lscaringella "passwordhere" [server IP here] 10 [secret here]
Depending on the Radius server, you may have to ensure that your machine that you are testing from is added as a trusted Radius client on the server.
Some organizations may choose to setup their remote access VPN to enable the VPN to connect automatically prior to a user logging into the machine. There may be a number of reasons for this, but in this case the VPN client must use a machine certificate to authenticate to the VPN.
I have encountered the below situation in regards to this pre-logon VPN setup. A machine with Global Protect and always-on with pre-logon settings reboots and is sitting at the Windows login screen. The machine successfully authenticates to the VPN using a machine cert. Now, the user logs into the machine. What should happen is that the Global Protect client detects a user login, then changes the VPN session from “pre-logon” to show the actual user logged into the machine. This could be from single sign on credentials or also use a user certificate to authenticate to the VPN.
This process is well documented and should happen seamlessly. However, the documentation doesn’t mention that the Global Protect agent will actually attempt another DNS request for the Global Protect gateway. So, let’s assume the gateway address is vpn.example.com. Prior to any VPN connection, the machine uses whatever DNS servers are configured, let’s assume 8.8.8.8 and 1.1.1.1. This then uses public DNS to resolve vpn.example.com to its public IP and the connection successfully goes through.
When the user logs in, the machine is already connected to the VPN and will be using internal DNS servers. Because of this and the fact that Global Protect will do a fresh DNS request for the gateway after the user logs in, this DNS request will fail to resolve properly to the external gateway and Global Protect would fail to connect. I determined this was being done from analyzing the logs of a system that to see the DNS request fail to resolve.
So, there are two ways to fix this. One, a DNS A record can be added to the internal DNS servers that maps vpn.example.com to its public IP. The other method is to create a DNS split tunnel in the Global Protect settings to exempt the vpn.example.com from being resolved by the DNS servers over the tunnel and instead use whatever DNS servers are configured on the end system.
I have encountered situations where a customer is needing to route all traffic, including Internet-bound traffic, from a branch location back to a main location to ensure consistent security policies, content filtering, or some other requirement.
In this scenario, let’s assume there is a firewall and ISP at the branch location. Normally, the firewall would have a default route configured that points to the ISP gateway for all Internet traffic. When adding a site to site VPN tunnel on a firewall that uses route-based VPNs and you want to send all traffic across this tunnel, you must create a default route that points to the tunnel interface. Fortinet and Palo Alto are examples of firewalls that use route-based VPNs where this would be applicable.
Because you are changing the default route to point to a site to site VPN, it is critical to also add a specific host route that points to the VPN peer public IP with the ISP gateway as the next hop. This is to ensure that the firewall has a route to the VPN peer instead of only using the default route that points to the VPN interface.
Background: In the past, when using the agentless method of User-ID with a Palo Alto firewall, WMI was used for the firewall to connect to a domain controller and parse Windows security logs to find user to IP mappings. However, on June 14, 2022, Microsoft released patch KB5004442 for Windows Server to address the vulnerability described in CVE-2021-26414. This patch essentially breaks the WMI connection from the firewall to the server. This is described well here: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000wkkfCAA
The new solution is to enable WinRM to be used in place of WMI. This process is very well documented so I won’t go into detail here, but I did want to mention that I had to add the service account used for this into the “Remote Management” group in Active Directory or else it wouldn’t work properly and would show “Access Denied” for the server. The below links are helpful in configuring this and only one of them has the Remote Management Group mentioned.
https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/user-id/map-ip-addresses-to-users/create-a-dedicated-service-account-for-the-user-id-agent
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000001VUICA2&lang=en_US%E2%80%A9
https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/user-id/map-ip-addresses-to-users/configure-server-monitoring-using-winrm
When trying to troubleshoot network or Internet related connectivity issues, it may be helpful to have a system on the inside network pinging a reliable destination on the Internet to test connectivity and log the output with a timestamp to find the specific times when an outage occurred.
Here is the command within Linux I used for this:
nohup ping 1.1.1.1 | while read result; do echo "$(date): $result"; done > /home/user/pinglog.txt &Including “nohup” makes it so this command continues to run even when the session to the system is closed. When you run this command without “nohup” and you close the SSH session to that Linux host, the command will stop executing. The “&” at the end makes this command run in the background on the system.
The command takes the ping output and creates a variable called “result”. The time is added and then the “result” variable is output.
This article will describe the steps needed for importing a VPN, DNS, or Device Management profile to a iOS or iPadOS device and enabling full trust for these certificates.
The configuration profiles allow an administrator to import settings to an iPhone or iPad which can be used for functions like VPN, DNS proxying, MDM, or trusting an internal Certificate Authority.
Recently, I implemented SSL decryption on my firewall, and had to import a self-signed CA certificate into my devices so that it was trusted and SSL/TLS errors didn’t appear within the web browser. There are two main steps for this.
First, send the certificate to the device using some method such as email, Dropbox, Airdrop, or MDM (if this is a managed device already). The certificate will appear under Settings->General->VPN,DNS, & Device Management. Make sure the cert you imported shows “Verified” when clicking on it under the “Configuration Profiles” section.
Next, if you need the device to trust this certificate as a root CA, you must also go to Settings->General->About and scroll down to “Certificate Trust Settings”. Check the box next to the cert in the “Enable Full Trust For Root Certificates” section.
Now, the device shouldn’t see any browser warnings when SSL decryption is performed using that certificate.
I recently setup the Sophos firewall as a VM in VMware ESXi 8. Sophos offers this for free for home users with limitations around how much memory and CPUs can be used.
When deploying this, or really any other virtual firewall in VMware, there are a few things to consider. First, just like a physical firewall appliance, you’ll want at least a minimum of two physical ethernet ports on the VMware host. This will allow you to use a traditional “inside” and “outside” interface. Next, if your VMware host has multiple ethernet ports, it is worth identifying what those ports are ahead of time before deploying the VM. This can be done by plugging in each cable on the physical host and checking what port lights up in the VMware console under the Network Management settings. Make a note of which ports they are.
Before deploying the VM, you can prepare the network settings in VMware for this. You’ll want to have two separate virtual switches, each associated with their own physical ethernet port. I created one vswitch for “inside” and another for “outside”. Next, I created two ports groups, also one for inside and outside and attached them to the appropriate virtual switch.
Here are the virtual switches:
Here are the Port Groups:
Now, when deploying the VM, add two network adapters and assign one to the inside port group and the other to the outside port group.
I have noticed that at times when using FortiClient for remote access VPN connections with MacOS, that after disconnecting from the VPN, the DNS settings added by FortiClient for DNS resolution over the VPN, fail to be removed.
When connecting to the VPN, an entry is added to /etc/resolver for the domain name associated with resources behind the VPN tunnel. For example, a resolver for example.com is added here. When on the VPN, this allows the user to resolve a hostname such as dc01.example.com. However, when the VPN disconnects, this should be removed. If the domain name used internally is the same as that used externally, then once the VPN is disconnected, with that resolver still in place, it will attempt to resolve DNS using that resolver over the disconnected VPN causing subsequent connections to the actual VPN to fail.
If the VPN hostname is vpn.example.com, and the resolver is still there, it fails to resolve and can’t connect to the VPN.
The solution I have found is to go to /etc/resolver, run “ls”, then run “rm example.com” to remove this. After doing this, resolution should use the system DNS servers and work as expected.