Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Here's the problem. I have two network connections on my DEV machine.

LAN - Connects to the building network and internet. IP is assigned by DHCP and is 192.168.30.XX.

LOCAL - Connects to a switch, which has one TEST machine. IP is 192.168.25.100. And the test machine is at 192.168.25.2.

Right now I remotely reboot the TEST machine, then ping to see when it's come back up.

Problem is, yesterday someone (probably accidentally) added a machine to the building LAN that has an IP of 192.168.25.2, so now when my TEST machine is rebooted and I ping for it, I get a response from this remote machine on the LAN, my software thinks the TEST machine is back up, and tries to log in. This obviously fails, because it's not the TEST machine responding, and it's still mid-reboot.

My question is, how do I either:

  1. prevent all requests for 192.168.25.2 from going out over LAN, or
  2. force all requests for 192.168.25.2 to go out over LOCAL

UPDATE: I think the best solution would be to modify the routing table so that packets to 192.168.25.2 are blocked over one interface, and statically routed over the other.

Thing is, while I can add a static route using this:

route add 192.168.25.100 mask 255.255.255.255 192.168.25.2

But Windows will still automatically fail back to the LAN and attempt to ping there if that static route fails.

Is there a way of blocking traffic to a specific interface or gateway within the routing table?

share|improve this question

migrated from stackoverflow.com Apr 30 '12 at 12:10

This question came from our site for professional and enthusiast programmers.

    
Can you be more specific, are both interfaces configured with a netmask of /24 (255.255.255.0) and does your DEV machine receive a default route through DHCP on the LAN interface? –  zero0cool Apr 28 '12 at 15:35
    
What operating system does DEV run, please? –  thb Apr 28 '12 at 15:36
    
Unfortunately I just lost my VPN, so I can't check at the moment. But I'm pretty certain that both connections have a 255.255.255.0 mask. I'll check the default route. And the DEV machine is running Win7. –  static416 Apr 28 '12 at 16:55
    
The solution would be to assign the TEST machine some other ip address that is unlikely to be used by anyone say 192.168.255.255 –  Ramhound Apr 30 '12 at 14:14
    
@Ramhound probably best to avoid anything near a broadcast address, especially if people are plugging different devices into the network. –  HaydnWVN Apr 30 '12 at 14:55

3 Answers 3

Not sure why I didn't think of this earlier, but the simplest solution is to just create a custom rule within the windows firewall to block connections to/from the specified IP, on a certain interface or connection type.

UPDATE: Doesn't really solve the problem either. This just causes pings to come back as "General Failure", rather than as a timeout or destination unreachable. "General failure" causes an exception in C#, and I'd have to write a handler to catch it.

Again, I COULD write an exception handler, but that isn't very elegant.

share|improve this answer

If someone 'added a machine' onto the network and gave it a static IP address outside of the DHCP scope then they're probably experiencing other problems too... Not being able to connect to Printers/other machines/other odd problems due to being on a different subnet. Find out who this person is and setup their PC correctly (ie on DHCP!).

Check your server that the DHCP scope is set correctly, then see if there is a lease for the 'rogue' PC. Expire it if found. Then add DHCP exceptions for your PC's you want to use on a different subnet, if they are not already present. Might be a good idea to flush the DNS on the server after doing any of this too.

IF you're not the network administrator then get them involved - people shouldn't be setting up PC's on your network if they don't know how to do it!

As you've already figured out - best way to block an IP address is to add it into the Firewall, you could also add exceptions into the Firewall too...

share|improve this answer
    
Yeah, this is sort of the problem. Our company builds network-connected devices. When built, all of these devices default to the IP 192.168.25.2. If someone in marketing connects one to the wrong ethernet port, it shows up throughout the whole building. –  static416 Apr 30 '12 at 15:03
    
So I need a sustainable way of dealing with this problem, cause it's going to happen constantly. I need to be able to block packets with a certain destination IP from going out over a specific connection. –  static416 Apr 30 '12 at 15:09

Unless you have some specific requirements on why you can't do this the best solution is to change your IP address to some unique value. No need to create rules if there are plenty of other IP addresses.

share|improve this answer
    
While it's possible to change the TEST machine IP, it's not really a good solution. Part of the intent of this software is to attempt to connect to 192.168.25.2, so if I change that detail, I won't really be testing the software under real-world conditions. It's a small difference, but these things tend to cause problems. That'll likely be the option of last resort. –  static416 Apr 28 '12 at 16:59
    
@Static416 - Just make it configurable. –  Ramhound Apr 30 '12 at 14:14
    
@Ramhound That won't scale in the long run. Once this software is rolled out, the default IP of TEST will always be 192.168.25.2 when it comes out of production, and I want to be certain the software will always find it correctly. –  static416 Apr 30 '12 at 14:46
    
change your IP address to some unique value. is very bad advice on most corporate networks. Last thing you want is 'random' IP's appearing! Makes it a nightmare to track/diagnose/configure anything! –  HaydnWVN Apr 30 '12 at 14:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.