I have a remote office connect via a VPN tunnel using a 3015 concentrator, and terminating on an 1841 IS Router. The tunnel was built with no problems, but I couldn't ping to anything or from anything on the private ethernet side of the router doing VPN. During trouble-shooting, I applied an access-list allowing specific traffic so I could capture what was going on, and I saw traffic matching my ACL lines, so I went back and applied logging to each statment to see real time traffic. When I applied this logging however, miraculously, I now had good ping connection. Any specific reason why I had to apply ACL statements with logging to have traffic pass? Thanks in advanced!
I am not aware of anything that would require logging for the access list to work. Is it possible that you changed something in the access list as you added logging (or is it possible that the previous version of the access list - without logging - did not quite match the entry in the crypto map) ?
One good way to investigate this would be to remove logging from the access list and see if that changes connectivity.
I double checked and re-checked my ACL statement, and the only difference is the logging command. I am using a text editor so I am just copy and pasting to ensure no typos.
What I don't understand is why I would need an ACL in the first place to allow connectivity, and second with an ACL, why it took the log command to allow it to work. I am adding more proccesses in my CPU this way, I am concerned about bogging down the router.
Maybe it is time for me to check on my assumptions. When you said it was an 1841 doing VPN I assumed that the 1841 config includes a crypto map to configure the IPSec. And I assumed that the crypto map includes a reference to an access list which identifies traffic to be protected by IPSec. And I assumed that the access list which was getting logging was the access list in the crypto map. If some of my assumptions were wrong perhaps you can help me understand better what we are talking about. And maybe you can also supply a few details about what was not working ans what was working.
You are correct in your assumption that it is the 1841 performing the VPN encryption. And There is an ACL that is defining the interesting traffic (in the case ACL 100). The VPN tunnel in itself was fine. I was able to ping across the tunnel to the head office and vice versa using 192.168.3.1 (the ethernet port on the router). However, I could not ping anything from lets say my switch on the actual lan (192.168.3.250) and vice versa.
I created 2 new access-list (150 and 151) to match icmp traffic from a source at my location and a destination of 192.168.3.250 (the switch on the lan). I also added permit ip any any so not to block any traffic to my lan. 150 was used for egress 151 was used for ingress, and I applied the ip access-groups to the fa 0/0 interface.
I ran my pings again, and was still getting timeouts, but if I looked at my access-lists, I was beginning to see matches for echos and echo-replys for the respective ip addresses. As a note, I still had no reachability to anything on the lan over the VPN tunnel excepth that of the fastethernet ip address.
The only alteration I made to my ACLs at this point is to add the log command to see real time traffic. I wasn't expecting to recieve the echo-replys, at this point, I thought it had to do with routing within the router, or a problem with my No Nat statement. But after I had my ACL log matches, sure enough I was able to ping all the devices I was unable to before.
Now I have 2 ACL list applied to my fastethernet interface (and it is the only way I have been able to come up with that has been allowing my router to pass traffic over the VPN from the LAN or to the LAN)
Extended IP access list 150
10 permit ip any any log (19202 matches)
Extended IP access list 151
10 permit ip any any log (28263 matches)
If you know why I would need an ACL on my ethernet int in the first place, I would love your feedback. Even better, if you could explain to me why in the world logging would make a difference I would be in awe. I know this set-up increases latency on the line, but it is the only way that it will work. Thanks again for your time.
Thanks for the additional information. While it helps some I am still a bit puzzled about a few aspects. I am not certain what the problem is, but your additional information does give me an idea.
When you add the log keyword to the access list it forces that packet to be process switched (which is why there is some performance hit and increase in latency). Apparently when the packet is process switched it is routed correctly and when it is not process switched it is not. So perhaps we need to look for something in CEF or in Fast Switching (depending somewhat on what code you are running and some details of your configuration) that is not correct. If you save the config and reboot the router does the problem remain or does the problem go away?
Thank you so much for poining me in the right direction. Although I have ran a series of debugs and examined the cef adjecency table, I still can't figure out why cef can't switch my packets properly. I am including a copy of my running config, and if you get the chance maybe you can spot something that is causing my router to act the way it is.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :