When a user selects a Defend-rewritten link, Defend's link-rewriting feature scans the link in real time before sending the user to its destination. If your network security tools inspect this traffic, the scan can fail and leave the user on a blank page. This article explains why that happens and how your IT team can fix it.

Symptoms

Users who select Defend-protected links are redirected to a blank white page instead of the intended destination. You may notice the following:

• The issue is intermittent. Refreshing the page multiple times sometimes lets the link through.
• The behavior is consistent across browsers, including Chrome and Edge.
• The issue does not resolve when you clear the browser cache or cookies.

Cause

Defend's link-rewriting feature uses a WebSocket connection to links.us1.defend.egress.com (part of the *.defend.egress.com domain) to scan links in real time. If a network proxy or Domain Name System (DNS) security tool performs Secure Sockets Layer (SSL) inspection (HTTPS decryption) on this traffic, the WebSocket upgrade handshake breaks. This causes the following chain of events:

1. The initial /_blazor/negotiate request completes successfully.
2. The WebSocket connection fails silently.
3. The fallback long-poll connection is invalidated almost immediately with a "404 Not Found" error.
4. The scanning page stalls and shows a blank white page.

This behavior has been observed with Cisco Umbrella and Palo Alto Networks firewalls performing SSL inspection. Because the cause is at the network level, no client-side troubleshooting step will resolve it until your IT team excludes Defend's scanning endpoint from SSL inspection.

Fix

Configure your proxy or DNS security tool to bypass SSL inspection for *.defend.egress.com (or, at minimum, links.us1.defend.egress.com).

Wildcard Domain Recommendation

We recommend excluding the wildcard *.defend.egress.com rather than only the specific subdomain links.us1.defend.egress.com. Excluding the wildcard keeps your configuration valid if KnowBe4 updates the endpoint hostname in the future, such as during a rebrand or regional expansion.

If your policy tool does not support wildcards, use links.us1.defend.egress.com as your entry for now, and watch for any KnowBe4 communications about endpoint changes.

Cisco Umbrella

To bypass SSL inspection in Cisco Umbrella, follow the steps below:

1. Log in to the Cisco Umbrella Cisco Umbrella (link opens in new window) dashboard.
2. Click Policies, then select SSL Decryption Policy (or Intelligent Proxy, then select SSL Decryption).
3. Add a Do Not Decrypt rule for the destination *.defend.egress.com.
4. Position the rule above any catch-all decrypt rules.
5. Save the policy and allow time for it to propagate.

Palo Alto Networks Firewall

To bypass SSL inspection in your Palo Alto Networks firewall, follow the steps below:

1. In the Palo Alto Networks Palo Alto Networks (link opens in new window) console, click Objects, then select Decryption Profiles.
2. Add *.defend.egress.com to the SSL exclusion list, or create a No Decrypt policy rule that targets this destination.
3. Commit the configuration.

Other Proxies

If you use a different proxy or firewall, bypass SSL inspection as follows:

1. Add *.defend.egress.com to your proxy's SSL inspection exclusion or bypass list.
2. Make sure that WebSocket (Upgrade: websocket) traffic to this domain passes through unmodified.