Transparent proxying

A complete firewall solution usually not only includes IP packet filters, but also some type of application-level proxy servers. Unfortunately, many proxying techniques need software modifications at the client side (think of SOCKS) or change the user-interface, requiring users to become proxy-aware. For this reason, the concept of transparent proxying was introduced in some of the more modern firewalls. This not only relies on special user-level software (modified proxy servers), but it also requires kernel-level support, which is now included in Linux. Transparent proxying redirects sessions passing the firewall to local proxy servers in a fully transparent way. Clients (both software and users) do not know their session is handed over to a proxy process: they still think they have a direct connection with the target they specified. Because it relies on port numbers, transparent proxying only works for TCP or UDP traffic.

In the Linux kernel, packet redirection for transparent proxying is mainly handled by the input firewall. An introductory example:

   ipfwadm -I -a accept -r 2323 -P tcp -S 192.168.37.0/24 \
            -D any/0 telnet

This command redirects (-r option) all telnet sessions originating from the 192.168.37.0 network to a local (proxy) telnet server, listening on port 2323. When no port (or port 0) is specified with the -r option, the port number of the original destination will be used as target port on the local host:

   ipfwadm -I -a accept -r -P tcp -S 192.168.37.0/24 \
            -D any/0 smtp www gopher z3950

Now all incoming sessions using one of the specified protocols will be redirected to servers on the local host, using the original port number. These servers usually have to be specially prepared proxy servers. We will not discuss the general concept of proxy servers here, but only introduce the techniques available for changing existing proxies intro transparent ones. For TCP sessions, these techniques include:

• The original destination (IP address and port number) can be requested via the getsockname(2) system call. The returned sockaddr structure will contain information about the originally specified target, not about the local host.
• Packets sent back via the accepted socket will automatically carry the original destination address and port as sender address. So, the client will think the packet comes from the original target.
• A server may (given it has appropriate privileges) also explicitly bind a socket to a port with an external IP-address. This will cause packets for that address (and port) to be redirected to that local server, without a separate firewall rule.

For UDP, the situation is a bit more complex, especially because the getsockname system call can not be used:

• For use in UDP proxy servers, two macros have been defined for sending and receiving proxied UDP packets. They can be found in the file /usr/include/sys/socketproxy.h.
• The macro recvfromto is essentially equal to the recvfrom(2) system call, except that it takes two extra parameters of type (struct sockaddr *) and (int *), respectively. In this second sockaddr structure, the original destination of the packet will be stored, so the proxy server knows where the packet was sent to.
• In a similar way, the macro sendtofrom is a wrapper for the sendto(2) system call, also having two extra parameters of type (struct sockaddr *) and (int *), respectively. In this second sockaddr structure, the desired (fake) source address can be given, so the client thinks the packet is coming from there.

With these few interfaces, it is fairly simple to modify an existing proxy server to be transparent.

Note that redirecting packets to other systems requires user-level software. Such a function can be implemented by redirecting the packets to a local server acting as a simple packet-forwarder.