• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1481
  • Last Modified:

IPSEC VPN ACL

I have configured two Cisco 1721's with an IPSEC site-to-site tunnel.

The tunnel is up and running, but I cannot see the private networks behind each network. Each 1721 has an IPSEC ACL Rule which is assigned to each outside interface via the crypto map and the "match address 100" command. The "access-list 100" appears to be correct on each router, but I still cannot ping/browse/rdp to a workstation behind the "other router."

I am obviously missing something. Thanks!

0
swcrook
Asked:
swcrook
  • 14
  • 4
  • 2
2 Solutions
 
M1WCommented:
You would need to prevent the traffic from being nated. Something like this:

ip nat inside source list acl_nat interface FastEthernet0 overload

ip access-list extended acl_nat
 deny   ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 (source to destination in ipsec tunnel)
 permit ip 192.168.200.0 0.0.0.255 any
0
 
swcrookAuthor Commented:
I thought the same thing. I didn't even have nat turned on because I had made this configs from scratch. Lol, I have already turned it on just to turn it off with the above example you gave, except I didn't have a deny ip command. I bet that has something to do with it.

From what I can tell, does the deny keep unencrypted traffic from encrypted in the tunnel? Why would I need to deny "source to destination in ipsec tunnel" when it is the traffic in the tunnel that I want to pass through. I understand that I want to drop the natted packets that give the packet a natted address instead of the original, but I guess I am not understanding why I need to have "deny"?
Thanks for help!
0
 
M1WCommented:
Cause you want to make sure that the traffic going through the tunnel is not natted. But if you did not have nat turned on in the router before...it might have something to do with the routes...
0
What Security Threats Are We Predicting for 2018?

Cryptocurrency, IoT botnets, MFA, and more! Hackers are already planning their next big attacks for 2018. Learn what you might face, and how to defend against it with our 2018 security predictions.

 
swcrookAuthor Commented:
WHat should I be looking for in the routes? The only route that I have is the default route. Should I be putting a route in for the source to destination and vice versa? I guess I thought the VPN tunnel allows traffic, so why would there need to be a route? Sorry, working out my noobish logic.
0
 
swcrookAuthor Commented:
%CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac verify failed fo
r connection id=2001 local=173.x.x.x remote=68.x.x.x spi=7DFAF6FE seqno
=00000057
I see this error on branch router trying to connect to the main office. Any ideas?
Thanks
0
 
swcrookAuthor Commented:
On the main site router I see this when I test the tunnel which is up:
"A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not Fragment' packets.
Hope that helps. In the meantime, I am googling these errors. Thanks!
0
 
M1WCommented:
The decrypt error is most likely due to a key mismatch.
0
 
swcrookAuthor Commented:
I checked that and when I mistpe the key on purpose the tunnel will no come up. When I type it correctly, the tunnel comes back up. I read just a few minutes ago that it is a bug in 12.4, so I am loading 12.3 to see what happens.
0
 
swcrookAuthor Commented:
Ok, I started over but this time I used the SDM. I am able to get the "Test Tunnel" button to "VPN Troubleshooting completed." I do not have any errors on either end, but the tunnel shows as down.
My question is:
With the SDM, when I configure the IPSEC ACL Rule it asks me the source and destination IP or network. I have tried both, but when I insert the source as the internal IP and destination as the network on the other end, I get the above mentioned result of "VPN Troubleshooting completed." On the other hand, when I try to put in the source as the network 10.10.0.0 255.255.0.0 and 10.10.8.0 255.255.255.0 respectively, I get a "Failed" stating that the network "10.10.0.0" is routed through the IPSEC and that I need to check the routing table. I get that on both ends repsectively.

Should I be routing the network source to the network destination or should I be routing the internal interface to the internal interface? Should I be routing the internal interface to the other network? So,
10.10.0.1 ---> 10.10.8.1
or

10.10.0.0 ---> 10.10.8.0
or

