How to tamper with source IP address on Windows

Question

Hi folks:

We meet a testing scenario which needs to tamper with source IP address of a Http request to simulate clients coming from different countries. Do you know any tool help on this?

Last but not least, our web site is built with ASP.NET.

Thanks.

Answer 1

That's not possible. Because when you forge the ip address, the response is never going to come back, which is required for http.

The best way is to use proxies. See also this question on serverfault.

Answer 2

As noted in answers to the ServerFault question "Are IP addresses trivial to forge", you cannot easily forge source addresses in a protocol that required two way communication (e.g. TCP). Note that this "two way communication" is required at the packet level. You cannot just say "no problem, I want to send requests and ignore HTTP responses." To establish a TCP session, you need to receive data. Your best bet is to use a proxy server.

Answer 3

If you change your source IP address, that means no traffic from your web server will be able to reach back to the client.

You might be able to use some kind of proxy and/or address translation filter to do the remapping while still allowing two-way communication.

Answer 4

I am unsure if the IP standard allows for this, but if you are working in a Lab environment, where you don't need internet connectivity during the test, I can see it working under following circumstances:

Basically, I would set the server's network interface to use netmask 0.0.0.0 and flush the rest of the routing table.

Then you could configure a client machine to take on any IP address as long as you use netmask 0.0.0.0. And two-way communication should be possible.

Server[1.2.3.4/0] <---> Client[x.x.x.x/0]

But please bear with me. I haven't tested this, so I could be wrong :-)

Answer 5

In a test environment it usually isn't difficult. First read this SO question about virtual network interfaces.

If the server and client are on the same machine, all you have to do is figure out how to get your client software to bind to your virtual interface. wget for instance has the --bind-address option to specify which local address to bind to. Web browsers are a bit more difficult to do this with; you may need to just run it in a VM.

If your server and client are on the same LAN, you just need to configure your router with some static routes to your client machine. In this case you probably don't need a virtual network interface, just set a static IP for your client machine; as long as the gateway is set up correctly it should be able to send packets to the server, and as long as the route is set up correctly the replies should find their way back to the client.

If the client and server are separated by an internet, it's rather more difficult. One option is to set up a network tunnel endpoint on the server and tunnel it to the client machine, which "knows" that it has the virtual network interface.

Answer 6

If you have access to your infrastructure, you can add an interface off the router and then place a static route on the router to that network.

Server-----Router----Internet
            /
Test_PC----/

Alternatively you can look into PBR (Policy Based Routing) and on the routers you can flag source packets and change the source on the fly, so your server will think they are coming from where you'd like them to come from.

Server-------------Router_with_PBR-------------Internet----- PC
SCR:4.2.2.2        Change SCR:6.6.6.6 to 4.2.2.2              6.6.6.6

But you have to ask yourself why do you want to see when packets come from different countries. Some countries have massive proxy servers that filter access ( "Great Firewall of China"), so the above tests will not prove much.

Your best bet then is using proxy servers or if your looking for a long term solution then setup a server (virtual is great for this) and use RDP for testing. I'm sure you can rent a virtual server somewhere for a month or two.