Change destination address same interface/subnet

[pauruizperez]

Is there any way of redirect all traffic to a specific global IP in the router to another machine in the same NET?

Ex:

Router c1721 IPs: 212.1.1.1/24 Outside

10.0.0.1/24 Inside

Machines IP: 212.1.1.2/24 (Webserver)

10.0.0.2/24 (Mailserver)

Using NAT I can make all traffic on 212.1.1.1:25 to 10.0.0.2:25 without problem.

Now the problem comes when I try to "NAT" 212.1.1.1:80 to 212.1.1.2:80...:

I can't NAT, so it's the same interface.

I can't do route-map, so route-map doesn't change destination address...

I think router had to tell source machine that the new destination is 212.1.1.2, without involving himself in the traffic.

But, there's a way of specifiyng a "static ip redirect" in Cisco IOS? Source machine has to be in the same subnet for a ip redirect to work? IP redirect only work on wich route is better, not destination?

Thanks in advance:

Pau

[mchin345]

To enable the sending of redirect messages if the Cisco IOS software is forced to resend a packet through the same interface on which it was received, use the ip redirects interface configuration command. To disable the sending of redirect messages, use the no form of this command.

ip redirects

no ip redirects

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/cs/csprtn1/csipadr.htm

[pauruizperez]

I can see redirects have to be enabled in the interface, this is usefull on wccp, when the cache engines are in the same subnet as the clients, and without the ip redirects won't work, but this does not solve the problem.

I wanted to check a connection to 1.1.1.1:80, and tell the client:

"Oh, you've connected to 1.1.1.1:80, and now you'll be redirected to 1.1.1.2:80".

- I can't do NAT, so as far as I know it's imposible to do NAT inside and NAT outside in the same interface

- I can't do route-map, so route-map does nothing with the address, just route the packet (and the 1.1.1.2 machine will do nothing with a packet destinated to 1.1.1.1).

Still looking, but the best way seems moving all the machines involved in this issue back the router, so usual NAT could be used.

Thanks for your response:

Pau