10.10.10.1 ---> 10.10.8.0
Does that make any sense at all? I know I need to flip this for the other end, but I am not sure how to proceed. Thanks for the help.
0
 
swcrookAuthor Commented:
Can anyone help with this please?
0
 
swcrookAuthor Commented:
Is anyone available to tell me what I am not seeing? Thanks all.
0
 
andy_deruCommented:
swcrook,

The message you refered below says something about Path MTU size which is smaller than your LAN MTU sizes.
"A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not Fragment' packets.

solution:
a. allow fragementation: ip policy route-map clear-df-bit ...
b. adjust the MTU size to lower value. The value you should choose depend on the type of tunnel you use. But you could use 1400 to be on safe side.

I've found this article for you to read, just in case.
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
0
 
swcrookAuthor Commented:
Thanks Andy. I worked the MTU errors out on my own with some help from google. Now, I need advice on this post:


Ok, I started over but this time I used the SDM. I am able to get the "Test Tunnel" button to "VPN Troubleshooting completed." I do not have any errors on either end, but the tunnel shows as down.
My question is:
With the SDM, when I configure the IPSEC ACL Rule it asks me the source and destination IP or network. I have tried both, but when I insert the source as the internal IP and destination as the network on the other end, I get the above mentioned result of "VPN Troubleshooting completed." On the other hand, when I try to put in the source as the network 10.10.0.0 255.255.0.0 and 10.10.8.0 255.255.255.0 respectively, I get a "Failed" stating that the network "10.10.0.0" is routed through the IPSEC and that I need to check the routing table. I get that on both ends repsectively.

Should I be routing the network source to the network destination or should I be routing the internal interface to the internal interface? Should I be routing the internal interface to the other network? So,
10.10.0.1 ---> 10.10.8.1
or

10.10.0.0 ---> 10.10.8.0
or

10.10.10.1 ---> 10.10.8.0
Does that make any sense at all? I know I need to flip this for the other end, but I am not sure how to proceed. Thanks for the help.
0
 
swcrookAuthor Commented:
I cannot get the tunnel to come up though the SDM Vpn troubleshooting produces no errors. I have re-flashed several times and created the IPSEC fresh with no change in status. I am at a loss at this point.
0
 
M1WCommented:
0
 
swcrookAuthor Commented:
Thaks M1W. I only used the above numbers as examples. The actual network are 10.10.0.0 and 10.253.0.0 (branch). I can make the branch anything I want, so that is not set in stone. I am just doing some testing, but I am at a loss. Thanks for the help.
0
 
swcrookAuthor Commented:
Does anyone have an example of a working config that has basic VPn connectivity? I am using 12.3 and adv security IOS on both 1721's. I think I am having routing issues but I am not sure if it is routing or ACLs due to limited VPN experience. Thanks!
0
 
swcrookAuthor Commented:
I have attached the two configs in hope that someone will notice something out of the ordinary. These are editied just a bit from the default SDM config. I have checked many times that the crypto pre-share keys are the same, each router can get to the outside and ping the other external interface of each router, and each VPN troubleshooting goes through without errors but the tunnel doesn't come up.

If there are some settings that are a bit odd, it may be that way because I have tried adjusting just about everything while trying to get this to work. As you can see, these are basic configs. Any other tips on a better config are also welcome!
Thanks!

==========
BRANCH
==========
!
! Last configuration change at 22:40:13 NewYork Sun Feb 22 2009
! NVRAM config last updated at 22:40:16 NewYork Sun Feb 22 2009
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname BRANCH_VPN
!
boot-start-marker
boot-end-marker
!
logging buffered 52000 debugging
enable secret 5 xxxxxx
enable password xxxxxx
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
no ip subnet-zero
ip cef
!
!
!
ip audit po max-events 100
!
!
!
!
! 
!
crypto isakmp policy 2
 encr 3des
 hash md5
 authentication pre-share
 group 5
