Back to Basics: The Many Modes of Proxies

Lori MacVittie, 2013-09-12

The simplicity of the term "proxy" belies the complex topological options available. Understanding the different
deployment options will enable your proxy deployment to t your environment and, more importantly, your applications.

It seems so simple in theory. A proxy is a well-understood concept that is not peculiar to networking. Indeed, some folks
vote by proxy, they speak by proxy (translators), and even on occasion, marry by proxy.

A proxy, regardless of its purpose, sits between two entities and performs a service. In network architectures the most
common use of a proxy is to provide load balancing services to enable scale, reliability and even performance for
applications. Proxies can log data exchanges, act as a gatekeeper (authentication and authorization), scan inbound and
outbound trafc for malicious content and more. Proxies are a key strategic point of control in the data center because
they are typically deployed as the go-between for end-users and applications. These go-between services are often
referred to as virtual services, and for purposes of this blog that's what we'll call them. It's an important distinction
because a single proxy can actually act in multiple modes on a per-virtual service basis.

That's all pretty standard stuff. What's not simple is when you start considering how you want your proxy to act. Should
it be a full proxy? A half proxy? Should it route or forward? There are multiple options for these components and each
has its pros and cons. Understanding each proxy "mode" is an important step toward architecting a suitable solution for
your environment as the mode determines the behavior of trafc as it traverses the proxy.

Standard Virtual Service (Full Application Proxy)

The standard virtual service provided by a full proxy fully terminates the transport layer connections (typically TCP) and
establishes completely separate transport layer connections to the applications. This enables the proxy to intercept,
inspect and ultimate interact with the data (trafc) as its owing through the system.

Any time you need to inspect payloads (JSON, HTML, XML, etc...) or steer requests based on HTTP headers (URI,
cookies, custom variables) on an ongoing basis you'll need a virtual service in full proxy mode.

A full proxy is able to perform application layer services. That is, it can act on protocol and data transported via an
application protocol, such as HTTP.
A full proxy is able to perform application layer services. That is, it can act on protocol and data transported via an
application protocol, such as HTTP.

Performance Layer 4 Service (Packet by Packet Proxy)

Before application layer proxy capabilities came into being, the primary model for proxies (and load balancers) was layer 4
virtual services. In this mode, a proxy can make decisions and interact with packets up to layer 4 - the transport layer. For
web trafc this almost always equates to TCP. This is the highest layer of the network stack at which SDN architectures
based on OpenFlow are able to operate. Today this is often referred to as ow-based processing, as TCP connections
are generally considered ows for purposes of conguring network-based services.

In this mode, a proxy processes each packet and maps it to a connection (ow) context. This type of virtual service is
used for trafc that requires simple load balancing, policy network routing or high-availability at the transport layer. Many
proxies deployed on purpose-built hardware take advantage of FPGAs that make this type of virtual service execute at
wire speed.

A packet-by-packet proxy is able to make decisions based on information related to layer 4 and below. It cannot
interact with application-layer data. The connection between the client and the server is actually "stitched" together in
this mode, with the proxy primarily acting as a forwarding component after the initial handshake is completed rather than
as an endpoint or originating source as is the case with a full proxy.

IP Forwarding Virtual Service (Router)

For simple packet forwarding where the destination is based not on a pooled resource but simply on a routing table, an
IP forwarding virtual service turns your proxy into a packet layer forwarder.

A IP forwarding virtual server can be provisioned to rewrite the source IP address as the trafc traverses the service. This
is done to force data to return through the proxy and is referred to as SNATing trafc. It uses transport layer (usually
TCP) port multiplexing to accomplish stateful address translation. The address it chooses can be load balanced from a
pool of addresses (a SNAT pool) or you can use an automatic SNAT capability.

Layer 2 Forwarding Virtual Service (Bridge)

For situations where a proxy should be used to bridge two different Ethernet collision domains, a layer 2 forwarding
virtual service an be used. It can be provisioned to be an opaque, semi-opaque, or transparent bridge. Bridging two
Ethernet domains is like an old timey water brigade. One guy lls a bucket of water (the client) and hands it to the next
guy (the proxy) who hands it to the destination (the server/service) where it's thrown on the re. The guy in the middle
(the proxy) just bridges the gap (you're thinking what I'm thinking - that's where the term came from, right?) between the
two Ethernet domains (networks).
F5 Networks, Inc. | 401 Elliot Avenue West, Seattle, WA 98119 | 888-882-4447 | wwww.f5.com
F5 Networks, Inc. F5 Networks F5 Networks Ltd. F5 Networks
Corporate Headquarters Asia-Pacific Europe/Middle-East/Africa Japan K.K.
info@f5.com apacinfo@f5.com emeainfo@f5.com f5j-info@f5.com

2015 F5 Networks, Inc. All rights reserved. F5, F5 Networks, and the F5 logo are trademarks of F5 Networks, Inc. in the U.S. and in certain other countries. Other F5
trademarks are identified at f5.com. Any other products, services, or company names referenced herein may be trademarks of their respective owners with no endorsement or
affiliation, express or implied, claimed by F5. CS04-00015 0113