06-08-2011 04:41 PM
Im trying to setup a connection Site-to-Site VPN. But I need to create a NAT IP, cause it will conflict with the destination box current connection.
Example:
Peer IP: 71.x.x.x (Inside: 10.50.50.12) <-----(Internet)-----> Peer IP: 62.x.x.x (Inside: 172.x.x.x/10.x.x.x/192.x.x.x)
I never delt with NAT before and I need a few opinions on how to do this. I can set it up with some bogus IP like 162.1.1.1. and it works but im not sure if it will run into problems in the long run.
Is it possible for me to use a public IP I have from my ISP (which I have a block of 20)
Any insight on this would be much appriciated!
06-08-2011 11:38 PM
You should use another subnet instead of 162.1.1.1, as this address is globaly routable, and it can potentially create routing problems on your peer side. Try using any subnet from private range
06-09-2011 08:37 AM
Is there a way I can avoid using the private ranges for the NAT. How about using a public IP. I've have a setup with a NAT from a vendor where they created a NAT from their IP block 170.220.x.x . Im just not sure if I can/should use one IP from my block which I got from Verizon (71.254.182.x).
06-09-2011 09:16 PM
Yes you can but, on your side, do you want to send through the tunnel only the host 10.50.50.12 or the subnet? If you want to translate the entire subnet into one IP then you need PAT in this case be aware that the traffic will be unidirectional, what I am trying to say is that you will be able to initiate traffic to the remote end but they won't be able to initate a connection to your side. Should look something like this:
*Note, using 8.2 or prior
nat (inside) 2 10.50.50.12 255.255.255.255
global (outside) 2 172.254.182.X
On the other heand if you want to do a one-to-one translation then it would be like this:
static (inside,outside) 172.254.182.X 10.50.50.12
That translation will happen always, so if you are sending the real IP through other tunnels it will get affected so I'd recommend you to use Policy NAT or Policy PAT, just use an access-list.
access-list POLICY-NAT permit ip host 10.50.50.12 20.X.X.X 255.0.0.0 (I know remote is 10.x.x.x but you should translate the 10 net into something else because of the overlapping)
static (inside,outside) 172.254.182.X access-list POLICY-NAT
same idea if using Policy PAT.
If you dont manage the remote end and want to use Policy the you can do DoubleNAT, source and destination. If using 8.2 or prior the you need two lines:
static (in,out)
static(out,in)
if using 8.3 or later you just need one line.
Regarding the fact of using 162.1.1.1 or any other Public IP, it will not represent any potencial routing problem; remember that we are using ESP and tunnelmode so the original packet will get a completely new IP Header, from peer to peer so this is what will get routed not the real IPs pr the translated ones in your case.
--Tavo
06-10-2011 08:49 AM
Thank you for the detailed reply Tavo! Alot easier to understand.
I redid the scheme where my 10.50.50.12 will be NAT'd to 172.20.10.12 and from the other peer they will connect over the VPN to 172.20.10.12. However, after creating the NAT for 10.50.50.12.
*Update*
I got it NAT'd and can establish a successful VPN connection between both peers. How ever I cannot ping or communicate from either sides. I added ICMP to the security policy but still no luck on getting a response from the NAT'd box.
* Update #2 *
Did some testing with the NAT in two different scenarios.
(Internet does not work on NAT'd peer, but network between peers work)
global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,outside) 172.20.10.12 10.50.50.12 netmask 255.255.255.255
access-group inside_access_in in interface inside
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 71.254.182.1 1
(Internet works, but network between peers does not)
global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 0.0.0.0 0.0.0.0
static (outside,inside) 10.50.50.12 172.20.10.12 netmask 255.255.255.255
access-group inside_access_in in interface inside
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 71.254.182.1 1
06-10-2011 09:29 AM
Jarrod,
Can you attach the translation you created as well as the access-list you applied to the crypto map?
A packet-tracer would be useful too:
packet-tracer input inside icmp 10.50.50.12 8 0 X.X.X.X det >> where X.X.X.X is the remote resource yu are trying to communicate with.
Regards,
06-10-2011 09:32 AM
Just noticed you already provided the translation you created, i'd like to take a look at the inside_nat0_outbound access-list and the one you have applied to the crypto-map, if not possible the the packet-tracer will be enough.
Thanks,
06-10-2011 09:50 AM
I just updated the post above with the the only part I changed.
Thanks again!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide