Browse Prior Art Database

Interception and redirection of TCP sockets by using a VPN connection over a loopback interface and an augmented NAT gateway

IP.com Disclosure Number: IPCOM000241753D
Publication Date: 2015-May-28

Publishing Venue

The IP.com Prior Art Database

Abstract

An improved method for capturing and forwarding data from non-proxy aware applications to proxy servers

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 16% of the total text.

Page 01 of 15

Interception and redirection of TCP sockets by using a VPN connection over a loopback interface and an augmented NAT gateway

Disclosed is a method for the interception and handling of TCP sockets within user-level application code. There are many uses for this, such as virtualising network servers and elements entirely in software, but this invention specifically relates to using this functionality to forward the data inside such sockets through remote proxies (including SOCKS and HTTP proxies). This process is commonly called 'proxifying' connections or applications.

Ordinarily, an operating system provides each application with an interface for creating and accepting socket connections, usually conforming to the POSIX interface standard (see IEEE Std 1003.1). This provides standard applications such as web browsers and web servers facilities with which to open connections to/from standardised remote addresses (ie. domain names, IP addresses, or other types of names which can be resolved by the OS) and send and receive data to and from them. Other options are provided, such as TCP_NODELAY, to provide control over the behaviour over these sockets, but these are heavily limited, and do not provide the flexibility to:


See or intercept connections from other applications

Control flags on each individual TCP packet

This means that ordinarily it is not possible to observe and intercept socket connections made from other applications in order to forward them through SOCKS (or less often, HTTP) proxies if the application hasn't explicitly stated that it wishes to have the socket sent through a given proxy.

Consider the scenario for each of the following three types of applications:

1


Page 02 of 15

Application A

User level code

OS/driver level code

Application B

Application C

Connect to address Connect to address via proxy

Connect to address without specifying proxy

Operating system

TCP packets

TCP packets

TCP packets

Secure remote network


*Connection will fail

Server

Secured server

Proxy

Figure

Figure

111 - Three possible scenarios when applications try to connect to a server with and without a proxy

    - Three possible scenarios when applications try to connect to a server with and without a proxy

Application A connects directly to a server using a standard connection. This is the most common scenario used by normal connections.

Application B connects to a machine in a secure remote network via a proxy. It is aware that it will need to connect to this machine via this proxy and is equipped to handle the proxy protocol and authentication required.

2


Page 03 of 15


Application C is attempting to connect to an application that can only be accessed via a proxy, but is either not aware that this is the case or is unequipped to handle the proxy's protocol or authentication methods. The connection will fail.

The following diagram shows the most common existing solution used to provide connectivity to applications of type C:

S...