Tracert won't help here, you should print the route table by "route print" and see if the static route you added is using the interface with IP "172.16.0.100" and it should have less metric value than the default gateway.
If not delete that static route and add it again as below:
Route add 172.16.0.100 MASK 255.255.255.0 172.16.0.1 METRIC 2 IF (put the interface number) -p
Also, Make sure you enabled the ICMP for that interface if you want to ping it. you can do that in WF.msc
Thanks for your response. Trace route is pertinent here as it shows the next hop for reaching the destination network (ie. the static routes have already been put in place and this validates the expected path). The windows OS network components have been configured properly as there are no connectivity issues - the problem is that MVM is not leveraging the local route table. I can ping the target IP address, however a scan from this scan engine says that the IP is not active.
Zaid, the IP's are provided are examples - this is a DMZ server with public IP addresses so I'd prefer not to disclose this information. However as an example it is setup as such. This is not an issue with routing but rather an issue with how MVM handles static route configurations. I can ping the destination IP address, the traffic is following the expected path...this validates the fact that there are no routing issues. It is MVM itself that is not picking up on the static routes.
Network Address Netmask Gateway Metric
172.16.30.0 255.255.255.0 172.16.0.1 1
0.0.0.0 0.0.0.0 192.168.0.1 Default
MVM uses system network configuration, so if you are able to reach the target from the server, MVM should be able to reach the target. unless there are some Firewall rules that prevent MVM services to reach the target. So If you are convinced that the network configuration are correct, I suggest next step to check firewall rules. You can do that by writing wf.msc in run.
Im with zaid on this - I very much doubt this is an issue with MVM. To confirm it to yourself you need to see exactly what is happening, so I would suggest using Wireshark or windump - if you run a basic discovery scan against a test host and capture the packets, you should see which interface the packets are leaving on. If you actually *see* the packets leaving the wrong interface, then you know something is wrong (I doubt this will happen) and this is the only real test. You can look at all the configuration in the world, but the best troubleshooting method is actually seeing what is happening, not what you believe is happening or is supposed to happen (with regard to the latter, wierd things can happen in IT!)
Hope this helps,
Thanks for the response on this. I couldn't agree more about running a packet capture - I'll be doing that today. The reason I immediately assume the issue is with MVM is that I can ping the target host from the scan engine and I receive replies (ICMP is successful). I can telnet to various TCP ports as expected. The discovery phase of any scan would attempt both of these (ICMP, TCP & also ARP) to determine whether an IP is active would it not? Therefore - the underlying OS has no issue with connectivity to the target host, however an MVM scan from that same scan engine shows zero active hosts. But as you said dmease729, better to confirm for myself by looking at the actual network traffic.
Thank you both for your advice on this!
It is as I expected & what you had indicated dmease729. The packet capture during a scan clearly shows the packets leaving the incorrect interface, ICMP requests are sent and no replies are received. A packet capture of running an extended ping to these same target IP's shows the correct interface and all the ICMP replies. I think the evidence clearly indicates an issue with how MVM utilizes the underlying Windows network configuration (my guess is that it's bypassing the local route table altogether). I wonder if any other customers have a seen similar issues? Hopefully they provide a quick resolutions to this one.
What the....? Certainly not what I was expecting and certainly not the way it is meant to work. I have used multiple NICs before and not come across any issues such as this. Just out of curiosity, when the packets are sent out of the wrong interface is the source IP the interface that the packet is being sent out of, or the correct source IP but out of the wrong interface (if that makes sense!). Likely the former, but the latter is actually possible. The only thing I can suggest now is raising an SR (and hopefully keeping us up to date as this is a puzzler!) - remember to gather and provide the MER output from the scanner itself, along with details of tests and observations so far, and this should make the support case a lot faster!