Network Proxy, Content Filter, and SSL Inspection Troubleshooting

What

FileWave components 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, FileWave cloud 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 feature 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, fw-kiosk-v2-ipas.filewave.cloud, cloud Fileset storage, notification services, or 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. Map the symptom to the FileWave feature

Before changing proxy or firewall rules, identify which FileWave feature is failing. Then use Default TCP and UDP Port Usage to find the destinations and ports used by that feature.

A browser test is useful, but it is not the whole test. FileWave background services may run outside the user’s browser session, may not be able to answer a proxy authentication prompt, and may use ports or TLS behavior that a browser test does not exercise.

2. 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.

3. Allow the required FileWave destinations

Use Default TCP and UDP Port Usage as the source of truth. Identify which FileWave component, platform, or workflow is failing, then verify every destination and port listed for that area. A blocked Kiosk download host breaks Kiosk installation, but a blocked license, notification, remote-control, cloud Fileset, Apple, Google, Microsoft, 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.

4. Check common proxy/filter failure patterns

Proxies and filters can break FileWave traffic in several different ways. Check for all of these, not just a simple block/allow result:

• Category or reputation blocking: the destination is marked unknown, uncategorized, newly seen, or not in an allowed category.
• SSL/TLS interception: the filter replaces the real certificate with its own certificate so the device no longer trusts the connection.
• Authenticated proxy or captive portal requirements: browser traffic works after a user signs in, but FileWave background services cannot answer the prompt.
• Transparent proxy behavior: the proxy handles normal web browsing but not FileWave service traffic, NATS, Booster traffic, or other non-browser connections.
• DNS or SNI filtering: the device resolves or reaches a different path than expected, or the filter blocks based on hostname before the connection is established.
• Different rules by network, VLAN, device type, user group, time, or off-site/on-site policy.

5. Bypass SSL/TLS inspection for FileWave management traffic

For FileWave Client, Kiosk, MDM, Booster, and FileWave cloud traffic, allow the traffic without certificate replacement or HTTPS decryption. For Apple, Google, and Microsoft services used by managed-device workflows, follow the vendor network guidance and avoid inspection where the vendor requires direct TLS trust.

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.

6. Lightspeed-specific example: 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, one known example 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.

7. 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 host, 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.

8. 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.

9. If it still fails, collect evidence before escalating

If the traffic still fails after allow and inspection-bypass rules are updated, collect enough detail to show where the failure occurs:

• The affected FileWave feature, platform, and device name or serial number.
• The network, VLAN, proxy/filter policy, and whether the same device works on another network.
• The timestamp of the failure and the corresponding proxy/firewall log entry.
• The blocked destination, category, action, and whether SSL/TLS inspection was applied.
• Any command output, such as curl -Iv, showing the connection, certificate, block page, reset, timeout, or proxy-generated response.
• Relevant FileWave Client, Kiosk/App Portal, or MDM logs for the same time window.

Related Content

• Default TCP and UDP Port Usage
• How the FileWave Client Communicates
• Resolving SSL and Manifest Validation Errors with FileWave Kiosk Installation (15.3+)
• Bypassing DPI for Apple Traffic in MDM Communication
• Customer Technical Support