Hello Rene,
How are you?
I followed the steps for configuring site to site VPN between two sites having commercial routers provided by ISP and cannot seem to establish the connection.
When i generate interesting traffic the status goes to WAIT status and then the connection drops off after a while.
Below is the config:
When implementing the configuration of this lesson on a real world application with commercial ISP routers, you have to keep a few things in mind. In the lesson, the two ASAs were on the same subnet (this subnet simulated the Internet or some other large network), but in the real world, there are various other mechanisms that exist between the two ASAs that can disrupt the formation of a tunnel.
Questions you should consider include:
Is NAT running on the commercial routers at each site?
Are the commercial routers running additional firewall features that may be blocking communication?
Are the public IP addresses used on the commercial routers themselves or are the configured on the ASAs? If they are on the commercial routers, are the static?
My suggestion would be that you first ensure that communication between the ASAsâ outside interfaces is successful before you go on. Once thatâs done, make sure no other mechanisms (NAT, firewall etc) in the commercial routers is hindering your communication.
One other alternative to test your configuration (if possible) is to bring the two ASAs together and test them by connecting them directly and see if the VPN comes up. If it does, then the problem is indeed at the commercial routers.
Hopefully this will give you some more insight and clues to help you in your troubleshooting proceduresâŚ
Whether you use private addresses such as 10.10.10.0/24 or public addresses such as 147.52.3.0/24, it will make no difference in the actual configuration. For the purposes of this lab, a private address range was chosen, but if you like, in your GNS3 lab, or in your home lab, you can use public addresses as well.
In the real world, how you would configure this depends upon the way in which you connect to the Internet. In some cases, the E0/1 interfaces of the ASAs would be assigned a static public IP address provided to you by the ISP. In others, the ISP may provide you with some termination equipment such as a modem, a router, or a switch to which you must connect your ASA. That termination equipment may have a static or a dynamic public IP address. In such a case you may still be assigned a private address on your ASA, and may have to traverse NAT or some other translation service at your network edge.
In order to make this work, however, you will require to have a static routable IP address on at least one end of the link.
How you will end up creating the link will depend upon the topology of the edge of your network. There are various ways to deal with these scenarios, but for the purpose of this lab, the idea was to understand the configuration of the ASAs for a site to site IPsec VPN.
This lesson deals with the scenario where you have one firewall with a static address, and another firewall with a dynamically assigned address. In the case of the lesson, ASA1 has a static IP address, and since it is static, we know what it is. ASA2 has a dynamically assigned address, and thus we donât know what it is. It could be anything at any time.
For this reason, this configuration allows you to set up a site-to-site IKEv1 IPsec VPN without the need to know the actual IP address of ASA2. Thus, we specify the IP address to which the ASA2 must connect, that is, the IP address of ASA1. We donât specify the IP address to which the ASA1 must connect simply because we donât know it.
The ASA2 initiates the communication such that the ASA1 will be able to dynamically learn the IP address of the other end of the tunnel.
This is a scenario that we find often when we use cable or xDSL connections that donât have static IP addresses associated with them.
Just a general query about VPN on ASA, do we need Access Rules to allow VPN traffic. If not, which configuration is required to allow access to VPN traffic automatically.
When creating a VPN on an ASA, you do have to define what traffic is going to be encrypted and sent over the VPN. This is defined using an access list that is then referenced by the crypto map command. In this lesson, this is done using the LAN1_LAN2 access list on ASA1 for traffic going from the ASA1 to the ASA2, and the LAN2_LAN1 access list for traffic in the other direction.
If you want to allow all traffic to be encrypted, you simply change the access list to include all traffic using the âany anyâ keywords (for any source and any destination). Look at the lesson on Extended Access Lists for more info on that syntax.
So when comparing to other firewalls. We only need to add the Phase 2 on VPN and no Firewall policy is required. I mean no need to add the VPN subnets on the access-group ACL which is applied on the Interface. Right?
If above is true, then lets assume we have Site-to-Site VPN for Internet via Data Center from ASA. How would I restrict unwanted traffic from Clients to go on Internet.
Yes that is correct. Take a look at this particular lesson, which doesnât involve dynamic peers. You can see that the access list that defines the traffic that is going to be encrypted (and thus sent through the tunnel) is defined by the access list that is then referenced in the crypto map. This does take place in Phase 2.
Since we are talking about a Site to Site scenario, I assume that when you say âclientsâ you donât mean VPN clients, but hosts in a particular network, right? If that is the case, then you donât need to restrict unwanted traffic by using mechanisms of the site to site VPN. You can do this independently from any VPN configuration, either at the remote location or at the datacenter, using ACLs, or other filtering mechanisms.
In a typical setup for a site-to-site IPsec VPN using Cisco ASA, you donât need specific static routes for the remote IPs that are used in phase 2 selectors. The phase 2 âselectorsâ are essentially the defined address ranges within the crypto ACL that specify the interesting traffic for the VPN. These are the subnets or hosts you wish to protect by the VPN.
When traffic matches the criteria specified in that ACL, the VPN is invoked and the traffic is sent over the tunnel.
The Cisco ASA will route traffic based on its routing table. It checks the destination of the packet and finds the egress interface. If the traffic matches an interesting traffic defined for a VPN tunnel, then the traffic is encrypted and sent through the tunnel. Otherwise, it is routed normally as per the routing table.
So in the context of a dynamic peer setup, where the remote IP can change, the most important factor is the crypto ACL or the âselectorsâ for the IPsec tunnel, not the static route. You should configure your ACLs to match the expected traffic from your network to the dynamic peer networks.
Your default gateway towards the WAN IP will route normal traffic, and not traffic that is matched by the ACL. That traffic will be encrypted and will be sent through the VPN tunnel. If traffic matches such an ACL, no routing information is necessary, since the VPN is a point-to-point construct. This is further illustrated in this NetworkLessons note about VPN default gateways for clients.
Twice NAT is not always necessary depending on the network configuration and requirements. Twice NAT, or bidirectional NAT, is typically used when both the source and destination IP addresses need to be translated. This is common in complex networks where overlapping IP address spaces exist.
However, in this particular network setup, it is not necessary.
In a real-world scenario where you would have private addresses behind each ASA, you would employ NAT at each ASA, but you would still not need twice NAT. The only time you would need it in a topology similar to the one in the lesson is if you have overlapping address spaces at both remote sites. Here we have non-overlapping IP address spaces.
Itâs also worth noting that twice NAT can add complexity to the network and make troubleshooting more difficult. So, unless itâs necessary for your specific network design or requirements, itâs often avoided.