About Richard Burts

Richard Burts · ‎08-16-2018

Gayan You are welcome. Do let us know the results when you have tried this approach. HTH Rick

Richard Burts · ‎08-16-2018

Thanks for the additional information. I understand that your VPN is working with policy 1 and I understand that you will be changing to use policy 2 which is much more secure. What I am trying to explain is that as you make changes to implement policy 2 that the peer device also needs to make similar changes to implement a new policy that will match your policy 2. HTH Rick

Richard Burts · ‎08-15-2018

I seem to remember from the days when I taught the ICND course that a static route recursive lookup could not use a dynamically learned default route to resolve the next hop. I have searched Cisco documentation but have not found a reference for that. But I did find results from my colleague and friend Peter Paluch which confirm this: Sadly, there does not seem to be any documentation regarding this. But I've checked the IOS source code, and I can safely state this - even correcting myself to a certain extent: If the default route is static itself and specified using the outgoing interface (in other words, it must be treated as a directly connected network), such as ip route 0.0.0.0 0.0.0.0 Serial2/0 it will be used to recursively resolve the next hops of other routes. In all other cases, such as a default route configured using a next-hop IP address or learned from a dynamic routing protocol, it will not be used to resolve the next hops of other routes. Here is the link if you want to see the details https://community.cisco.com/t5/routing/recursive-lookup-in-static-routing/td-p/2356941 So I believe that the answer to the current question is that trying to use a static route with recursive lookup for the default route learned via EIGRP does not work. Is there any route, other than the default route, that is advertised from AS1 via EIGRP to the switch? If so then use that host, or subnet, or network in the static route for AS2. If there is not any other route advertised from AS1, can you ask the admin in AS1 to advertise some route along with the default route? HTH Rick

Richard Burts · ‎08-15-2018

Thanks for the additional information. I am guessing that when you created the new crypto map that you used the same access list to match traffic and identify what is to be encrypted in the new map entry that was used in the existing map entry. So now you have two entries in the crypto map each trying to identify the same traffic. That is what the message is about. My suggestion would be for now to put a different ACL in the new crypto map entry (probably configure the ACL to match on source addresses that do not exist on the ASA so that it will not attempt to encrypt any traffic). That will allow you to save the config changes. Then at the time when the new ISP is active and you want to switch over you will change the match statement in the original crypto map entry (or perhaps remove the original crypto map entry) and change the new crypto map entry to use the right ACL. Then traffic will use the new crypto map and your VPN should work. HTH Rick

Richard Burts · ‎08-15-2018

In my previous response I did think about VTI. And I believe that it does not apply in this case. The original post very clearly talks about an ACL for interesting traffic. VTI does not have any ACL for interesting traffic and traditional IPSEC does have an ACL. So I am pretty comfortable believing that we are talking about traditional IPSEC in this discussion. In a more broad discussion about behavior of encrypted traffic it is certainly appropriate to compare behaviors of traditional IPSEC and VTI and to observe that a more specific static route might point at a different exit interface and next hop than the route for the /24 and therefore might cause the traffic to not be encrypted. HTH Rick

Richard Burts · ‎08-14-2018

The other simple thing that I can think of is the possibility that SSH might not go to the switch you expect (perhaps far fetched but it did happen to me once). Perhaps do your SSH, change the host name, access the console, login, check the host name. HTH Rick

Richard Burts · ‎08-14-2018

Only other simple thing I can think of would be to change enable secret to test1, show run and copy the encrypted value of enable secret, then change enable secret to cisco123, show run, compare the encrypted value of enable secret, make sure that it did change. HTH Rick

Richard Burts · ‎08-14-2018

Thanks for the additional information. Yes that syntax should work (some people like to use the optional parameter to specify the type of encryption and I wanted to be sure you were not doing that). When you change it, you just hit enter, is there any type of response or do you just get the prompt? If that is not working then something strange is going on. I would suggest as the next step to debug aaa authentication. Login using SSH, make sure that logging monitor is enabled (and perhaps logging buffered if we might want to look at output after the testing is complete), do terminal monitor, debug aaa authentication, leave the SSH session running so you see the output while you access the console, login, and attempt enable. HTH Rick

