Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

We understand that a lot of our customers and users have issues troubleshooting Site-to-Site VPN tunnels.
Here’s a small reference sheet that you could use while trying to sort such issues.

Introduction#

Firstly, the two most important commands when troubleshooting any vpn tunnel on a cisco device:

1. “show crypto isakmp sa” or “sh cry isa sa”

2. “show crypto ipsec sa” or “sh cry ips sa”

The first command will show the state of the tunnel. For an tunnel to be perfectly up and passing traffic like it is supposed to, you should see a status “MM_ACTIVE” on an ASA and “QM_IDLE” on a router. The second command will show you the tunnel stats in detail showing clearly the number of packets encapsulated and decapsulated through the vpn tunnel. These numbers should be more or less equal.

(Henceforth throughout the document, I shall be referring to the above mentioned commands as command 1 and command 2 respectively)

Tips to Remember

1. Upon issuing command 1, if you see the status as “MM_NO_STATE” on an ASA or “MM_WAIT_MSG2” on a router, then you would want to –

a. Check the ISAKMP policies that are configured on both the ends of the tunnel to check if the parameters are matched. By ISAKMP policies, I am referring to the parameters that have been configured after issuing the command “crypto isakmp policy <policy-number>” within the sub-prompt. Out of the multiple policies that may have been configured at both ends, at least one policy must match completely with the peer policy, else you would see this status message. Make sure that you match the parameter “group” as well else you will still see this status message.

b. Check if you are able to ping the peer IP address. Also check with your ISP providers on both ends to see if they have blocked UDP port 500 at their end. Blocking of port 500 can also result in this status message.

2. Upon issuing command 1, if you see the status as “MM_WAIT_MSG4” on a router, you would want to check the value of the “group” parameter set under the “crypto isakmp policy <policy-number>” for the policy that is supposed to match on both ends of the tunnel. This parameter has to match on both ends, just like all the other parameters.

3. Upon issuing command 1, if you see the status as “MM_KEY_EXCH” on an ASA or “MM_WAIT_MSG6” on a router, then you would want to ensure that the pre-shared-key you are using on both ends is exactly matched, character by character.

4. Upon issuing command 1, if you see the status “MM_ACTIVE” on an ASA or “QM_IDLE” on a router, issue command 2. If for some reason the traffic is not passing through the vpn tunnel successfully, then you might want to check the IPSEC transform set that has been set under the crypto map for both ends. Here too, the parameters must match at all times.

5. Upon checking to see if traffic is passing successfully, if you find that traffic is not successfully passing through the tunnel, you would also need to check if the traffic for that vpn tunnel has been either exempted from the NAT process by using the “nat (interface-name) 0” command or if the crypto acl has the natted IP of the subnet and not the real IP.

Must DO’s

1. Always enable ISAKMP on the interface that you want to terminate the VPN tunnel on. You can do this by issuing the command “crypto isakmp enable <interface-name>”.

2. Always apply the crypto map to the same interface that has the isakmp enabled. The command “crypto map <map-name> interface <interface-name>” should do the trick!

3. Ensure that there is only one crypto map applied to a particular interface.

4. Ensure that the crypto acl’s or access-list that are used to match traffic to go through the vpn tunnel do not overlap with other access-lists applied to tunnels going to other peers.
This can cause a major traffic passage issue although the status of the tunnel will show as “MM_ACTIVE” or “QM_IDLE”. Hope this helps!

Policy based routing

This is more like a filter for networks. It has 3 basic steps

ACL to define interesting traffic
Routemap to refer to the ACL (If/Then statement)
Apply route Map to ingress interface

Normal traffic outward flow
R1 – R3 – R5 – R4 – R7
Return path
R7 – R4 – R5 – R3 – R1

Apply Route-Map on R4 to change the return Path
Return path

R7 – R4 – R3 – R1

R4# show access list

#access-list 100 permit ip host 7.7.7.7 any
#route-map PBR
#match IP address 100 // looking for Access list that matches acl 100. The “Match” is the “IF” portion
#set ip next-hop 10.34.0.3 //The “Set” is the “Then” portion
exit

//Please Note: If you do not specify a match statement, and only specify Set, it will match every other route to the PBR. If we dont set an alternative match statement, it will use the dedault route table.
//to check the route path

R7# traceroute 1.1.1.1
R7# traceroute 1.1.1.1 source 7.7.7.7

//to change the path, go to R4 ingress interface to apply the route map

R4# int se1/1.478
#ip policy route-map PBR

Verify the PBR you just applied

R4# sh ip policy
R4# Debug ip policy

// Lets go to R7
R7# traceroute 1.1.1.1
//Traffic flows normally as it is not coming from 7.7.7.7 but from 10.7.7.7
R7# traceroute 1.1.1.1 source 7.7.7.7
//Now you see the traffic path changes acording to PBR

Reference …From Keith Barker’s CBT.

What goes into a blog post? Helpful, industry-specific content that: 1) gives readers a useful takeaway, and 2) shows you’re an industry expert.

Use your company’s blog posts to opine on current industry topics, humanize your company, and show how your products and services can help people.

08/02/2019

TOP VULNERABILITY THIS WEEK: NetWire variants used in fake business spam campaign