Occupancy tracking works with cloud security proxies, virtual private networks (VPNs), and networks without a fixed IP address, as long as Skedda can identify your office's public IP address. This article explains what Skedda needs from your network and how to configure the most common setups. To learn how occupancy tracking works, see Occupancy tracking.
What occupancy tracking needs from your network
Skedda marks a person as seen on-site when their device connects to Skedda from a public IP address listed in Settings → Occupancy tracking. Skedda does not see inside your network. It only sees the public IP address your traffic leaves from, called the egress IP.
Occupancy tracking works when your network meets these three conditions:
Office traffic leaves from a known public IP address or range, in IPv4 or IPv6
The office IP address stays the same over time
Remote traffic leaves from a different IP address than office traffic
Note: If you have more than one office, give each office its own egress IP. Skedda uses the IP address to tell offices apart.
The Skedda Companion and the Skedda web app connect outbound only, using Hypertext Transfer Protocol Secure (HTTPS) on port 443 to *.skedda.com. Occupancy tracking does not require inbound ports or split tunneling.
Choose your network setup
Find the row that matches your network, then go to its section:
Network setup | Example tools | What to do |
Zscaler, Netskope, Cloudflare One | Assign a dedicated egress IP to each office, or exclude Skedda from the proxy | |
Cisco Secure Client, Palo Alto GlobalProtect, FortiClient | Enter the IP office traffic leaves from, and confirm remote users leave from a different IP | |
Most business broadband plans | Request a static IP address, or enter a range or IPv6 prefix | |
Strict zero trust policies | Route Skedda traffic through a dedicated proxy or tunnel with a fixed IP. Use QR code or manual check-in only if this is not possible |
Cloud security proxy
Cloud security proxies, such as Zscaler, Netskope, and Cloudflare One, route your traffic through the provider's data centers. By default, Skedda sees the provider's shared IP address instead of your office's. A shared IP address can change without notice and can also carry traffic from remote employees and other organizations.
Note: Skedda does not integrate directly with these tools. The tools listed are common examples, and the same steps apply to similar products.
You can configure your proxy in one of two ways. Choose the option your security policy allows.
Option 1: Assign a dedicated egress IP to each office
Most cloud security providers can reserve IP addresses for your organization. To set up a dedicated egress IP:
Ask your provider for a dedicated egress IP for each office.
Configure your proxy to send Skedda traffic through that IP address.
Go to Settings → Occupancy tracking in Skedda.
Enter each office's dedicated IP address.
Use the guidance for your provider:
Zscaler: Select Dedicated IP as the forwarding method in the Zscaler Internet Access (ZIA) Forwarding Control Policy. You can apply it to all traffic or only to *.skedda.com. See ZIA Innovation Launch: Dedicated IP and Granular Geolocalization.
Netskope: Ask your Netskope account team for a dedicated egress IP. Without one, the Netskope egress IP can change every few weeks. See In what scenarios is a steering bypass required.
Cloudflare One: Purchase dedicated egress IPs, or anchor traffic to an IP address you already own with Cloudflare Tunnel. See Egress through Cloudflare Tunnel.
Note: Dedicated egress IPs are often a paid add-on. Check your contract with your provider.
Option 2: Exclude Skedda from the proxy
If your security policy allows it, exclude Skedda from the proxy. Skedda traffic then leaves through your office's own internet connection, and remote employees appear with their home IP address. To exclude Skedda:
Add *.skedda.com as an exception in your proxy.
Find your office's public IP address on your firewall or router.
Go to Settings → Occupancy tracking in Skedda.
Enter the office's public IP address.
Use the guidance for your provider:
Zscaler: Add *.skedda.com as a bypass in your proxy auto-config (PAC) file or forwarding policy.
Netskope: Add skedda.com as a domain exception. See Steering configuration.
Cloudflare One: Add *.skedda.com to Split Tunnels in Exclude mode. See Split Tunnels.
VPN that stays on in the office
Some organizations keep their VPN connected at all times, including on the office network. Occupancy tracking works in this setup if Skedda can tell office traffic apart from remote traffic. To configure it:
Identify the public IP address office traffic leaves from. If office devices connect through the VPN, this is the VPN gateway's IP address, not the office router's.
Confirm that remote VPN users leave from a different public IP address.
Go to Settings → Occupancy tracking in Skedda.
Enter the office egress IP.
Connect a laptop to the VPN from outside the office.
Select the Skedda icon in the menu bar or system tray.
If your setup is correct, the Skedda Companion shows Not yet detected on-site today.
Important: If office and remote VPN traffic share one public IP address, Skedda marks people working from home as seen on-site. If your VPN cannot separate the two, exclude *.skedda.com from the VPN tunnel. Office devices then reach Skedda through the office connection, and remote devices through their home connection.
If every office connects through one VPN gateway, all offices share one IP address. Skedda can confirm that a person was at an office, but not which one.
No static IP address from your internet provider
Many business internet plans assign a public IP address that changes over time. When it changes, Skedda stops detecting people in the office until you add the new address.
Use one of these options:
Request a static IP address or block of addresses from your internet provider. This is the most reliable option.
Enter the range your IP address changes within, in Classless Inter-Domain Routing (CIDR) notation, for example 203.0.113.0/24. Confirm the range with your provider, because a broad range can include other organizations' networks.
Enter your IPv6 network prefix, for example 2001:db8:abcd:12::/64. Device addresses change, but the network prefix usually stays the same. To find your prefix, see Occupancy tracking.
If none of these options is available, update the IP addresses in Settings → Occupancy tracking each time your address changes.
Security policy does not allow IP exceptions
Some zero trust policies prohibit dedicated egress IPs, proxy exceptions, and static IP addresses for general traffic. Many organizations with these policies still route traffic to specific outside services, such as Skedda, through a dedicated proxy or tunnel with a fixed public IP address. This is the recommended setup for occupancy tracking.
To set up a dedicated proxy or tunnel for Skedda:
Create a proxy or endpoint tunnel that carries only traffic to *.skedda.com.
Assign the proxy or tunnel a fixed public IP address for each office.
Confirm that remote devices do not use the same IP address.
Go to Settings → Occupancy tracking in Skedda.
Enter each office's IP address.
A dedicated proxy or tunnel sends only Skedda traffic out through an IP address your organization controls. All other traffic stays under your zero trust policy.
Use the guidance for your setup:
Zscaler: Assign a Dedicated IP to *.skedda.com only, using a destination rule in the Zscaler Internet Access (ZIA) Forwarding Control Policy. See ZIA Innovation Launch: Dedicated IP and Granular Geolocalization.
Cloudflare One: Create an egress policy that sends Skedda traffic through a dedicated egress IP, or route it through Cloudflare Tunnel to leave from an IP address you own. See Egress through Cloudflare Tunnel.
Netskope: Ask your Netskope account team about a dedicated egress IP for specific destinations, then apply it to skedda.com.
Your own proxy: Set up a forward proxy at each office with a static public IP address. Allow only *.skedda.com, then point office devices to it with a proxy auto-config (PAC) file.
Important: Apply the proxy or tunnel to office devices only, or give remote traffic a separate IP address. If remote devices share the office IP address, Skedda marks people working from home as seen on-site.
Without an office IP address, occupancy reporting and automatic check-in based on network presence are not available. If your main goal is to confirm that people show up for their bookings, use one of these check-in methods instead:
QR code check-in: people scan a code at their desk or room when they arrive. See QR code check-in.
Manual check-in: people check in from the web app, mobile app, email, Microsoft Teams, or Slack. See Check-in
Both methods work with any network setup
FAQ
Does Skedda integrate directly with Zscaler or other security tools?
Does Skedda integrate directly with Zscaler or other security tools?
No. Skedda only uses the public IP address your traffic arrives from. Any tool works if your network meets the conditions in What occupancy tracking needs from your network.
Do I need to set up split tunneling?
Do I need to set up split tunneling?
No. Excluding Skedda from your proxy or VPN is one way to separate office and remote traffic. A dedicated egress IP for each office also works.
Why are people working from home shown as seen on-site?
Why are people working from home shown as seen on-site?
Their traffic leaves from an IP address on your office list, usually a shared VPN or proxy IP. See VPN that stays on in the office.
What happens if our office IP address changes?
What happens if our office IP address changes?
Skedda stops detecting people at that office until you add the new address in Settings → Occupancy tracking.
Related articles
