Skip to main content

Network Proxy, Content Filter, and SSL Inspection Troubleshooting

What

FileWave clients and Kiosks need reliable network access to the FileWave Server, FileWave Boosters when used, and specific FileWave cloud services. That traffic is encrypted. Proxies, web filters, secure web gateways, firewalls, and content filters can block or alter that traffic, which can cause FileWave communication or Kiosk installation to fail even when the FileWave Server itself is working correctly.

This can happen with products such as Lightspeed Filter, GoGuardian Admin, Securly Filter, Linewize Filter, ContentKeeper, iboss, Cisco Umbrella, Zscaler Internet Access, Netskope, Fortinet/FortiGate, Palo Alto Networks, Sophos Firewall, WatchGuard, Check Point, and similar proxy or filtering systems. The exact product name is less important than the behavior: if the product blocks the required host, blocks an unknown or uncategorized URL, or performs SSL/TLS inspection on traffic that must remain end-to-end trusted, FileWave may not be able to communicate.

When/Why

Use this article when FileWave behavior changes depending on the network, filtering policy, or proxy path. Common examples include:

  • The FileWave Client checks in on one network but not another.
  • Devices stop reporting inventory or processing manifests.
  • The FileWave Kiosk or App Portal does not appear or does not install.
  • iOS/iPadOS Kiosk installation fails with an error like:
Could not validate manifest..An SSL error has occurred and a secure connection to the server cannot be made.
  • A content filter shows FileWave URLs as blocked, uncategorized, unknown, newly seen, or unclassified.
  • Security logs show the FileWave Server hostname, *.filewave.cloud, or fw-kiosk-v2-ipas.filewave.cloud being blocked or inspected.

FileWave communication relies on encrypted, certificate-based connections. On macOS and Windows, modern FileWave Client communication uses mutual TLS for client/server trust. Apple, Google, Microsoft, and FileWave cloud services also expect valid TLS connections. If a filtering product performs SSL inspection, HTTPS inspection, TLS inspection, SSL decryption, certificate inspection, deep packet inspection, DPI, or a similar feature that replaces the remote certificate with a filtering certificate, the connection may fail because the device is no longer seeing the certificate it expects.

This is not limited to one vendor. Lightspeed is a common example in schools, and Lightspeed environments that block Unknown or Uncategorized sites may block a FileWave cloud URL until it is recategorized or explicitly allowed. Other web filters and secure web gateways can create the same symptom under different names.

How

1. Confirm whether the filter or proxy is involved

Start by comparing a working and failing path.

  • Test the affected device on a network that does not use the same proxy or content filter, such as a known-good test VLAN or temporary hotspot.
  • Check the proxy, firewall, or web-filter logs for the affected device at the time of failure.
  • Look for blocked or inspected traffic to the FileWave Server hostname, FileWave Booster hostname, FileWave cloud URLs, Apple services, Google services, or Microsoft services used by the platform.
  • If only one network or policy fails, the issue is likely in the network path rather than the FileWave Server itself.

2. Allow the required FileWave destinations

At minimum, the affected devices must be able to reach their configured FileWave Server address on the ports required for that platform and workflow. For Kiosk and cloud-hosted components, FileWave cloud destinations must also be reachable.

Common destinations to review include:

  • The customer’s FileWave Server hostname or FQDN used by clients and enrolled devices.
  • Any FileWave Booster hostnames used by clients.
  • *.filewave.cloud
  • https://fw-kiosk-v2-ipas.filewave.cloud/
  • Hosted-customer cloud Fileset storage destinations listed in Default TCP and UDP Port Usage, when applicable.
  • Apple, Google, and Microsoft endpoints required for the platform being managed.

Do not rely only on a port being open. Category-based filtering can still block an allowed port if the destination is classified as unknown, uncategorized, newly registered, or otherwise not allowed by policy.

3. Bypass SSL/TLS inspection for FileWave management traffic

For FileWave Client, Kiosk, MDM, and FileWave cloud traffic, allow the traffic without certificate replacement or HTTPS decryption.

Depending on the product, this setting may be called:

  • SSL inspection
  • SSL decryption
  • TLS inspection
  • HTTPS inspection
  • HTTPS proxy/content inspection
  • Certificate inspection
  • Deep packet inspection or DPI
  • Secure web gateway inspection
  • Man-in-the-middle inspection

The goal is the same: FileWave-managed devices must see the real certificate presented by the FileWave Server or cloud service, not a substitute certificate generated by the filtering product.

4. Lightspeed-specific check

In Lightspeed environments, check whether the affected URL is listed as Unknown or blocked by an Unknown / Uncategorized category rule. For FileWave Kiosk 15.3.1 and later, the following URL may need to be recategorized or explicitly allowed:

https://fw-kiosk-v2-ipas.filewave.cloud/

If Lightspeed is blocking this URL, the Kiosk installation may fail with a manifest validation or SSL error even though other FileWave functions appear normal.

5. Test from the affected network

From macOS or Windows on the same filtered network, test the Kiosk IPA host with:

curl -Iv https://fw-kiosk-v2-ipas.filewave.cloud/

A successful connection should complete a TLS handshake and return an HTTP response from the destination. A failure may show certificate validation errors, proxy-generated certificates, connection resets, block pages, authentication prompts, or timeouts.

For iOS/iPadOS, use the filter logs and a browser test from the same network or policy where possible. The device may not expose the same command-line testing tools, so the proxy/filter logs are often the best evidence.

6. Retest FileWave behavior

After updating allow/bypass rules:

  • Retry the FileWave Kiosk or App Portal installation.
  • Force or wait for the FileWave Client to check in.
  • Confirm inventory, manifests, and Fileset downloads behave normally.
  • Review filter logs again to verify the FileWave traffic is allowed and not being decrypted.

Related Content

Digging Deeper

A proxy or content filter can break FileWave communication in more than one way:

  • Blocking the destination entirely because the URL is unknown, uncategorized, or not in an allowed category.
  • Allowing the destination but replacing the TLS certificate during inspection.
  • Allowing browser traffic but blocking background service traffic from the FileWave Client or Kiosk.
  • Allowing the FileWave Server but blocking a separate cloud host used for Kiosk, cloud Filesets, license checks, notifications, or other supporting services.
  • Applying different rules to macOS, Windows, iOS/iPadOS, Android, ChromeOS, or guest networks.

When troubleshooting, avoid assuming that “the internet works” means FileWave traffic is allowed. FileWave services may use different ports, hostnames, certificate trust behavior, and background processes than a normal browser session.

If the issue is urgent, temporarily placing one affected test device on a less-filtered network can quickly separate FileWave Server problems from proxy/filter policy problems. If the device works immediately outside the filtered path, focus on proxy allow rules, category rules, and SSL/TLS inspection bypasses.

Back to top