Geek pop quiz.

[theweaselking]

A server is, for unknown reasons, trying to connect to ip A for updates to an application. It SHOULD be connecting to ip B. The application configuration is correct. A complete reinstall, down to digging it out of the registry and deleting all the folders, has not solved the problem.

A brute-force solution presents itself: forcibly redirect all connection to A to B instead. Difficulty: they are on the same subnet, and you cannot change anything about the switches, routers, or, in fact, anything except Windows itself on this one machine.

And it's an IP, NOT a dns name. Hosts file won't do it unless you can provide syntax for ip redirection via hosts.

Is there a way to do that in windows server 2008, via "route" or something?

Posted via the phone of doom

Comments

[rbarclay.livejournal.com]

Got a Linux box on that LAN? Than you could just do a /32 route, plus iptables-NAT.

[harald387.livejournal.com]

This was posted on my behalf, and the answer is 'no, we cannot do anything with the LAN'. Many solutions would present themselves if we had access to make changes to the network, but we don't; any solution must involve changing only the Windows box.

I don't expect we'll find a solution, to be honest.

[theweaselking.livejournal.com]

I was thinking rinetd rather than iptables, but yes. Problem: Can't get a Linux machine on the network.

Depending on if that other IP is occupied, assigning it to the same NIC on the Windows machine could work, but then you've got to run your redirect under windows and I don't know of a tool for that and/or the magic spell with Route for "all incoming traffic on this IP, send to that IP"

[theweaselking.livejournal.com]

Steal the second IP, install Cygwin, run iptables is Right Out. For the record.

[duskwuff.livejournal.com]

It's a moot point anyway; iptables won't run on Cygwin, as it's just an interface to features of the Linux kernel.

[theweaselking.livejournal.com]

Rinetd then. Still Right Out.

[ianhess.livejournal.com]

Install a minimal vmware instance that runs linux and only forwards the ip?

[theweaselking.livejournal.com]

How would that help? It's still demanding that IP A give it the answers - tunneling traffic to B first doesn't tell it to look at B.

[rbarclay.livejournal.com]

Install a /32 route for IP A to the vmware'd Linux, where you can then NAT just the required port(s) to IP B, and NAT the rest to the "real" IP B. Even WIndos can do host routes.

Butt-fugly, and likely to break at some point, of course. And not necessarily less work than wiping/reinstalling the originally offending Windos box.

Alternatively, hunt for something that can do proper NAT natively on WIndos. I'm sure there's something Out There.

[jack coates (from livejournal.com)]

The likelihood that you're experiencing a problem which is arising from previous application(s) of the kind of fix you're looking for is.... 99.999%.

[theweaselking.livejournal.com]

I'm in favour of "wipe the machine, reinstall windows server, try again", for the record. It'll only take 3 hours or so to do.

[en-ki.livejournal.com]

Concur. I'm pretty sure the sophisticated, careful solution to this (and the only reasonable alternative to "nuke it from orbit") is to figure out WTF the application is doing. Surely it has its stupid configuration bullshit somewhere. Search the registry for a value with IP A, grep the hard disk image for big-endian and little-endian and text and [...] representations of IP A, sniff its packets from boot time for IP A. It's not like it comes from outer space.

[prk.livejournal.com]

0) Check if there are any static ARP entries on the server in question. Clearing them may fix your problem.

1) Statically define the MAC address for machine B as as the ARP answer for IP A on the server.

That will send all traffic to machine B when it tries to connect to IP A.

2) Add IP A as a dummy / loopback address on machine B. That will allow it to terminate the TCP sessions to IP A on machine B, and reply back successfully.

3) Cry in horror at the hack you've created.

[theweaselking.livejournal.com]

4) hide your head in shame a year from now when a new sysadmin says "WTF? All my connections to A are going to B instead!"