In our application's Production environment, when we call the Navigate operation on our C# WebBrowser control, we POST the authentication details and a redirect URL first to an authentication server. This server authenticates and sends back a HTTP 302 response which prompts the WebBrowser control to redirect to another server. Because of a change in the IP address by the time the redirect is performed, a fingerprint monitor masking the target url sends us a challenge. We then forward the cookies and what not that we received from the authentication server.
Now, the problem is, when we debug this in our non-prod environment, because the client IP remains unchanged, there is no challenge issued by the monitor and we are not able to test out our changes which ensure all the right authenticatoin information is forwarded from the earlier Authentication Server's response.
Is it possible to do this sort of client ip address spoofing in between redirects in order to allow us to test our code? I was using Fiddler for this and as far as I can see, there are no properties which can be modified. the Session variable "x-clientip" is a readonly variable.
How does your server determine the IP address of the client? If it looks at, for instance, an X-Forwarded-For request header, Fiddler can easily change that.
If not, no, Fiddler does not itself have some magical way to make traffic originate from a different IP address. If your machine has multiple NICs, Fiddler can direct the second request to egress via a specific IP address using the X-EgreesIP. Or you can have Fiddler direct a given request through a different proxy (say, another Fiddler instance) running on a different machine that has a different IP address; use the X-OverrideGateway flag to do that.