crypto isakmp key xxxxxxx address 12.x.x.x no-xauth
!
!
crypto ipsec transform-set MD5 esp-3des esp-md5-hmac 
!
crypto map SDM_CMAP_1 1 ipsec-isakmp 
 description Tunnel to 12.x.x.x
 set peer 12.x.x.x
 set security-association lifetime seconds 28800
 set security-association idle-time 28800
 set transform-set MD5 
 set pfs group5
 match address 100
!
!
!
interface Ethernet0
 ip address 10.253.0.1 255.255.0.0
 ip nat inside
 full-duplex
 crypto map SDM_CMAP_1
!
interface FastEthernet0
 ip address 173.x.x.x 255.255.255.252
 ip nat outside
 speed auto
 full-duplex
!
ip nat inside source route-map SDM_RMAP_1 interface FastEthernet0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 173.x.x.x
ip http server
no ip http secure-server
!
access-list 100 remark SDM_ACL Category=20
access-list 100 deny   ip 10.253.0.0 0.0.255.255 10.10.0.0 0.0.255.255
access-list 100 permit ip 10.253.0.0 0.0.255.255 10.10.0.0 0.0.255.255
!
line con 0
line aux 0
line vty 0 4
 password xxxxxxx
 login
!
end
 
 
==========
MAIN SITE
==========
!
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname VPN_MAIN
!
boot-start-marker
boot-end-marker
!
enable secret 5 xxxxxxx
enable password xxxxxxx
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
no ip subnet-zero
ip cef
!
!
!
ip audit po max-events 100
!
!
!
!
! 
!
crypto isakmp policy 2
 encr 3des
 hash md5
 authentication pre-share
 group 5
crypto isakmp key xxxxxxx address 173.x.x.x 255.255.255.252 no-auth
!
!
crypto ipsec transform-set MD5 esp-3des esp-md5-hmac 
!
crypto map SDM_CMAP_1 1 ipsec-isakmp 
 description Tunnel to 173.x.x.x
 set peer 173.x.x.x
 set security-association lifetime seconds 28800
 set security-association idle-time 28800
 set transform-set MD5 
 set pfs group5
 match address 100
!
!
!
interface Ethernet0
 ip address 10.10.8.1 255.255.0.0
 ip nat inside
 full-duplex
!
interface FastEthernet0
 ip address 12.x.x.x 255.255.255.248
 ip nat outside
 speed auto
 full-duplex
 crypto map SDM_CMAP_1
!
ip nat inside source route-map SDM_RMAP_1 interface FastEthernet0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 12.x.x.x
ip http server
no ip http secure-server
!
access-list 100 remark SDM_ACL Category=22
access-list 100 deny   ip 10.10.0.0 0.0.255.255 10.253.0.0 0.0.255.255
access-list 100 permit ip 10.10.0.0 0.0.255.255 10.253.0.0 0.0.255.255
route-map SDM_RMAP_1 permit 1
 match ip address 100
!
!
line con 0
line aux 0
line vty 0 4
 login synchronous
 !
end

Open in new window

0
 
swcrookAuthor Commented:
Alright, I have the tunnel up. I am not sure what it was, but I changed the main site 1721 to a out-of-box 1841 and it worked like a charm. Now, I just need to get traffic talking to each lan on the tunnel. When I add routes, what should I be looking at adding?

Main site lan = 10.10.0.0 255.255.0.0
Branch site lan = 10.253.0.0 255.255.0.0
Thanks!
0
 
andy_deruCommented:
What I could see in your last codes, is that you configured NAT overload on your external interface IP addresses.
Those addresses are in fact the so called VPN Gateways.
IPsec places headers on your VPN traffic using these Gateways as each source and destination IP addresses.
So Nating your internal IP address to these GW IP address, will confuse the encryption/decrytion process.
In your example:
Source: 10.10.0.x
Destination: 10.253.0.x
Will be translated by your NAT overload to:
Source: 12.x.x.x
Destination: 10.253.0.x
Conclussion: this package will not pass your VPN encryption rule.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 14
  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now