03-13-2015 03:36 PM
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
03-13-2015 04:31 PM
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.
03-13-2015 04:40 PM
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
03-14-2015 05:58 AM
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.
03-13-2015 04:41 PM
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?
03-13-2015 04:56 PM
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
03-13-2015 05:11 PM
"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?
03-13-2015 05:36 PM
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
03-13-2015 05:50 PM
Thanks very much!!
03-13-2015 05:03 PM
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
03-14-2015 03:05 AM
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.
03-14-2015 04:35 AM
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
03-14-2015 04:43 AM
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.
03-14-2015 05:51 AM
...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
03-14-2015 05:56 AM
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.
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