Question S2S VPN using Public IP

[Terence Lockette]

Hello,

I have a few of questions regarding a S2S VPN set up I'm being asked to complete.  To give you some background, a vendor is requesting a many-to-one NAT from our 2 of our internal hosts to a single public IP address and wants to use this public IP to be able to send across the encrypted tunnel.  Normal VPN tunnels (that I've configured) typically encrypts the traffic between the internal LANs on both sides of the tunnel.  They said they can accommodate the use of a many-to-one internal IP to another single internal IP if we don't want to use a public IP.  Here are my questions:

1. How common is it to use a public IP address for a S2S VPN tunnel (not the public IP peer address) for the interesting/encrypted traffic?

2. Their documentation says many-to-one or PAT which is what we already have set up for Internet access for our internal hosts (using a range of public IP addresses).  How does this type of configuration work since we're already using PAT?

3. If we went the many-to-one internal NAT to another private IP address, how do I set this up?

I know there's going to be many questions but please feel free and I'll provide as much details as I can.  I just want to get the discussion going so I have a better understanding.

Thanks!

[Bogdan Nita]

1. It isn't that common, but companies with a lot of vpn tunnels to 3rd parties do use them so there is no chance to conflict with private addresses.

2. You would specify the destination in the vpn nat and have it before the internet nat.
crypto-acl would only need to have the nated IP as source

3. Similar to the public IP nat, but with the private IP instead.

HTH

Bogdan

[Terence Lockette]

Bogdan,

Thanks for your quick reply.  I'm going to test this out in a lab environment so that I can make sure that my production changes will work.

Thanks again!

[Marius Gunnerud]

1. It is common.  I have set up quite a few of these NATing to the public interface IP of the VPN firewall. There have been two main reasons why the 3rd party wanted to do this in the cases I worked on.  first reason is that they were routing full private IP ranges (for example 172.16.0.0/12) to their inside network and to make administration easier they wanted to use the default route for this VPN traffic.  The second and most common reason is that the 3rd party vendor has many site to site VPNs with the remote sites having overlapping subnets.  So, since traffic is only generated toward the 3rd party vendor and not the other way around, an easy way to guarantee different remote IPs is to use public IPs.

2.  How this is set up really depends on the equipment you are using (router or firewall).  in the router you would use a policy NAT that references an ACL defining source and destination that this NAT statement should match and then the translated IP or translate to the interface IP.

On an ASA you are able to define source and destination IPs that the NAT statement should match.

3.  Same as the previous question you just define the IP you wish to NAT to.

check out the following link for ideas.

https://www.booches.nl/2009/01/policy-nat-on-cisco-router/

[Terence Lockette]

Hello,

Are you able to provide an example of how numbers 2 and 3 would look at on the ASA running version 9.4?

[Marius Gunnerud]

The NAT configuration for this would look something like the following:

object network LOCAL-IP

  host 10.10.10.1

object network REMOTE-SERVER

  host 192.168.1.10

nat (inside,outside) source static LOCAL-IP interface destination static REMOTE-SERVER REMOTE-SERVER

Then instruct the remote side to adjust their VPN configuration to have your ASA outside interface public IP as the remote encrypted domain.  And you would need to adjust the VPN at your side so that the public IP of the ASA is defined as he local subnet in the encryption domain.

This is assuming that the remote side is able to send traffic through VPN based on source and destination IP.  If they are unable to, or it is configured incorrectly you will see the tunnel start to flap.

[Terence Lockette]

So when you say, "you would need to adjust the VPN at your side so that the public IP of the ASA is defined as he local subnet in the encryption domain." you mean the ACL that would be configured on my ASA, correct?  For instance,

access-list VPN-ACL extended permit ip object LOCAL-IP object REMOTE-IP

Then have it reversed on the remote end of the tunnel, right?

[Marius Gunnerud]

That is correct.  The public IP goes as the source in the crypto ACL on the local side, and then the ACL is reversed at the other end (public IP is the destination in the ACL).

[Terence Lockette]

Ok one last question.  If the vendor is willing to accept a many-to-one NAT on a private IP (because they are only able to accept an address from a single source IP), I assume the process is the same but rather use a private IP as opposed to a public IP.  The question, however, is do I need to have this private IP the real addresses will NAT to in my internal network and routed?  Or is it as simple as creating a network object for it and mapping the real inside addresses to it?  Hope that makes sense.

[Marius Gunnerud]

The question, however, is do I need to have this private IP the real addresses will NAT to in my internal network and routed?

This would depend on who is accessing the NATed IP.  If the NATed IP is just being accessed / used by the remote side then nothing is needed on your side other than NAT configuration and VPN configuration.  However, if the remote side is accessing these servers based on the NATed IP then they would need to have routing inplace sending the traffic over the VPN.

[Terence Lockette]

Ok so our internal hosts are basically clients and the servers they'll communicate to are on the remote side.  So since the vendor is looking for a single IP from our side, it's just the VPN and NAT information I'll need to configure on my side, correct?

If that's the case, then I don't need to create a new subnet anywhere in my internal network or ASA, just create the network object for the IP that my internal hosts will NAT to and link it to the VPN config, correct?

[Marius Gunnerud]

That is correct, you do not need to do anything more on your end.

[Terence Lockette]

Ok, great!  I'll get this set up next week and will confirm all is working before marking the posts as accepted solutions.

Thanks again!

[Terence Lockette]

Just to reiterate, the purpose of this is to NAT a real, internal address to another private IP to use across the VPN tunnel on the ASA.  The way you've described will still work, correct?

[Marius Gunnerud]

Yes, it will work.  Just make sure that routing at the remote end is correct.

Also, if there are any firewalls behind the remote VPN head end then this will ofcourse need to be allowed there aswell.