Skip to main content

Network Proxy, Content Filter, and SSL Inspection Troubleshooting

What

FileWave clients and Kioskscomponents need reliable network access to the destinations listed in Default TCP and UDP Port Usage. Depending on the workflow, that may include the FileWave Server, FileWave Boosters when used, and specificBoosters, FileWave cloud services.services, vendor services from Apple, Google, or Microsoft, licensing and notification services, remote-control services, cloud Fileset storage, or Kiosk/App Portal download locations. That traffic is encrypted. Proxies, web filters, secure web gateways, firewalls, and content filters can block or alter that traffic, which can cause the affected FileWave communication or Kiosk installationfeature 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, the FileWave feature that depends on that destination may not be able to communicate.

The Kiosk IPA URL https://fw-kiosk-v2-ipas.filewave.cloud/ is one example because blocking it can prevent Kiosk installation. The same principle applies to any FileWave address or vendor address required by the workflow and listed in the port usage article.

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 a FileWave destination from Default TCP and UDP Port Usage being blocked or inspected, such as the FileWave Server hostname, *.filewave.cloud, or fw-kiosk-v2-ipas.filewave.cloud, beingcloud blockedFileset storage, notification services, or inspected.Apple/Google/Microsoft service endpoints.

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

AtUse minimum,Default TCP and UDP Port Usage as the affectedsource devicesof musttruth. beIdentify able to reach their configuredwhich FileWave Servercomponent, addressplatform, onor theworkflow portsis requiredfailing, then verify every destination and port listed for that platformarea. andA workflow. Forblocked Kiosk anddownload cloud-hostedhost components,breaks FileWaveKiosk installation, but a blocked license, notification, remote-control, cloud destinationsFileset, mustApple, alsoGoogle, beMicrosoft, reachable.Server, or Booster destination can break the feature that depends on that traffic.

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.

Examples: blocking the FileWave Server or Booster can break check-in, inventory, manifests, or Fileset downloads; blocking *.filewave.cloud or fw-kiosk-v2-ipas.filewave.cloud can break Kiosk/App Portal downloads; blocking cloud Fileset storage can break hosted Fileset delivery; blocking licensing, notification, TeamViewer/remote-control, AutoPkg, or version-check destinations can break those specific services; and blocking Apple, Google, or Microsoft endpoints can break platform enrollment, app management, software updates, or MDM/EMM workflows.

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 checkexample: Unknown or Uncategorized destinations

In Lightspeed environments, check whether the affected URL is listed as Unknown or blocked by an Unknown / Uncategorized category rule. Apply that check to the FileWave and vendor destinations required by the failing workflow. For FileWave Kiosk 15.3.1 and later, theone followingknown URLexample may need to be recategorized or explicitly allowed:is:

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. If a different FileWave feature is failing, check the corresponding destinations from the port usage article instead of focusing only on the Kiosk URL.

5. Test from the affected network

From macOS or Windows on the same filtered network, test the specific destination that matches the failing workflow. For the Kiosk IPA hosthost, with:for example:

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