cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2422
Views
0
Helpful
16
Replies

NAT and VPN question

mjsully
Level 1
Level 1

On ASA running 8.2, firewall is configured to PAT all inside networks when going out to the internet, to the interface of the outside firewalls interface.

Setting up a new VPN, if I don't setup an ACL to bypass NAT, can the defined inside hosts in my crypto ACL still get PAT'd to the same outside ip before it goes to the remote end. In otherwords, can it PAT to the same ip address that would be the peer address from the remote end's perspective? remote side can only accept a public IP, and we have no other IP's to use, so looking to see if and how this can be achieved.

 

 

thanks

16 Replies 16

David paull
Level 1
Level 1

Set it to any public ip you want -- and just have them NAT it to whatever in the world their little hearts desire.  Just because it has to be a public IP address doesn't mean it has to be yours.  In short, that public address only exists through the tunnel to them.  They'll NAT it on their end, and they'll NAT it back when it hits their crypto asa.  It's never seen by their internal network, etc etc.

They'll NAT it on their end, and they'll NAT it back when it hits their crypto asa

They might not.

I have setup VPNs with other companies where they didn't do that, they just wanted to make sure there was no overlap with their private IPs,

If the OP used any public IP it could actually stop the other company accessing a particular server on the internet.

Jon

Again, 100% wrong, due to the reasons I stated above -- that being that their internal network never sees your public IP that you chose.  That public IP only exists through the tunnel, and is 100% gone after that.

I am in charge of over 208 Site to Site IPSec VPN tunnels at my organization.  I bring up a new s2s tunnel at least every two weeks with a different outside vendor.

 

***EDIT: This post was made with the assumption that they route internet traffic differently and it never goes through the ASA responsible for IPSec conections -- clearly I assumed something that was never brought forth as far as information goes.  I'll leave the post in-tact, however for awareness reasons.

but I can set it to the same address as the PAT address? how would I configure this in a VPN. Let's say I have a single inside server, ip 192.168.10.10. My firewalls outside IP for this example is 10.10.10.10. Everything on the inside network gets PAT'd to 10.10.10.10 before going out to internet. 

if I were to nat the inside 192.168.10.10 to a different address of my own choosing, how do I configure that NAT so it only comes into play when going to the remote VPN subnet, and still get PAT'd to firewalls outside interface with non vpn regular internet traffic?

You can use policy NAT to do this but I still wouldn't recommend using any public IP.

If you wanted to use a different IP for the VPN eg.

access-list VPN permit ip host 192.168.10.10 <remote network> <subnet mask>

nat (inside) <id> access-list VPN

global (outside) <id> <IP of your choosing>

where the <id> must match and must not already be in use.

If you want either end to be able to initiate the connection you would need to do static policy NAT statement instead of the above.

Personally if you are already doing PAT to a public IP I would just use that.

If you choose any public IP then I would check with them at the other end as to what they are going to do with it.

Jon

"Personally if you are already doing PAT to a public IP I would just use that."

 

so if I simply entered no NAT statements and built the VPN config as normal, then traffic from my local server would get NAT'd  to the same PAT address (firewalls outside interface), despite it going over the VPN? so regardless of whether the server was just hitting the internet or a host on the other side of the tunnel, the src would be the firewalls outside IP?

Yes assuming the VPN is terminated on the outside interface which it very probably is.

You just need to make sure the crypto map acl references the public IP and not the private IP.

Jon

Thanks very much!!

Just to clarify and using the ASA as an example.

The ASA does NAT before encryption. If you happened to pick an IP of an internet site they use, for example, then their crypto acl  will match that traffic and send it down the tunnel to you.

Which may mean all traffic meant to go to that site ends up coming to you.

Probably not what you want :-)

Jon

Not true.  You can use any public IP site they use and it will not affect their internal network operations.  For the simple fact that as soon as your packet arrives are their ASA, it is un-encapsulated, and NAT'd to whatever their internal scheme allows.  The source then becomes that, the address that they picked.  When traffic is returning, it is NAT'd at the asa again, and send back over the tunnel.

David

It's nothing to do with what IP they see in their internal network, it is what happens when the packet gets back to the ASA.

I may be wrong because I am no expert but the ASA does NAT before encryption when going inside to outside.

So they receive the packet and change the source IP to one they want on their internal network.

When the packet gets back to their ASA the IP is changed back to the public IP before it is encrypted.

So now the destination IP is the public IP.

And then it is encrypted and sent down the VPN tunnel.

So what if a user internally sent traffic to that public IP and it was meant to go to Google for example.

The source would be an internal IP and the destination IP would be the public IP of Google. But your crypto acl matches that traffic and sends it down the VPN tunnel.

I'm not saying you can't use a public IP that you don't own but what I was saying is it can't be any public IP you can simply pluck out of the air.

I may well be wrong but I cannot see how the ASA would know which traffic wasn't meant to be sent down the tunnel and which was if the destination IP is the same ?

Jon

Why not?  Who says they route their internet traffic through that same ASA?  (And by your argument -- who says they don't?) -- I see where this is going.

 

The more I think about it, you could be correct, depending on their network setup...but if the only stipulation given was "NAT it to a public IP address" -- it sounds like they know what they're doing.

 

I do see your point now, and I just took for granted that they route to the internet through another means than the ASA -- which, if they're running a lot of s2s connections, I can only assume they do, and they know what they are doing.

 

I digress -- I certainly wasn't viewing the bigger picture -- more information would have to be collected to make the assumptions that I made and be 100% sure of them.

...but if the only stipulation given was "NAT it to a public IP address" -- it sounds like they know what they're doing.

If all 208 of the VPNs you have setup have been with people who knew what they were doing then I envy you :-)

Seriously though I also have setup a lot of L2L VPNs and certainly from my experience most companies use the same firewall for both internet access and VPN and I can honestly say not all of them knew what they were doing.

None of what I said was intended as a criticism of you and I didn't post my response to try and prove you wrong because I'm not interested in doing that.

I just wanted to make sure the OP didn't make a mistake by choosing an inappropriate IP, that's all.

Jon

I got you Jon.  I just feel like in his case, he is the person setting up a tunnel between his location and some type of centralized location that has been over this before (due to the nature of their request).

 

And of course, pretty much every s2s that I set up requires me to assist someone on the other end with matching everything up.  I'm assuming the OP is like that guy on the other end that needs a little help (which is totally cool).

 

I didn't take anything you said as criticism.  I bet the OP will get the clarification he needs and it will go smoothly now.  I'm a pretty straight-forward kind of person, so if I come off oddly, it's certainly not intended.