Richard Burts · ‎08-14-2018

Your drawing shows the head office with Sonicwall and Branch with ASA. It is not clear to me whether the ISP changing is the ISP for head office or ISP for Branch or both? Can you clarify? You mention that you have tried one of the changes. Is the second ISP already in place and connected? There are multiple places in the ASA config where the IPSEC peer address is used. It should be possible to edit the config and change the several places where the address is used. But you might want to consider using the approach of configuring a new policy with the new address. That way the old config can work as long as the original ISP is operational at the peer and the new config can work when the new ISP becomes active. HTH Rick

Richard Burts · ‎08-14-2018

Thanks for the clarification. If you enter the enable command, get the prompt, enter the enable password, and it fails then it sounds like you do not have the correct enable password. Would you post the exact syntax of what you type in when you are setting the enable secret to test1? HTH Rick

Richard Burts · ‎08-14-2018

Thanks for posting the configuration of the lines. If the config is long it may not be worth the effort to scrub it. We will see if we can come up with something without seeing the complete config. Am I correct in understanding that you are logging in using a username that is authenticated by your Radius server (and not the user configured on the device for local authentication)? And am I correct in understanding that when you access using SSH that you login successfully and are placed directly into privilege mode? And when you login on the console the authentication is successful (you use your Radius password) and you are placed into user mode? In user mode does the enable command work? When you enter the enable command do you get a prompt asking for the password? If you get a prompt, enter the password but do not get into privilege mode is it possible that you do not have the correct enable secret password? HTH Rick

Richard Burts · ‎08-14-2018

The encryption parameters used on one peer must match to the parameters used on the other peer. If your IPSEC does come up when using these parameters crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 crypto ipsec transform-set CSC-3DES esp-3des esp-md5-hmac then it suggests that this is what the peer is configured to use and that is why your VPN does not work when you change your side to the more secure set of parameters. HTH Rick

Richard Burts · ‎08-14-2018

Based on the little bit of config that you posted I would expect the enable password to get you into privilege mode - assuming that the enable password is configured. Perhaps if you post a more complete config (especially including all the line configuration) we might see something to explain the issue. HTH Rick

Richard Burts · ‎08-14-2018

If you have created the second DMZ and if you can access it from the LAN and the AnyConnect user can access it then it is working pretty well. There are a couple of things that might prevent devices on the DMZ from accessing the Internet. The most likely problem is that the devices in the DMZ are using private IP addressing and the ASA does not have any NAT configured for these devices. Another possible reason for no Internet access might be something in the access rules that are configured. Without seeing config details it is difficult for us to know what is the problem. HTH Rick

Richard Burts · ‎08-14-2018

I am a bit puzzled at the description of the problem in the original post. It says " If I put those routes in and point them to the next hop interface IP, this works fine. " So what are you putting into the static routes when they are not inserted into the routing table? Perhaps you can provide an example of the static configuration and also the output of show ip route so that we see what is known on the router? HTH Rick

Email	rburts@netcraftsmen.com
Date Registered	‎08-08-2003 08:54 AM
Date Last Visited	‎08-17-2018 12:04 AM
Total Messages Posted	21,241
Total Helpful Votes Received	15439

Re: CISCO ASA 5505 - SITE TO SITE VPN I...

Re: ISAKMP and IPSEC

Re: Recursive Route Not in the RIB

Re: CISCO ASA 5505 - SITE TO SITE VPN I...

Re: Routing decision IPSEC vs Static Ro...

Re: enable auth with radius for console

Re: enable auth with radius for console

Re: enable auth with radius for console

Re: CISCO ASA 5505 - SITE TO SITE VPN I...

Re: enable auth with radius for console

Re: enable auth with radius for console

Re: ISAKMP and IPSEC

Re: enable auth with radius for console

Re: ASA Configuration

Re: Recursive Route Not in the RIB