Consider using "ip nat outside source static...." instead, but then you should pay attention to where the packets come from and go to, and how is the nat implemented on interfaces. In any case, you can always deny a single host by being translated on its way out too. Let's say you have a NAT for a complete class C, then you'll have an matching ACL such as: access-list 1 permit 192.168.0.0 0.0.0.255 if you wanted to exclude a single host, you should add a line so this looks like this:
access-list 1 deny 192.168.0.1 access-list 1 permit 192.168.0.0 0.0.0.255 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leonardo Gama Souza Sent: Friday, February 08, 2008 11:46 PM To: Dennis Breithaupt; cisco-nsp@puck.nether.net Subject: [c-nsp] RES: (simple?) NAT-question mapping multiple outside addresses to one inside address What if you invert the picture? "ip nat inside source static 192.168.1.1 10.1.2.10 " And server - outside - router - inside - source_network ? Traffic from server to the network won't be nat'ted and the return traffic will be directed to 10.1.2.10, thus won't match the nat rule. cheers, Leonardo. -----Mensagem original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Dennis Breithaupt Enviada em: sexta-feira, 8 de fevereiro de 2008 05:01 Para: cisco-nsp@puck.nether.net Assunto: [c-nsp] (simple?) NAT-question mapping multiple outside addresses to one inside address Hello list, I request your support with this NAT-szenario, which I'm facing in a migration szenario from one IP-range to another. Szenario: On the "inside" we have a "node1". "node1" formerly had the IL-address "192.168.1.1". During a migration the node gets moved to a new location with a new IL-address "10.1.2.10". I now want this node to be reachable over both the ip-addresses. So I set up a hostroute for the old IL "192.168.1.1" to point to the new IL "10.1.2.10". (or a gateway to the segment, where the node resides...) My first approach was to define a static mapping: "ip nat inside source static 10.1.2.10 192.168.1.1" But that solution is not feasible. When trying to reach the "old" IL "192.168.1.1" the translation is correct and the node is reachable, as it should: (1-to-1 mapping) *Feb 8 08:55:55.223: NAT: s=10.1.1.10, d=192.168.1.1->10.1.2.10 [8] *Feb 8 08:55:55.243: NAT*: s=10.1.2.10->192.168.1.1, d=10.1.1.10 [8] When trying to reach the "new" IL "10.1.2.10" the outside-to-inside packet passes without NATting, but the inside-to-outside packet gets translated according the static mapping. So the initiating host gets an answer packet from a different ip. *Feb 8 08:58:30.271: NAT: s=10.1.2.10->192.168.1.1, d=10.1.1.10 [9] -> What would be the correct instrument, to just map multiple inside-global IP's to one inside-local for outside-to-inside conversations? Thank you very much in advance, regards, Dennis _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/