Tracking Reverse Proxy Requests with Multiple Interfaces
Ok, so here's my situation, and I'm hoping someone can help me out. We have a box doing reverse proxying via Apache to our OWA server, since only a crazy person would expose a Winows box to the internet . The reverse proxy has 2 NICs, one on the untrusted network and one on the trusted network, with different IPs and in different subnets. I'm trying to build a rule to track logins to OWA with the true source IP. Problem is, the OWA IIS server only sees the reverse proxy's trusted IP, and the reverse proxy doesn't see the username since this is put into the logs by IIS. My solution was to build a rule that looks for a POST to /owa/auth.owa on the reverse proxy and corresponding IIS server (4 reverse proxies and 4 OWA servers, btw, in a round robin load balance) since the sourceAddress on the IIS server would be the deviceAddress on the reverse proxy and they'd be within a few seconds of each other so I can reasonably assume they're from the same authentication attempt.
So here's my dillemma. The untrusted IP != the trusted IP, and the Apache server logs only put the IP that the request was sent to, which would be the untrusted IP, but IIS sees the trusted IP. The solution I thought would work would be to use the AssetId and assign the corresponding alternate interfaces to each reverse proxy (RP's deviceAssetId = IIS's sourceAssetId) - but alas, it appears to still use the AssetId of the asset to which the IP corresponds to.
Anyone got any ideas? Can someone think of a better solution, or am I doing the alternate interface wrong? The only other solution I could think of is to use an ifthenelse operation in the Apache connector to replace all the untrusted IPs with trusted IPs.
What might work is setting up an active list based on key fields, which excist out of ip adress and proxy name. Fill the active list with the trusted and untrusted ipadress and have the same name for the proxy name on both ip adresses. Use get activelist variable to retrieve the proxy name and use that in the join condition.
I have not tried it myself, but should be working.
Unfortunately, the AL wouldn't work because I need it to actually be pulled in with the event. However, your idea gave me an idea that worked perfectly - use a custom map file that maps the internal IP to another field and just key off of that.
In the end, what I've done (in case anyone else ever deals with this) is revised my flexconnector to map the untrusted IP to destinationAddress and I'm using a custom mapping file to map the trustedIP to the deviceAddress field since this is allows for a more accurate picture since the public IP will be the one that's "targeted".
The KISS rule claims another victory. Thanks for the idea!