ASA IPsec Remote Access VPN | NAT Question

[Mark^]

We have a situation where a company that needs remote VPN access to our network is having an IP conflict with our subnet.  I know this is a common issue and can often be resolved on the client side by changing the metirc on the network interface, but I am looking for a better solution on our end so I do not have to suggest workarounds.

Part of the problem is likely that our subnet is "too big", but I'm not going to be changing that now.

We are using 10.0.0.0/24 and the remote is using 10.0.11.0/24 and 10.1.0.0./16

I played around with some NAT rules and feel that I am missing something  I am looking for suggestions, please.

Thank you.

[Jouni Forss]

Hi,

So you are saying that the remote site has alot of subnets from 10.0.0.0/8 in use and this causes problems for them when connecting to your local network 10.0.0.0/24?

You could try configuring Static Policy NAT where you essentially NAT your network 10.0.0.0/24 to something like 192.168.10.0/24 for the VPN users. So that the VPN users would be connecting to 192.168.10.10 when they want to connect to 10.0.0.10 and so on.

Or did I understand your situation wrong?

- Jouni

[Mark^]

Hi Jouni,

Thanks for your response, I think you're on it right.  I'd like to give these speicifc VPN users a 192 or 172 address then NAT them back so they can access our 10.0.0.x network.

How would I go about doing this?

[Jouni Forss]

Hi,

This depends on your ASA firewalls software version and partly on its current NAT configurations.

I presume the following

• Interfaces "inside" and "outside"
• VPN Pool network of 10.10.100.0/24 (or some 192/172 network)

Software 8.2 and below

access-list VPN-POLICYNAT remark Static Policy NAT for VPN Client

access-list VPN-POLICYNAT permit ip 10.0.0.0 255.255.255.0 10.10.100.0 255.255.255.0

static (inside,outside) 192.168.10.0 access-list VPN-POLICYNAT

Key things to keep in mind with this software level is that if any of our internal hosts on the network 10.0.0.0/24 also have a "static" configuration that binds their local IP address to a public IP address then you might have to insert the above configuration and then remove the original "static" command and enter it back again.

This will change the order or the "static" commands so that the original "static" command wont override this new configuration as they are processed in order they are inserted to the configuration. The remove/add part is just to change their order in the configuration

Software 8.3 and above

object network LAN

subnet 10.0.0.0 255.255.255.0

object network LAN-VPN

subnet 192.168.10.0 255.255.255.0

object-group network VPN-POOL

subnet 10.10.100.0 255.255.255.0

nat (inside,outside) 1 source static LAN LAN-VPN destination static VPN-POOL VPN-POOL

In the above configuration we do the same as in the older software versions configuration but we have the number "1" in the "nat" configuration which places it at the very top of your NAT configurations and therefore it applies. No need to remove any existing configuration and enter them again like in the old software

In addition to the above NAT configuration you naturally have to make sure that the traffic to the NATed LAN network goes to the VPN. So if using Split Tunnel the NAT network needs to be added to the VPN ACL. If using Full Tunnel then naturally everything should already be coming through the VPN. I imagine though that you are using Split Tunnel, or?

Hope this helps

Please do remember to mark a reply as the correct answer if it answered your question.

Feel free to ask more if needed

- Jouni

[Mark^]

Excellent.  That looks like exactly what I want, but I want to fully understand it before I implement it.

We are above version 8.3 and I am using split tunnel for this specific group policy.  I am not using split tunnel on other group policies.

I follow the config just fine until I see the 10.10.100.0 VPN-POOL.  Where does this come into play?  I assume I issue dhcp in the 192.168.10.x subnet?

On my other group policies, if I am issueing dhcp addresses in the 10.0.0.0/24 network, these nat changes will not affect those VPN connections -- correct?

Thank you very much for your time on this.

[Jouni Forss]

Hi,

Was the 10.0.0.0/24 your LAN network or the actual subnet from which the VPN user IP addresses are provided from?

Lets look at the configuration

object network LAN

subnet 10.0.0.0 255.255.255.0

object network LAN-VPN

subnet 192.168.10.0 255.255.255.0

object-group network VPN-POOL

subnet 10.10.100.0 255.255.255.0

nat (inside,outside) 1 source static LAN LAN-VPN destination static VPN-POOL VPN-POOL

It presumes that your LAN network is 10.0.0.0/24 and VPN Pool is 10.10.100.0/24 and the LAN network will be NATed to 192.168.10.0/24.

In the above setup naturally the VPN Pool and NATed LAN network are subject to change to something else. Above are example networks.

With all the above in mind you would probably be better off having a different VPN Pool for these users in particular. If multiple different user groups use the same VPN Pool then this change would probably affect them also. What I mean that they would also have to use the NAT IP address to contact the actual LAN hosts in network 10.0.0.0/24

Considering this is a new(ish) setup I would imagine its not a problem at this point configuring a new VPN Pool for these users?

- Jouni

[Mark^]

This setup has been in place for many years and currently issues IP addresses in the LAN subnet - we do not have a seperate VPN pool.  However, we have contracted a third party and I created a seperate group policy with a split tunnel and also restricting their access.  Any chanegs I make, I would like only to effect connections from this third party if possible.

10.0.0.0/24 is our LAN and the third party's LAN overlaps with that.

[Jouni Forss]

And to further clarify the operation of the NAT

When the connection is coming from the VPN-POOL to LAN-VPN then there would be no translation for the source network VPN-POOL as its specified as both the real and mapped object. The connections destination in this case would be LAN-VPN which would in turn be UN-NATed to LAN.

Same naturally applies to the other direction but there is rarely connections formed towards VPN Client users. If that were the case then the ASA would basically apply the same NAT configuration but in other order.

When connection is coming from the LAN to VPN-POOL then the source address would be NATed to LAN-VPN. Since the destination of the connection in this case would be VPN-POOL there is no actual NAT performed for it since the real/mapped object are the same. (though there is actually an UN-NAT though the address is not changed)

- Jouni

[Mark^]

Ok, so I want to go ahead and try this out and mark your response as answer.

If I want to copy your example exactly, all I need to do is add those lines and then setup the VPN dhcp pool to be in subnet 192.168.10.0 255.255.255.0 and all should work in theory?

[Jouni Forss]

Hi,

There seems to be some missunderstanding still.

In the above configuration example I mention the network 192.168.10.0/24 is only the NAT network of the real network 10.0.0.0/24. The network 10.0.0.0/24 will be masked as 192.168.10.0/24 for the VPN users that are using the VPN Pool network 10.10.100.0/24, though again the VPN Pool can be any network you want. The network 10.10.100.0/24 is just an example.

object network LAN

subnet 10.0.0.0 255.255.255.0

object network LAN-VPN

subnet 192.168.10.0 255.255.255.0

object-group network VPN-POOL

subnet 10.10.100.0 255.255.255.0

nat (inside,outside) 1 source static LAN LAN-VPN destination static VPN-POOL VPN-POOL

So lets take an example

• Your VPN Pool for the new user group is 10.10.100.0/24
• A user connects using the new VPN connection and gets assigned the IP address 10.10.100.10
• The user wants to connect to the host on your LAN thats real IP address is 10.0.0.10
• Since the network 10.0.0.0/24 is NATed to an equal size network of 192.168.10.0/24 we know that the VPN user should connect to the target IP address 192.168.10.10 that corresponds to the real IP address 10.0.0.10. In the same way 192.168.10.100 would correspond to the real IP address of 10.0.0.100

What you have to make sure is that the VPN configurations for the new user group tunnel traffic towards network 192.168.10.0/24 atleast. If you are using Full Tunnel VPN then this is naturally no issue as everything is tunneled.

You will also have to make sure that the VPN Pool/network that this new user group is using is something that ONLY they are using. IF NOT you will be affecting other VPN users also as the NAT rules look at the source/destination IP addresses only and are not in anyway tied to "tunnel-group" or "group-policy" you might have configured on the firewall.

- Jouni