Intro
As I am not a true network specialist but more a security operations specialist, I am always amazed by discovering network things that they probably teach in networking 101 and seem obvious to those in the know.
I had a “revelation” (to me anyways) like that lately.
The details
For all these years I’ve dabbled setting up interfaces, creating static routes, setting up RIP advertisements, reading BGP configurations, solving martian source problems, or slightly harder things like network address translation, secure network address translation and vpn tunnels, I thought I knew all the mainly relevant things there is to know about how to get packets to where you want them.
For a typical, non-routing device, I had always thought that the only choice on how to send packets out is
– local subnet if destination is on a subnet of one of the interfaces
– static route if configured for that destination IP
– default gateway if configured
And that’s that, right?
This limited number of route selection methods is very important in some architectural designs I’ve been involved with. For instance, an Intranet which has “borrowed” large swaths of valid Internet address space pretty much necessitates a two-stage proxy approach if using explicit proxy settings. Or so I thought.
What I learned
Someone pointed out to me a feature on Bluecoat proxy called return-to-sender. Normally it is disabled. But when enabled, what it does is (to me, because I never thought it possible) amazing: it sends its response packets back to the MAC address of the inbound sender! Thus it will shortcut all the routing decisions mentioned above and use the MAC address of the host which sent it a packet to which it is responding.
If I had know that was possible I might never have implemented a two-stage proxy.
I decided to try the ultimate worst-case scenario:
– use of proxy with this feature enabled and
– proxy client on same internal subnet as proxy server, 10.11.12.0/24
– source IP of proxy client = my AWS server, 50.17.188.196
– requested web site: my AWS web site at http://50.17.188.196/
In other words, steal my own IP, put it on the Intranet, and make the proxy route packets back to me in response while simultaneously connecting to that exact same IP on the Internet.
How I configured the VIP
This is very old school, but I did one of these numbers ona SLES11 system:
$ sudo ifconfig eth0:0 50.17.188.196 up
And that was sufficient to add that IP to the eth0 interface.
Did it work? Yes, it did. Amazing.
I only needed one single request to verify that it worked. Here is that request, using wget from the Linux host which is on the same subnet.
export http_proxy=http://10.11.12.13:8080/ wget --bind-address=50.17.188.196 http://50.17.188.196/ |
And the proxy log line this produced:
2014-08-04 13:55:08 3 50.17.188.196 - "none" 200 TCP_HIT GET text/html http 50.17.188.196 80 / - - "Wget/1.11.4" OBSERVED 10.11.12.13 769 158 - - |
Other appliances can do this, too
On F5 BigIP this feature is also supported. It is called auto last hop and can be configured either globally or for an individual virtual server.
To be continued…