Common issues
Common issues that can occur with the firewall and throttling features in the SDK, the underlying causes, and recommended solutions.
Browser Caching and Connection Behavior
Most issues with the SDK's firewall and throttling features stem from how browsers cache data and manage connections. Understanding browser behavior is key to troubleshooting these issues.
Caching
Browsers utilize local caches extensively to improve performance. A browser will often serve a response from its cache rather than requesting fresh data from the server. To ensure the SDK's features are applied to the latest data, it's recommended to refresh the page and clear the cache using Ctrl+F5 or Shift+F5.
TCP Connections
Browsers maintain TCP connections when they expect the connection to be reused soon. In this state, the browser will not resolve DNS addresses, preventing the SDK from obtaining the domain IP addresses. Additionally,Netfilter cannot affect any existed TCP connections and Browser will have a way to avoid Bypass or Route via VPN rules for some time. As a result, the browser may be able to bypass firewall rules for some time. The only guaranteed solution is to completely close and reopen the browser.
DNS Resolution
Some browsers and external applications employ protocols like DNS-over-TLS to obfuscate DNS resolution. In these cases, the SDK cannot obtain the resolved addresses, causing Domains bypass or Route via VPN to fail. The SDK also cannot rely on utilities like nslookup because a single domain may have many IP addresses that can change between lookups.
Configuring Domain Bypass
A common issue occurs when the client application only adds the primary domain to the bypass list. However, subdomains may point to different servers or applications than the primary domain. To comprehensively bypass a domain, it's recommended to use two rules:
This will bypass the main domain and all its subdomains. Avoid overly broad patterns like *example.com which would unintentionally bypass domains like notexample.com.
Process Bypass and the Killswitch Module
Process bypassing is straightforward but can behave unexpectedly when used in conjunction with the Killswitch module. The Windows Filtering Platform (WFP) used by the Killswitch requires the full path to the executable, while the SDK's Netfilter component matches against just the executable name.
As a result, bypassing chrome.exe will work as expected when the Killswitch is disabled, but the browser will be blocked when the Killswitch is enabled. To avoid this, always specify the full path to the executable in process bypass rules. This also prevents unintentionally bypassing all applications with the same executable name.
Route via VPN Compatibility
When using Route via VPN mode, it's important to understand how it interacts with other VPN modules to ensure proper configuration and avoid blocked traffic. In Route via VPN mode, all traffic is sent through the main adapter, while only filtered traffic passes through the VPN tunnel.
While the SDK allows activating Route via VPN together with the Prevent IP Leak and Killswitch modules, these configurations are not actually compatible. The SDK will do exactly what the client app instructs, even if those instructions lead to conflicts. Activating incompatible modules together can lead to unintended consequences.
Another common issue arises when the client app activates both Route via VPN and Bypass modules for the same processes or domains. In this scenario, one module blocks traffic through the VPN adapter while the other blocks traffic through the main adapter. As a result, traffic will be blocked regardless of which module attempts to forward it.
To avoid blocked traffic, the client app should disable Manual Bypass modules before connecting with active Route via VPN. Failing to do so will cause traffic to be blocked by the incompatible rules.
Route via VPN modules have the same common issues with Bypass modules.
How Throttling Affects Connections
Throttling is a technique used to intentionally slow down network traffic. It's important to understand that when throttling rules are applied, they only affect new connections established after the rules are put in place. Any existing connections will continue operating at their original unthrottled speeds.
This means that if an application is holding open TCP connections when throttling is activated, those specific connections will not be subject to the speed limitations. The most common way this scenario occurs is with speed test services run in web browsers like Google Chrome. If the speed test was initiated before throttling started, the browser will maintain its existing connections to complete the test at the unthrottled rate.
Web browsers, particularly Chromium-based ones like Chrome, are designed to reuse connections for efficiency when a user frequently refreshes the same page. As a result, simply refreshing will often not force the browser to establish a new connection that would be subject to the throttling rules.
To ensure throttling is applied to all connections, users need to manually close or break the existing ones. The most reliable way to do this is to completely restart the browser. If restarting is not desirable, an alternative is to refresh the page after clearing the browser cache. Note that the refresh method is less consistent with Chromium browsers but tends to work well with Firefox.
Last updated