Wondering if any other customers have encountered a similar issue?
One of our DMZ scan engines (Windows Server 2008 VM) has two IP addresses & 1 default gateway. I then entered static routes on the server to direct certain traffic to the appropriate gateway address. Running a ping from the server to the target is successful, however scanning that same target IP from this scan engine shows no active IP addresses. Here's an example of the setup:
IP 1: 192.168.0.100 / 24
IP 2: 172.16.0.100 /24
Default Gateway: 192.168.0.1 /24
Network destination: 172.16.30.0 /24
Gateway: 172.16.0.1 /24
- This destination network is only accessible via 172.16.0.1 and not 192.168.0.1
- ping 172.16.30.100 is successful
- tracert 172.16.30.100 shows proper next hop of 172.16.0.1
- ping -S 192.168.0.100 172.16.30.100 is not successful
What appears to be happening is that MVM is reading the network configuration of the server and determines there is 1 default gateway (192.168.0.1) it is then attempting to send all traffic to this gateway & not honouring the local routing table on the Windows server itself. This is problematic as at this time it is not feasible to include a secondary NIC, nor should it be necessary. Adding a secondary default gateway does not resolve the problem either and conflicts with configuration policies we have in place.
Thanks & would appreciate any feedback if others have a similar setup
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.
Edburn, can you pm me with your routing table.
The way I see it is you are having issues with routing. the routing table will confirm this, you can show the routing table by "route print"
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!