Webcast: DMVPN troubleshooting (Live Webcast Tuesday June 7th, 2016 at 10 am Pacific/ 1 pm Eastern) Dynamic Multipoint VPN (DMVPN) is a Cisco IOS/IOS-XE Software solution for building scalable IPsec Virtual Private Networks (VPNs). Cisco DMVPN uses a centralized architecture to provide easier implementation and management for deployments that require granular access controls for diverse user communities, including mobile workers, telecommuters, and extranet users. Cisco DMVPN allows branch locations to communicate directly with each other over the public or private WAN or Internet but doesn't require a permanent VPN connection between sites. It enables zero-touch deployment of IPsec VPNs and improves network performance by reducing latency and jitter, while optimizing head office bandwidth utilization.   This session provides some insight into the base components involved in DMVPN and the different phases of deployment (hub-spoke model v. dynamic full mesh). It will focus on the layered troubleshooting approach required when working on DMVPN-related network issues and how it can be used to troubleshoot commonly seen problems in the field. Agenda: DMVPN Phase 1/2/3 Overview Deep Dive on Phase 3 Layered Troubleshooting Approach for DMVPN Live Demonstration of Phase 3 Operation Live Troubleshooting of Common DMVPN Issues Best Practices Featured Speakers Frank DeNofa has been a Customer Support Engineer in the Technical Assistance Center VPN team in RTP since 2013. He has expertise in VPN technologies with a focus on site-to-site VPN solutions such as DMVPN, GETVPN, and FlexVPN. Frank holds a Bachelor's Degree in Applied Networking and Systems Administration with a focus on routing and security from Rochester Institute of Technology in Rochester, NY. His non-networking interests include hockey, CrossFit, and cooking. Hamzah Kardame has been a Customer Support Engineer in the Technical Assistance Center Security team at Cisco since 2010. His area of expertise lies in the VPN space on both IOS/IOS-XE based platforms as well as on ASAs, focusing on VPN solutions such as DMVPN, GETVPN and FlexVPN, in addition to Public Key Infrastructure (PKI). He holds a CCIE certification in Security (#35596). Hamzah graduated with a Bachelor’s Degree in Electronics and Communication from PESIT at Bangalore, India. His other areas of interest include reading, soccer and traveling. Do you have more questions? Our experts are available for the next two weeks to answer your questions. Join the Ask the Expert discussion at  https://supportforums.cisco.com/expert-corner/events ">https://supportforums.cisco.com/expert-corner/events. We look forward to your participation. This event is open to all, including partners. Please Share this event in your social channels. You have a chance to win a prize by filling out the survey after attending the live event. Have a technical question? Get answers before opening a TAC case by visiting the Cisco Support Community.        ... View more

      Introduction This document provides a sample configuration for setting up the ASA (running 8.3 or later) to hairpin/u-turn traffic off its interface.     Requirements Ensure that you meet these requirements before you attempt this configuration: ASA is running 8.3 code or later.   Network Diagram       Configurations   Consider the following scenario: 1. Client 192.168.1.10 is trying to access web-server 192.168.2.10.   2. The default-gateway for 192.168.1.10 is the ASA's inside interface ip i.e. 192.168.1.1   3. Thus, the SYN is sent from the host to the ASA's inside interface.   4. On the ASA, an access-list check is done first, followed by route-lookup which determines the egress interface  to be the 'inside' interface itself.   5. Since, the SYN packet is going to ingress and egress the ASA from the same interface and hence, traverse through the same security-level, we need the ASA to permit this exclusively using:      ASA(config)#same-security permit intra-interface   6. The SYN will then reach the webserver after the router does the appropriate routing.   7. When the SYN-ACK is returned from the webserver, it will get back to the router. Here, if the router is already aware of the 192.168.1.0 network (as shown in the topology above), then it will directly forward the packet back to the client (out its FastEthernet 0 interface).   8. The client upon receiving this SYN-ACK packet, will drop it. The reason for this is due to "TCP sequence number randomization" carried out by default on the ASA i.e. when the ASA receives a SYN packet on any interface, it randomizes the sequence number of the packet before sending the packet out. It carries this out as a security policy and keeps track of the the changes it has made using its state table. In our case, when the client initiated the connection, let's say the seq. number of the packet was 12345. When this SYN packets got hairpinned/u-turned off the inside interface, the seq. number would have gotten randomized to another number, say, 56789. Thus, when the webserver wants to acknowledge this packet, it generates a SYN-ACK with respect to 56789 (and not 12345). This SYN-ACK is dropped by the client (since it was expecting a SYN-ACK for the packet with seq. number 12345).   9. To avoid packet-drops due to the asymmetric nature of routing that's occuring internally, we need the ASA to bypass stateful inspection for this particular traffic. For this, we need to configure the following:   ASA(config)#access-list tcp_bypass extended permit tcp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0    !--- Configure the access list to specify the TCP traffic    !--- that needs to by-pass inspection to improve the performance.      !--- Configure the class map and specify the match parameter for the    !--- class map to match the interesting traffic.      ASA(config)#class-map tcp_bypass    ASA(config-cmap)#description "TCP traffic that bypasses stateful firewall"    ASA(config-cmap)#match access-list tcp_bypass        !--- Configure the policy map and specify the class map    !--- inside this policy map for the class map.      ASA(config-cmap)#policy-map tcp_bypass_policy    ASA(config-pmap)#class tcp_bypass      !--- Use the set connection advanced-options tcp-state-bypass    !--- command in order to enable TCP state bypass feature.      ASA(config-pmap-c)#set connection advanced-options tcp-state-bypass      !--- Use the service-policy policymap_name [ global | interface intf ]    !--- command in global configuration mode in order to activate a policy map    !--- globally on all interfaces or on a targeted interface.      ASA(config-pmap-c)#service-policy tcp_bypass_policy inside   Note: Once the above is enabled, the ASA does not keep track of the state of the connection anymore, so, features such as TCP sequence randomization, TCP intercept, etc. will be disabled.   10. Finally, as far as NAT is concerned, ASA's running 8.3 and higher have nat-control turned off and thus, no specific NATs are required to get the hairpinning/u-turning to work. There is one exception to this though: If NAT rules such as the one below are present, then we would require some specific NAT'ing to be done on the ASA to allow the u-turning to occur.   object network obj-all-network subnet 0.0.0.0 0.0.0.0.0 nat (inside,any) dynamic <ip address>   I n the NAT statement above, the 'any' keyword will cause an issue due to which the u-turned traffic will fail the reverse-path check (RPF-Drop). To avoid this, one can issue a NAT statement such as:   nat (inside,inside) 1 source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-192.168.2.0 obj-192.168.2.0      where obj-192.168.1.0 and obj-192.168.2.0 are the network objects that contain the subnets 192.168.1.0/24 and 192.168.2.0/24 respectively.   This NAT rule is more specific and instructs the ASA as follows:   When a packet sourced from 192.168.1.0/24 and destined to 192.168.2.0/24 reaches the inside interface of the ASA, then statically NAT the source ip of the packet from 192.168.1.X to 192.168.1.X and statically NAT the destination ip of the packet from 192.168.2.X to 192.168.2.X. This rule can be used for the return traffic from 192.168.2.X to 192.168.1.X as well i.e. it is a bi-directional NAT rule.   11. With the above configurations in place, the ASA will permit traffic to be hairpinned/u-turned off its interface.   Additional Comments 1. Note that, as the name suggests, TCP State Bypass can be used to resolve such asymmetric routing issues only for TCP traffic and nothing else. 2. For example, pings from 192.168.1.x to 192.168.2.x may work; but pings initiated from 192.168.2.x to 192.168.1.x will not. This is because the ASA is usually configured to inspect protocols such as ICMP (refer: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008085283d.shtml ). 3. Thus, when initiating pings from 192.168.2.x to 192.168.1.x, the echo request reaches 1.x directly through the router whereas the echo reply from 1.x is sent to the ASA. Since the ASA is unaware of this ICMP session, it simply drops the echo reply packet. 4. The only workaround to allow pings to work from 192.168.2.x to 192.168.1.x is to disable ICMP inspection for that traffic on the ASA. 5. The same holds true for other protocols that are being inspected by the ASA.       Related Information 1. TCP State Bypass Configuration Guide: http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080b2d922.shtml   2. Information on Default Global Inspection on the ASA: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008085283d.shtml   3. Information on 8.3 NAT and pre-8.3 to 8.3 NAT configuration examples: http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/nat_overview.html https://supportforums.cisco.com/docs/DOC-9129       ... View more