2

We host a web site for a client that is not responding to our requests to change their "A" record for the site (they own the domain). We are migrating soon and we cannot wait for them, nor do we want their site to be down once we migrate.

Is there a way to route or forward traffic directed at a specific public IP to another public IP (in a different subnet) at the firewall level? We have a Cisco ASA 5510 if it matters.

If not at the firewall level, are the OS-level or even application-level fixes beyond URL redirection to another URL?

2
  • Forwarding everything that is hitting that IP isn't the best idea. Why don't you use a reverse proxy, just until they change their A-record? Feb 22, 2012 at 14:32
  • I know you can set up reverse proxy from web server level, but can this be accomplished at the firewall level (ASA, for example)? Feb 22, 2012 at 14:36

2 Answers 2

1

You can do this forward with your ASA, or you could dual-home the new host for a while (this would be my choice - it's the easiest solution), or you could rig up a proxy like Bart De Vos suggested.
None of these this solutions will solve your underlying problem though: Presumably you need this customer to get off that IP for some reason, and by keeping it working you provide them no incentive to change their DNS.


I know it's not what you want to hear, but you need to give your customer a hard deadline by which time thy MUST change the A record, because the IP will go away at hard deadline + X hours. (If you have the time you should ideally send this notice to them in writing, certified mail, return receipt, yadda yadda yadda, so there's no disputing that they were notified). If they fail to comply, let their site break.

I've been through 3 IP migrations from the ISP side, and 2 from the client side. In my experience a customer who does not respond to repeated polite requests to change their addresses will NEVER do so until their hand is forced. (And to be fair, many ISPs will hang on to address blocks their delinquent customers are still occupying, right up until the point their RIR says "You can't have any more IPs until you stop advertising those! They're not yours anymore!")

1

If your machines are on the same network, just dual-address the new machine call it a day. That's probably not your case though, so the following are suggestions for handling this across two different networks.

The fast way would be to implement NAT on the old machine's firewall. This requires only affecting the setup of the old system. Change the source and destination address of all incoming packets to be traffic from your machine to the new server. The downside to this is that redirected traffic will look like it came from the old server, the old server's firewall may quickly run out of sockets to maintain the NAT if you have high traffic, and you'll have to endure doubling of inbound and outbound traffic on the old machine plus increased latency.

A more complex fix requires some adjustments to both the new and old systems. You'll need to establish a tunnel between the systems and route traffic for the old system over that tunnel. The new system will need to answer to both the new and old IP addresses. You'll still be carrying double the traffic that arrives at the old server, but all traffic leaving the new server can be sent out directly without traversing the old system. I believe that this is worth the effort, though.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .