Route Shield

Process Level Routing

Routes

Routing is the process of directing network communications to the intended destination. This is normally thought of in the context of the Internet where a packet moves between routers until it eventually reaches its destination. However, the routing of that packet starts before it leaves your system.

Every computer has its own internal route table that guides how packets move within, and ultimately out of, the computer. This route table does not provide a lot of flexibility especially when multiple routes may exist. Generally, the system will use a metric to determine which route is the best to take however, that may not always be the route you desire.

For example, suppose you have two VPN connections running on your computer along with your normal Internet connection. The first VPN is for your work while the second VPN is for your privacy. It's entirely possible that packets intended for your work VPN may leak onto the other connections and vice-versa. This is because of how routing works within the system itself. Some packets, while intended for a specific destination, may end up going another route because it was calculated to be better. And unless the process allows you to specifically set which network to use, you have little control.

Route Shield does away with the internal route tables based on metrics. Instead, Route Shield allows you to configure applications to use the exact network resources that are required.

Route Order

It is important to understand how Route Shield makes its routing decisions. There is an order of precedence that it follows based on configured settings and other available information. In some situations, Route Shield will fall back to default settings while in others it may simply fail the connection.

First, we have to look at all the ways that Route Shield can route packets.

DNS

Route Shield monitors for outbound DNS requests and proxies them to the Route Shield service. The service will determine the calling process and extract the domain. Those two pieces of information are then used to determine the appropriate route and options.

Route Shield will first check if the domain should be sinkholed. If so, the request is just dropped. Next, if DNS caching is enabled then Route Shield looks to see if a valid response based on the time to live (TTL) value is available. If so, it will simply return the result. The next step is to check if the domain has a mapping available. If a provider is mapped, then that is what will be used for the request.

If no domain mapping is found, then Route Shield checks if the process has a configured DNS route. If so, then that will be the provider that will be used. If not, it will finally check if the system-wide settings are enabled. If no system-wide settings are configured then the packet will be resent without any modification.

Once Route Shield has the DNS provider, it will then check if any bindings are set. First it checks if the process has a configured DNS binding. If not, it will check if the system-wide DNS binding is set. If no binding is set, then the system default will apply.

The DNS request is now ready to be routed to the appropriate DOH or DOT server. If it succeeds then the response is parsed and the IP addresses are extracted. These are checked against the sinkhole list and if any one matches, the entire packet is dropped. If none match and if caching is enabled, then the result is added to the cache list.

This process can be seen in this simple flow-chart.

1) Domain sinkhole check
	1a) Drop if match
2) Cached responses
	2a) Return cached response
3) Domain mapping
	3a) Goto binding check (6)
4) Process mapping
	4a) Goto binding check (6)
5) System-wide settings
6) Binding:
	6a) Process binding
		6a1) Goto lookup (7)
	6b) System-wide binding
7) Perform lookup
8) IP sinkhole check
	8a) Drop if match
9) Add response to cache
10) Provide response to original process
					

Note that there are numerous error points within this workflow. Everything from malformed requests and responses to network errors may cause this workflow to fail. If that does occur, Route Shield will simply try to resend the original packet without any modifications.

Proxy

Route Shield has a built-in proxy server designed to route connections to the appropriate destination. For proxying to work, the Route Shield driver will first re-route all new outbound HTTP and HTTPS connections to the Route Shield service. Only HTTP (port 80) and HTTPS (port 443) can be proxied by Route Shield. Process details and information about the request are extracted and is then used to make the routing decision.

Route Shield will first check if the domain has a proxy mapping. If VPN mapping is also enabled, the VPN mapping will also be checked here as well. Route Shield will next check if the process has a defined route. If a process route is set and if no proxy or VPN mapping exists then Route Shield will use the process route details. If either the proxy or VPN process details is not set, then Route Shield will use the system-wide settings for both settings.

If no proxy is set then the connection will continue on as originally intended. And if no VPN is set, then the system default bind point will be used.

VPN

VPN routing works very similar to proxy routing and as discussed, is intertwined with both DNS and proxying.

First, if proxying is enabled, then VPN binding occurs within Route Shield's proxy server and is described above. However, if proxying is not enabled, then VPN routing occurs in the kernel and is based solely on configured process and system settings. There is no domain mapping available in the kernel.

When a process starts, the Route Shield driver checks if a route is configured. If it is, it marks the process so it knows to use the VPN settings when a new binding occurs. When it detects a new binding, it determines the process and will use the saved settings if they were set. If no settings were set, then it will check if the system-wide settings have been set. If no system-wide settings were set, then the binding continues without any modification.