BGP Multipath & return routes

Question

I'm probably a complete n00b concerning serverfault related questions, but our IT department makes a bold statement I wish to verify. I've searched the internet, but can find nothing related to my question, so I come here.

We have Threat Management Gateway 2010 and we used to just route the request to IIS and it contained the ip address so we could see where it was coming from. But now they turned on "Requests apear to come the TMG server" so ip addresses aren't forwarded anymore. Every request has the ip of the TMG server.

Now the idea behind this is that because of multipath bgp routes, the incoming request goes over RouteA, but the acknowledgement messages could return over RouteB. The claim is that because the request doesn't come from the first known source, our proxy, but instead from IIS, some smart routers at the visitor of our websites don't recognize the acknowledgement message and filter it out. In other words, the response never arrives.

Again, this is the claim. But I cannot find ANY resources on the internet that support this claim. I do read about bgp multipath, but more in the case that there are alternative routes when the fastest route fails for some reason.

So is the claim completely bogus or is there (some) truth to it? Can someone explain or point me to resources?

Thanks in advance!

Answer 1

That kind of asymmetric routing does indeed happen fairly often on the internet. A given BGP router can have a multitude of local preference rules as well as a different perspective on a path and which peers it prefers to use. An internet router doesn't know or care which pipe a session came through, and it doesn't matter either; as long as the packet gets to its destination, everything is working fine.

But, that behavior has nothing whatsoever to do with the communication between your web server and the TMG proxy.

The issue with the explanation is here:

request doesn't come from the first known source, our proxy, but instead from IIS

If this were true, then all connections to the web server would unconditionally fail. The client connects to the IP address of the proxy, and expects response traffic from the same address - the IIS server being the source IP of response traffic (skipping TMG) would get the response traffic rejected.

The reason it works correctly for TMG to have the apparent source of the connection be the "real" client, is that TMG sits in-line in front of your web server (it only works if TMG is in line, acting as your router). TMG sees the response traffic from your web server bound for the client address, catches it, and sends it on to the client via the correct connection (the one the client initiated to TMG).

So, basically, BGP and internet routing has nothing to do with it, but a similar kind of asymmetric routing on your internal network (where the TMG device isn't used to route the response traffic) would break connections from web clients and necessitate using the TMG IP address as the apparent connection source. Maybe they're planning a topology change?