[c-nsp] RES: (simple?) NAT-question mapping multiple outside addresses to one inside address

Ziv Leyes zivl at gilat.net
Sun Feb 10 03:32:40 EST 2008


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: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Leonardo Gama Souza
Sent: Friday, February 08, 2008 11:46 PM
To: Dennis Breithaupt; cisco-nsp at 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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] Em nome de Dennis Breithaupt
Enviada em: sexta-feira, 8 de fevereiro de 2008 05:01
Para: cisco-nsp at 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 at 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 at 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.
************************************************************************************




More information about the cisco-nsp mailing list