cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
265
Views
0
Helpful
2
Replies

IOS VPN on 7200 12.3.1 and access-list problem

r.parlier
Level 1
Level 1

I am running IOS 12.3(1) on a 7200 and have configured it for VPN access. I'm using Cisco's VPN client. Am wondering if anyone else has seen the following problem and if there is a fix.

The outside interface has the usual access-list applied that blocks incoming traffic. One of the rules is to block private, non-routable IPs, such as the 10.0.0.0 range, for example.

When I establish my VPN connection, none of my packets get routed and I noticed that the outside interface access-list is blocking the traffic. When I connect to the router via VPN, the router assigns the client an IP address from a VPN pool, such as 10.1.1.0/24. But the normal outside access-list denies such traffic as it should. But once I establish a VPN connect, it seems my encrypted VPN traffic should bypass the outside interface access-list.

If I modify my outside access-list to allow traffic from source address 10.1.1.0/24 my VPN traffic gets through properly, but this defeats the purposes of having an outside access-list that denies such traffic and having a VPN.

Anyone else seen this problem and/or can recommend a fix or IOS version that works properly??

thanks,

-R

1 Accepted Solution

Accepted Solutions

gfullage
Cisco Employee
Cisco Employee

This is how IOS has always worked, no way around it.

The reasoning is to do with the internal routing in the router. Basically an encrypted packet comes into the interface and initially passes the ACL check as an encrypted packet. It then gets sent off the crypto engine and decrypted, so we now have this packet sitting in the crypto engine portion of the router. What do we do with it now, keeping in mind users may want to policy route it as it comes in also, may want to perform qos on it, etc, etc. For this reason the packet is basically put back on the outside interface and run through everything again, this time as an unencrypted packet. So the packet hits the ACL twice, once encrypted and once unencrypted.

Your outside ACL will have to include both the unencrypted and the encrypted form of the packet.

Now, if you're worried that people can then simply spoof packets to come from 10.1.1.0 and they'll be allowed through your router, bzzzt, wrong. The first thing the router checks when it receives a packet on an interface with a crypto map applied to it is if the packet should be encrypted, this is based on its crypto ACL's and its IP pools. If it receives an unencrypted packet when it knows that it should have been encrypted, it'll drop the packet straight away and flag a syslog something like "received unencrypted packet when it should have been".

You can check up on the old bug on this here:

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdz54626&Submit=Search

and take careful note of the security implications section, you may need to change your config slightly.

View solution in original post

2 Replies 2

gfullage
Cisco Employee
Cisco Employee

This is how IOS has always worked, no way around it.

The reasoning is to do with the internal routing in the router. Basically an encrypted packet comes into the interface and initially passes the ACL check as an encrypted packet. It then gets sent off the crypto engine and decrypted, so we now have this packet sitting in the crypto engine portion of the router. What do we do with it now, keeping in mind users may want to policy route it as it comes in also, may want to perform qos on it, etc, etc. For this reason the packet is basically put back on the outside interface and run through everything again, this time as an unencrypted packet. So the packet hits the ACL twice, once encrypted and once unencrypted.

Your outside ACL will have to include both the unencrypted and the encrypted form of the packet.

Now, if you're worried that people can then simply spoof packets to come from 10.1.1.0 and they'll be allowed through your router, bzzzt, wrong. The first thing the router checks when it receives a packet on an interface with a crypto map applied to it is if the packet should be encrypted, this is based on its crypto ACL's and its IP pools. If it receives an unencrypted packet when it knows that it should have been encrypted, it'll drop the packet straight away and flag a syslog something like "received unencrypted packet when it should have been".

You can check up on the old bug on this here:

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdz54626&Submit=Search

and take careful note of the security implications section, you may need to change your config slightly.

Thanks for the pointer. Have never setup the IOS to do client VPN access 'til now and this one sorta bugged me. I don't remember this being mentioned in any of the cisco docs while I was reading up on how to set it all up.

Will have to add "match address" since I am using dynamic crypto-maps.

I will also need to document this one as others will certainly be confused when they see it on the router.

Thanks for the reply.

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: