Site to Site VPN with 2 ASA 5510's

[Wouter Platteeuw]

Hello guys,

Im hoping yall can help me with the following objective. I have been tasked to make a site to site VPN between two networks. We are both using an ASA 5510.

This is the scenario:

SiteA has an wan adress of (example) 20.20.20.20  - The firewall is connected to a DMZ range : 192.168.0.0 255.255.255.0. In this range there is another firewall which grants/blocks acces to the internal range. 10.20.0.0 255.255.0.0

SiteB has an wan adress of (example) 21.21.21.21 - The internal range is 10.0.0.0 255.0.0.0 No DMZ.

How can i connect these 2 devices since there is an overlap. I am gonna need to use nat right? Can someone give me readable  Access rule/Nat Rule and maybe advice / some other things i need to think of.

Hope to hear from yall. Any advice is highly appriciated.

Thanks in advance

[Jouni Forss]

Hi,

I do tend to run into these situation every now and then. I mean situation where the remote end simply states that their side network is 10.0.0.0/8 which naturally isnt the case at all.

I would probably consider asking the remote site admin to specify the subnets from the network 10.0.0.0/8 that actuall need to use this L2L VPN connection and then decide on a suitable subnet for NAT purposes so you dont have any overlap. The situation will most probably also require you to also NAT your 10.20.0.0/16 subnet to something else.

For actual configuration examples we would need to know your ASAs software level which you can check with the command "show version". This is because the configuration format depends if you are using the 8.2 (or older) or 8.3 (or newer) software level.

Generally speaking you should do the following things

• With the remote site admin define the networks on their side which need to use the L2L VPN
• Device on a suitable subnet(s) that will be used to NAT the subnets on each site
• Define the local/remote networks (Encryption Domain) in the L2L VPN by using the subnets NAT addresses
• Define a Static Policy NAT that will perform the Static NAT for your source network when the destination network is the remote sites network (its chosen NAT subnet(s))

Naturally if the L2L VPN connection is only used so that the other site can access resources (initiate connections) on the other site then you could probably configure some kind of Dynamic Policy PAT which would again make the situation a bit simpler as you could "hide" all subnets on other site behind a single PAT address.

Hope this helps :)

- Jouni

[Wouter Platteeuw]

Dear Jouni,

We are running version 8.4(2) (adsm 6.4(5))

I have seen their network briefly and they havent done any subnetting. They do use some kind of logic when giving out adresses but nothing has been done to seperate these ranges. (for the devices that will use the tunnel they use the 10.0.1.0 and 10.0.2.0)

Both sides have to be able to communicate to one another. Will be using some applications of theirs and vice versa. (They only have to communicate with our internal range but to get there they will have to pass through our dmz :P)

We would only want a few protocols to be excepted. Can you give me an example how it would look like for just HTTP and FTP traffic (just so i have a basic understanding of it)

[Jouni Forss · Accepted solution]

Hi,

Well regarding the remote site I suppose if they are using hosts from ranges 10.0.1.0/24 and 10.0.2.0/24 they could simply NAT these portions of the network towards the L2L VPN connection. For example NAT them to subnets 192.168.101.0/24 and 192.168.102.0/24

But you also seem to have a large subnet on your side since its 10.20.0.0/16. Because of this I would suggest narrowing it down to the hosts or smaller subnets like above with the remote site because simply NATing the whole subnet 10.20.0.0/16 to some other private range that is NOT from the 10.0.0.0/8 range would probably cause problems in the long run.

Lets presume that on your side the network that needs to access the L2L VPN is 10.20.1.0/24 and we would NAT that to 192.168.201.0/24 then your NAT configuration could look like this

object network DMZ-INTERNAL
  subnet 10.20.1.0 255.255.255.0

object network DMZ-INTERNAL-NAT
 subnet 192.168.201.0 255.255.255.0

object-group network REMOTE-NETWORKS
 network-object 192.168.101.0 255.255.255.0
 network-object 192.168.102.0 255.255.255.0

nat (dmz,outside) 1 source static DMZ-INTERNAL DMZ-INTERNAL-NAT destination static REMOTE-NETWORKS REMOTE-NETWORKS

In the above configuration we first create an "object" for both the actual internal DMZ subnet and the subnet that we will NAT it to. Then we create an "object-group" that will have inside it both of the remote NATed networks (NAT performed at the remote site).

Finally the "nat" command itself will perform NAT between "dmz" and "outside" interface and it will NAT "DMZ-INTERNAL" to "DMZ-INTERNAL-NAT" when the destination is "REMOTE-NETWORKS". The NAT configuration is bidirectional so it naturally handles which ever directin the connection is attempted. The names of the objects are up to the user.

The ACL that defines the local and remote networks for the L2L VPN should use the NAT subnets of each site.

If you want to restrict the traffic from the remote site then this can be done in a couple of ways. At its default settings the ASA will allow ALL traffic from the remote site behind the L2L VPN connection.

You can use the command "show run all sysopt" to list some configurations that will tell us how your ASA has been set to handle VPN related traffic. The command we are looking for is "sysopt connection permit-vpn". This is the default setting that allows all traffic from VPN connections. If you were to change this to "no sysopt connection permit-vpn" then you could simply use the interface ACL of the interface that terminates the L2L VPN connection on your side to select what traffic is allowed. You would allow traffic the same way as if you were allowing traffic from Internet to your servers.

The problem with this setup is if you have other existing VPN connections (VPN Client and L2L VPN) because they would also require their traffic to be allowed in your external interfaces ACL if you changed the above mentioned global setting.

The other option is to configure a VPN Filter ACL that you will then attach to a "group-policy". You will then attach that "group-policy" to the "tunnel-group" of the L2L VPN connection.

The actual ACL used for the VPN Filter purpose is a norma ACL but you will always have to configure the remote network as the source in the ACL and this usually causes some confusion.

- Jouni

[Wouter Platteeuw]

Thanks :)