Sometimes when building Firewall rules in a big network it's difficult to tell what will happen to routing and inside a firewall just by looking at the rules.  In many cases somebody wants a server with some IP Address to talk to another server somewhere on the network.  The best thing to do is traceroute, or telnet to the service ports from the source host and see what the firewall does with the traffic.  Does it ever see the packet?  If so does it allow or block it?

This becomes more difficult when you don't have access to the source host, and/or the people in charge of it are unwilling/unable to run a trace.  As in maybe they don't know how or just don't respond to your questions in time.  If you try to explain 'telnetting to a port' it can confuse a lot of DBA's  :-O

So here's the next best thing - you can try it yourself, but "spoof" the source IP address of the request.  Your packet will travel to the destination if routing allows it. The firewall will see traffic appearing to come from the real source host. You will never see a response because responses will go to the "spoofed" IP address, but you can examine the firewall logs to see what happened as though the traffic was real.

At work I don't always have access to a Unix shell so I run NMAP from Windows.  Here are the steps to make it happen.

First if you try NMAP by spoofing the source IP but not identifying which interface you're using NMAP will complain.  The next trick is to figure out your interface ID.  What if you have several?  My laptop has WiFi and wired Ethernet, plus VM and VPN adapters which makes for a whole bunch of "interfaces."  I want to see which is my default, so I use ipconfig.

C:\>ipconfig /all

This will spit out all of your interfaces.  Look for your IP address and note the MAC address. Note the (Preferred) tag - this is your default interface, in my case the Ethernet adapter.


Noting the MAC and IP addresses, run NMAP to list your interfaces.

C:\>nmap --iflist

Here's the interface I want to use, identified by the IP address assigned to the NIC.  From the example, I'll be using the interface known to Windows as eth7.





Now you can run your spoofed scan using NMAP.  Say I want to pretend my source address is 10.154.14.138, and my destination address is 10.25.17.45.  I know that my Ethernet NIC is called eth7 so:

C:\>nmap -e eth7 -S 10.154.14.138 10.25.17.45

-e  = interface
-S  = Specify source (+ address)
destination address 




NMAP, as expected, responds with no luck.

Starting Nmap 5.51 ( http://nmap.org )
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.91 seconds

Why is this expected?
This is expected because routers are stupid.  What I mean by that is: routers don't know anything except what they're told.  Routers don't ever know the actual source address of any packet, they rely on that information to always be inside the packet.

In the IP protocol, the source and destination address is always inside every packet.  All of them!  This is the whole point of Internet Protocol.  It is designed this way on purpose, to ensure traffic can arrive where it's supposed to by any route, because the routing information is inside every packet.

I changed my source address to be something else, so as far as any other device or server is concerned that's where responses will be sent.  Since all replies go to an address other than my own I will by definition never see any reply.

That return traffic may or may not end up somewhere real.  In fact, sending requests with a forged source address that is actually a real device someplace else is the basis of several attacks, such as the famous Smurf Attack.  Any halfway decent firewall will block this traffic, because it will be "out of state."  Meaning, a stateful firewall knows this is a response that was never asked for.  But that's a topic for another day.

So why do it?
If you send a packet with a false source IP address you will of course never see the return traffic.  So why do this at all?  Aside from doing something evil, this is really only useful if you have control of some device that can see traffic along the path - like a firewall.

You might never see the return traffic but your firewall can at least see the request.  Maybe the response too, depending on topology.  So check your logs to see what happened:


The firewall saw a request
from: 10.154.14.138
to: 10.25.17.45
on: icmp, https, http.

It blocked http but not https or ping.  Now I know that HTTPS and ping are open in the firewall, but HTTP isn't for these hosts.  Voila!