cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1807
Views
4
Helpful
13
Replies

Crypto map policy

ycae
Level 1
Level 1

Hi all,

I have configured a IPSEC VPN between 2 routers which are connected through a E1 line. Of course i don't want to encrpyt everything so I've set up a policy to just include certain addresses. Out of that range of addresses I would like to exclude some. So I though that this would work if I would add an access-list deny as first line for the host I want to exclude. What happened is that the router at the remote site sent the packet unencrypted and the local router with the same access-list complained about the packet not being encrypted. What am I doing wrong?

Here is the access list: (very basic as you will see)

access-list 115 deny ip xxx.xx.xxx.x 0.0.0.31 host xxx.xx.xxx.xx

access-list 115 permit ip xxx.xx.xxx.x 0.0.31.255 xxx.xx.xxx.x 0.0.31.255

If someone has an idea, I would appreciate.

Thanks,

Yves

1 Accepted Solution

Accepted Solutions

Yves

Perhaps a different way of thinking about the access list might help. The way that access lists function in VPN to identify traffic to be protected is significantly different from the way that access lists function when applied to an interface as a packet filter. When you apply the access list to an interface you must specify a direction (in or out) and that direction defines what is source and what is destination. But VPN does not assign the access list as in or out. In fact the same access list is used to examine inbound and outbound traffic and the IOS makes appropriate adjustments about what is source and what is destination. So for access list with VPN it may help to think of the addresses in the access list as "local" (source) and "remote" (destination).

HTH

Rick

HTH

Rick

View solution in original post

13 Replies 13

Yves,

When creating access lists for crypto, they need to mirror images of each others on the two routers forming an IPSEC tunnel. If you exclude the host using a deny on one of the routers, you need to do the same to fix the problem.

-- Pushkar

Hi,

Well that's what I did....that's the strange thing...the policy was exactly the same on both routers.

But I will retry it tomorrow and let you know.

Yves

Still doesn't work....quite strange since I copied the exactly sam policy on the 2 routers and the receiving router is always complaining that it gets an unencrypted packet.

If somebody has an idea, i would appriciate

Yves

Yves

It would be helpful if you would post the crypto policy and the access list used to identify traffic for IPSec for both routers.

HTH

Rick

HTH

Rick

Hi Rick,

Here is the configuration of the crpyto map and the access-list. Both routers have the same configuration. The crypto is applied on the WAN interface.

crypto map xxxxxxxxx 1 ipsec-isakmp

set peer xxx.xx.xxx.xx

set transform-set rtpset

match address 115

access-list 115 permit ip xxx.xx.xxx.0 0.0.31.255 xxx.xx.xxx.0 0.0.31.255

What I want to do is to add a deny rule for a certain address. So I want to change my ACL that it looks like this:

access-list 115 deny ip xxx.xx.xxx.0 0.0.0.31 host xxx.xx.xxx.xxx

access-list 115 permit ip xxx.xx.xxx.0 0.0.31.255 xxx.xx.xxx.0 0.0.31.255

Of course this policy is installed on both routers. And the sending router is sending tha packets unencrypted but the receiving one just complains that the packets are not encrypted eventhough it has the same access-list.

If you need more information, just let me know.

Thanks for your help

Yves

Yves

I can not tell from what you posted whether you mean that both routers have exactly the same access list? I would expect that the source address and destination address would be reversed in the ACL on the other router. Can you clarify this?

HTH

Rick

HTH

Rick

HI,

Sorry that I didn't post the complete ip addresses but we are not allowed to post to much information due to corporate policy.

However, both policies are exactly the same and are not reversed...why should they since the source and destination will always be the same. I think this would play a role if the return packet would have a problem but i dono't even get there.

Sad that we cannot attach a small map here.

Yves

Yves

I believe that this would be much easier to discuss (and perhaps to solve) if we had specifics to discuss. But I do understand corporate policies must be observed.

Let me just try to explain it this way: your deny statement specifies host x as the destination address. On one router host x would be the destination. On the router on the other end of the VPN tunnel host x would not logically still be the destination would it? Host x is on one end of the VPN or the other (how could it be on both ends?). So on one end it is the destination and on the other end it is the source.

I suggest that you try reversing the addresses on one end (only you have enough information to determine which end should reverse - only you know where host x really is located) and let us know what happens.

HTH

Rick

HTH

Rick

Hi Rick,

Let's assume the following network:

* Host A * ------> * Router A * -----VPN------- * Router B * ----------> * Host B *

So Host A wants to communicate with Host B but unencrypted. But for all the other connections everything should be encrypted.

So my configuration would be as follow on both routers:

access-list 115 deny ip host HOST A host HOST B

access-list 115 allow ip any any

With tis configuration on both routers I would assume that if I try to make a telnet from Host A to Host B, that this traffic is not encrypted but what happens in my real network is that the connection is dropped on router B since the message received from Router A is not encrypted (which is correct since the access rule specifies it like that) but Router B is complaining about the packet being unencrypted.

Furthermore you say that I have to reverse the hosts in the access-list since the source and the destination changes. This I don't understand since on Layer 3 nothing is changed. If I sent a packet form A to B my Source will always be A and my destination will always be B and this won't change only because I pass the packet through a router.

Hope that this clears up the situation.

Yves

Yves

Perhaps a different way of thinking about the access list might help. The way that access lists function in VPN to identify traffic to be protected is significantly different from the way that access lists function when applied to an interface as a packet filter. When you apply the access list to an interface you must specify a direction (in or out) and that direction defines what is source and what is destination. But VPN does not assign the access list as in or out. In fact the same access list is used to examine inbound and outbound traffic and the IOS makes appropriate adjustments about what is source and what is destination. So for access list with VPN it may help to think of the addresses in the access list as "local" (source) and "remote" (destination).

HTH

Rick

HTH

Rick

Hi Rick,

Thanks for the explanation, I didn't know that. I will give it a try tomorrow.

Thanks again.

Yves

Hi Rick,

It worked.

Thanks for your help.

Yves

Yves

Thanks for updating and indicating that it is now working. I am glad that my explanations helped you to resolve your problem.

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: