Hmm if you can ping from end node 1 to end node 2 then your IPsec tunnel is up and running. If you are able to ping within the local subnet then at least you know your IP addresses are configured correctly. Couple of things to check/try here:
Do your webservers have a correct default gateway? Maybe they don’t know how to get outside of their own subnet.
The ACL that you use for your IPsec tunnel. Does it permit all traffic between 192.168.1.0/24 and 192.168.2.0/24? Make sure it matches the traffic that you want to get through the tunnel.
Rene
shantel
(Shantel - Networklessons.com)
Split this topic
62
I have a question regarding IPSEC VPN.
If there are many crypto isakmp policy configured on the ASA, how do you know which crypto isakmp policy is being used by the IPSEC VPN tunnel?
The command show crypto isa sa detail will show you the values for the encryption hash and so on, however it does not give you the number of the policy in use. Looking at the hash you can then determine the policy, however a more elegant way would be to initiate a debug crypto isakmp and bring the tunnel down and back up again and follow the phase one negotiation messages. The debug messages will show the router going through each individual policy until it finds a match and you can determine which policy was matched.
In case if you configure an ACL at Inside interface (IN) to allow the access from inside to outside, do we need to create an ACL at Inside interface for each new Tunnel to allow the traffic between encryption domain.
I’m not quite sure I fully understand your query, however, I will answer and if you need clarification, you can let us know.
In the lab, the access list access-list LAN1_LAN2 was specified in order to indicate the subnets of the internal networks on each end of the VPN. This access list was then used in the crypto map MY_CRYPTO_MAP 10 match address LAN1_LAN2 command to indicate that these are the subnets that will be sent over this specific VLAN.
Now if you have additional tunnels to create on one of the devices, then you will require a new access list that defines the subnets that will be participating in that tunnel. For each tunnel, a different ACL must be configured along with all its crypto and other associated commands.
Hi How can we allow specific traffic on this tunnel, i tried to change the access-list but it didn’t worked for me. I want to allow http on this tunnel and other traffic should be restricted?
Hi Rene i did the lab site- to site ikev1 IPsec but I had difficulty. My question is tunnel-group type IPSec i did not use a 121 because I couldn’t get it so is that must to use type-121? Thank you very much.
I recently deployed a pair of ASA at two different customer sites. Both ASA’s terminate both an MPLS circuit and an iNet circuit. I’m running EIGRP with the MPLS provider on both ASAs, so both sites can route to each other.
The goal is for Site2 to reach Site1 over the MPLS circuit. This works - no problemo
The second goal is for Site 2 to route via L2L VPN tunnel back to Site 1, should the MPLS go down. This is where I’m having an issue.
When I configured a L2L VPN, my NAT exclusion statement at Site 2 is getting hit for some reason when the MPLS is up and I generate traffic FROM site 2 TO site 1. As such, the traffic never goes over the MPLS.
Here’s my config for Site 2 (Site 1 is the same, just with a reversed ACL and NAT statement)
I THOUGHT that the NAT shouldn’t get hit because a route is learned via EIGRP over the MPLS link, which terminates on the ASA). I have a floating static pointing to the outside interface on the ASA at site 2 in case the MPLS goes down.
However I see the NAT getting hit and traffic not flowing over the MPLS from site 2 to site 1. When I remove the NAT, traffic flows over the MPLS as expected.
I feel like this is a simple fix, but I’m missing something terribly obvious that’s causing traffic to get pushed to the outside interface.
Ok, so I figured it out and thought I’d share my solution in case anyone else is having a similar issue with using a L2L VPN exclusively for backup traffic, i.e. not passing traffic so long as the primary MPLS path is available.
I’ll skip to the chase and point out this is what I was missing, which I’ve added in bold below
Ok, basically NAT on an ASA influences routing. If you have a NAT statement, as I did above, without the keyword route-lookup then just by the mere existence of that NAT statement, the ASA will match packets against the source and destination portions of the NAT (obj-site-2 and obj-site-1, respectively) and if a match is found, it will route that traffic out the interface specified by the NAT.
In the example above, traffic coming from the networks specified in obj-site-2 and going to the networks specified in obj-site-1 will be routed out the outside interface. If you add the keyword route-lookup, then you tell the ASA to not automatically route out the outside interface and instead look to the route table for the traffic’s next-hop.
There’s one other command needed to make everything work, and that’s a floating static default to the outside interface. If the MPLS went down, then the route to site-1 would disappear. As such, we need this to push traffic out the outside interface, both for iNet destinations and Site-1 (which would then get matched by the crypto map and pushed out the VPN). Incidentally, part of the design was to backhaul iNet traffic over the MPLS, which is why I use a default route here.
In the lesson configuring ipsec between two sites with static ip address it does not mention NAT exemption anywhere, shouldn’t it be included? Also, it would be helpful if you can elaborate a bit on NAT-T.
Johnny
Can you specify which lesson in particular you are referring to? There are several site to site VPN lessons using the ASA on the site. Let us know and we can answer your question more appropriately.
As for NAT-T, IPsec VPN clients can use NAT traversal to allow for ESP (Encapsulating Security Payload) packets traverse NAT. Several protocols within the IPsec framework must be enabled to traverse both firewalls and NAT including IKE, ESP, AH. UDP port 4500 is used for IPsec NAT traversal. These features are sometimes called IPsec Passthrough features.
If you would like Rene to consider including a lesson on NAT-T and IPsec, feel free to make a suggestion at the Lesson Ideas link below:
For this particular lesson, Rene is focusing on the configuration of the site to site IKEv1 IPsec VPN without incorporating other features such as NAT and NAT exception to exempt traffic from being NATed that is destined for the remote site over the VPN. However, for a more detailed look at NAT exemption, take a look at this lesson which includes this particular feature:
It is viewed from the point of view of a single remote user connecting to a VPN using an ASA, but the principle is the same for the implementation in a site to site VPN as well.
I am having issues pinging from the outside of my ASA to test peer connectivity between my 2 ASA Firewalls.
I have configured policy-map for the class inspection_default
ASA1(config)# show run policy-map
!
policy-map type inspect dns migrated_dns_map_1
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns migrated_dns_map_1
inspect ftp
inspect h323 h225
inspect h323 ras
inspect ip-options
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect icmp
inspect icmp error
Configured Access-list on both firewalls to allow ICMP traffic echo and echo-reply:
ASA1(config)# show access-list LAN1_LAN2
access-list LAN1_LAN2; 3 elements; name hash: 0xed8ba9f
access-list LAN1_LAN2 line 1 extended permit icmp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 echo (hitcnt=0) 0x73945c45
access-list LAN1_LAN2 line 2 extended permit icmp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 echo-reply (hitcnt=0) 0x3d6749e7
access-list LAN1_LAN2 line 3 extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 (hitcnt=0) 0x4db4c657
It seems you are trying to ping from the INSIDE interface of ASA1 to the INSIDE interface of ASA2. This will be difficult, as your ASA won’t NAT translate its own local traffic.
That should work.
