cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
752
Views
0
Helpful
11
Replies

VPN Routing Question

westernmotor
Level 1
Level 1

When creating a lan-to-lan VPN connection between a Cisco ASA 5505 device and a Cisco 2811 router, I end up getting connected, but I'm unable to ping the remote location. I also get decapsulated packet errors on one end. I am getting tips on how to fix this, and most of them are telling me to make sure I have the appropriate routes set up. My question is...do I have to create or establish a route for the traffic that is destined for the remote connection on the other side of the VPN tunnel?

1 Accepted Solution

Accepted Solutions

Kevin

While 103 may be used as a NAT rule it IS an access list. Just look at the syntax:

access-list 103 remark SDM_ACL Category=2

access-list 103 permit ip 10.4.167.0 0.0.0.255 any

access-list 103 remark IPSec Rule

access-list 103 deny ip 10.4.167.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 103 remark IPSec Rule

access-list 103 deny icmp 10.4.167.0 0.0.0.255 192.168.1.0 0.0.0.255

Access lists can be used for many things. They are more than just packet filters: they can be used in distribute lists to filter routing updates, they can be used in route maps as part of policy based routing, they are used in VPN to identify traffic to be protected by the IPSec, and they can be used as NAT rules. But access lists have certain traits and one of them is that they are processed in order and once you get to a statement with a true condition (a match) then it does that action and does not look at any other statements in the access list. Since the first statement in 103 is a true match it will never look at the second statment.

So the order of statements is 103 is not correct. Change the order and tell us if the behavior changes.

HTH

Rick

HTH

Rick

View solution in original post

11 Replies 11

Richard Burts
Hall of Fame
Hall of Fame

Kevin

I am not sure what you have been looking at that suggests that it may be a routing issue. From the symptoms that you describe I would believe that it is more likely an issue that the access lists that identify traffic to be protected by the VPN do not match than it is an issue of routing. As far as routing is concerned you basically need to have routes that send the traffic out through the interface where the crypto map is active.

HTH

Rick

HTH

Rick

That's what I thought. However, I have the correct access-lists set up, so I'm stuck. Here they are:

I checked ACL on both routers and the ACL_INT_IN (outside interface) is set to permit traffic from remote network and source network. Still no luck.

2811 settings: ip access-list extended sdm_fastethernet0/1_in permit ip 192.168.1.0 0.0.0.255 10.4.167.0 0.0.0.255

ASA Settings: access-list outside_20_cryptomap extended permit ip 192.168.1.0 255.255.255.0 10.4.167.0 255.255.255.0

Kevin

If the ACL on the 2811 has 192.168.1.0 as the source then I would expect the ASA to have that network as the destination. But both devices have the same network as source and the same network as destination. Unless there is something else going on here that we do not yet know about I believe that this is not correct.

Perhaps you could post configs from both the 2811 and the ASA? This would help to clarify what is going on.

HTH

Rick

HTH

Rick

"2811 settings: ip access-list extended sdm_fastethernet0/1_in permit ip 192.168.1.0 0.0.0.255 10.4.167.0 0.0.0.255

ASA Settings: access-list outside_20_cryptomap extended permit ip 192.168.1.0 255.255.255.0 10.4.167.0 255.255.255.0"

If both sides use the same local and remote

encryption domain, you have to double-NAT both

sides for this to work. For example, you

have to make 192.168.1.0/24 appears as 10.1.1.0/24 to the ASA and 10.4.167.0/24

appears as 10.1.2.0/24 to the 2811. It is

not a difficult task but a pain in the ass

to configure in ASA.

This thing could be done in 2 minutes with

Checkpoint firewalls due to the simplicity

of the SmartDashboard NAT translation.

CCIE Security

Not sure that I understand "encryption domain". One end of the tunnel has a network of 10.4.167.0. This is the network of the main office we support here. The other ends network is 192.168.1.0. It's the network that I am trying to "tie into" the main bldg network. I'm posting my current running-configs for you to look at.

Good find. However, even after changing that, I still have the same problem. I'm posting my configs here for you to review. Very appreciative of the assitance. I've been pulling my hair out on this one. I'm by no means an expert cisco tech, so this is confusing.

Kevin

It is pretty complex and there are several things in the config that seem strange to me. But I believe that the essence of your problem is the address translation on the 2811. The address translation is controlled by a route map SDM_RMAP_3 which uses access list 103. The first permit in that access list is this:

access-list 103 permit ip 10.4.167.0 0.0.0.255 any

following that line is this:

access-list 103 deny ip 10.4.167.0 0.0.0.255 192.168.1.0 0.0.0.255

this line attempts to deny traffic sourced from 10.4.167.0. But it will have no effect because the preceeding permit has already permitted that traffic.

I believe that the result is that the VPN traffic is being translated on the way out and messing things up. If you correct the order of statements in access list 103 I believe that it will work better.

HTH

Rick

HTH

Rick

103 is a NAT rule (not an ACL). SDM_RMAP_3 uses this NAT rule. The first entry (permit ip 10.4.167.0 0.0.0.255 any) was created by the wizard to NAT traffic from 10.4.167.0 to the Internet. The second entry was created by the VPN wizard so that traffic from 10.4.167.0 that is destined for 192.168.1.0 NOT be NAT'ed. Is this config wrong?

Kevin

While 103 may be used as a NAT rule it IS an access list. Just look at the syntax:

access-list 103 remark SDM_ACL Category=2

access-list 103 permit ip 10.4.167.0 0.0.0.255 any

access-list 103 remark IPSec Rule

access-list 103 deny ip 10.4.167.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 103 remark IPSec Rule

access-list 103 deny icmp 10.4.167.0 0.0.0.255 192.168.1.0 0.0.0.255

Access lists can be used for many things. They are more than just packet filters: they can be used in distribute lists to filter routing updates, they can be used in route maps as part of policy based routing, they are used in VPN to identify traffic to be protected by the IPSec, and they can be used as NAT rules. But access lists have certain traits and one of them is that they are processed in order and once you get to a statement with a true condition (a match) then it does that action and does not look at any other statements in the access list. Since the first statement in 103 is a true match it will never look at the second statment.

So the order of statements is 103 is not correct. Change the order and tell us if the behavior changes.

HTH

Rick

HTH

Rick

That WORKED!!! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you!

Kevin

You are quite welcome. This is what the forum is about. Thank you for using the rating system to indicate that your problem was resolved (and thanks for the rating). It makes the forum more useful when people can read about a problem and can know that they will read what was able to successfully resolve the problem.

The forum is an excellent place to learn about Cisco networking. I encourage you to continue your participation in the forum.

HTH

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: