Sunday 28 April 2013

ASA SSL - part II - Anyconnect


In order to configure the ASA for VPN access using the AnyConnect client, complete these steps:
  1. Configure a Self-Issued Certificate.
  2. Upload and Identify the SSL VPN Client Image.
  3. Enable Anyconnect Access.
  4. Create a new Group Policy.
  5. Configure Access List Bypass for VPN Connections.
  6. Create a Connection Profile and Tunnel Group for the AnyConnect Client Connections.
  7. Add Users to the Local Database.
Scenario:
  • Configure a Self-Issued Certificate
By default, the security appliance has a self-signed certificate that is regenerated every time the device is rebooted. You can purchase your own certificate from vendors, such as Verisign or EnTrust, or you can configure the ASA to issue an identity certificate to itself. This certificate remains the same even when the device is rebooted.
  • Upload and Identify the SSL VPN Client Image
ciscoasa# copy tftp://172.20.1.6/anyconnect-win-3.0.11042-k9.pkg flash:
Address or name of remote host [172.20.1.6]?
Source filename [anyconnect-win-3.0.11042-k9.pkg]?
Destination filename [anyconnect-win-3.0.11042-k9.pkg]? 
webvpn
 anyconnect image disk0:/anyconnect-win-3.0.11042-k9.pkg 1
  • Enable Anyconnect Access.
webvpn
 port 8443
 enable outside
 anyconnect enable
  • Create a new Group Policy.
access-list SPLIT_TUNNEL standard permit 10.1.1.0 255.255.255.0
access-list PERMIT_ANY extended permit ip any any 

 group-policy SSLVPN internal
group-policy SSLVPN attributes
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT_TUNNEL
  • Configure Access List Bypass for VPN Connections.
sysopt connection permit-vpn
  •  Create a Connection Profile and Tunnel Group for the AnyConnect Client Connections.
 ip local pool SVC_POOL 20.0.0.1-20.0.0.254

tunnel-group SSLVPN type remote-access
tunnel-group SSLVPN general-attributes
 address-pool SVC_POOL
 default-group-policy SSLVPN
 webvpn
tunnel-group-list enable
  •  Add Users to the Local Database.
username ANYCONNECT password CISCO
Verification: 
  • https://172.20.1.10:8443

  • anyconnect will be downloaded and installed automatically.
  •  SSLVPN connection will be automatically established after that

  • ASA outputs:
ciscoasa# show webvpn anyconnect
1. disk0:/anyconnect-win-3.0.11042-k9.pkg 1 dyn-regex=/Windows NT/
  CISCO STC win2k+
  3,0,11042
  Hostscan Version 3.0.11042
  Mon 12/10/2012  5:18:28.27
1 AnyConnect Client(s) installed

ciscoasa# show vpn-sessiondb anyconnect
Session Type: AnyConnect
Username     : ANYCONNECT                 Index        : 15
Assigned IP  : 20.0.0.1               Public IP    : 172.20.1.6
Protocol     : Clientless SSL-Tunnel
Encryption   : RC4                    Hashing      : SHA1
Bytes Tx     : 47604                  Bytes Rx     : 11501
Group Policy : SSLVPN                 Tunnel Group : SSLVPN
Login Time   : 18:45:49 UTC Sat Apr 27 2013
Duration     : 0h:06m:03s
Inactivity   : 0h:00m:00s
NAC Result   : Unknown
VLAN Mapping : N/A                    VLAN         : none

IOS SSL - part II - Anyconnect

In a typical clientless remote access scenario, remote users establish an SSL tunnel to move data to and from the internal networks at the application layer (for example, web and e-mail). In tunnel mode, remote users use an SSL tunnel to move data at the network (IP) layer. Therefore, tunnel mode supports most IP-based applications. Tunnel mode supports many popular corporate applications (for example, Microsoft Outlook, Microsoft Exchange, Lotus Notes E-mail, and Telnet).

The tunnel connection is determined by the group policy configuration. The Cisco AnyConnect VPN Client is downloaded and installed on the remote user PC, and the tunnel connection is established when the remote user logs into the SSL VPN gateway.

By default, the Cisco AnyConnect VPN Client is removed from the client PC after the connection is closed. However, you have the option to keep the Cisco AnyConnect VPN Client installed on the client PC.


AnyConnect VPN is supported in both IOS and ASA platforms. The configuration syntax is pretty much different between the two platforms.

Scenario:

webvpn install svc disk0:/anyconnect-win-3.0.11042-k9.pkg
ip http secure-serve
ip http server
  •  SSL VPN gateway

webvpn gateway SSLVPN_GATEWAY
 ip address 172.20.1.2 port 443
 ssl encryption rc4-md5
 ssl trustpoint TP-self-signed-local
 logging enable
 inservice
  • SSL VPN context

webvpn context SSLVPN
 title "SSL VPN TEST"
 ssl authenticate verify all
 policy group ANYCONNECT_POLICY
   functions svc-required
   svc address-pool "SVC_POOL"
   svc keep-client-installed
   svc split include 10.1.1.0 255.255.255.0
 default-group-policy ANYCONNECT_POLICY
 aaa authentication list SSLVPN
 aaa authentication domain @SSLVPN
 gateway SSLVPN_GATEWAY domain SSLVPN
 logging enable
 inservice
aaa authentication login SSLVPN local
username ANYCONNECT@SSLVPN password 0 CISCO

ASA SSL - part I - Clientless

Clientless SSL VPN (WebVPN) allows for limited but valuable secure access to the corporate network from any location.
A remote client needs only an SSL-enabled web browser to access http- or https-enabled web servers on the corporate LAN.
Clientless SSL VPN and ASDM must not be enabled on the same ASA interface. It is possible for the two technologies to coexist on the same interface if changes are made to the port numbers. It is highly recommended that ASDM is enabled on the inside interface, so WebVPN can be enabled on the outside interface.

Clientless SSL VPN provides secure and easy access to a broad range of web resources and web-enabled applications from almost any computer on the Internet. They include:

•Internal websites
•Web-enabled applications
•NT/Active Directory file shares
•E-mail proxies, including POP3S, IMAP4S, and SMTPS
•MS Outlook Web Access
•Application Access (that is, smart tunnel or port forwarding access to other TCP-based applications)

The user connects to the ASA firewall using a secure HTTP connection and logs in using a name and
a password provided. The firewall opens a special (customizable) portal page to the user, which mulates a browser, with URL address bar. The user may enter URLs for company resources, and the firewall resolves them using a configured DNS server and downloads the requested pages. Optionally, the firewall may apply an URL filter to restrict access to certain corporate resources, or even disallow URL entry at all, providing the user with a list of static bookmarks.

Using WebVPN you can download a special Java applet that implements port-forwarding. 
A browser plug-in is a separate program that a web browser invokes to perform a dedicated function, such as connect a client to a server within the browser window. The adaptive security appliance lets you import plug-ins for download to remote browsers in clientless SSL VPN sessions.

Cisco redistributes the following open-source, Java-based components to be accessed as plug-ins for web browsers in clientless SSL VPN sessions:
  • Citrix Client (ica)
  • Terminal Servers (rdp)
  • Terminal Servers Vista (rdp2)
  • SSH
  • Telnet
  • VNC
Scenario:

Enable WebVPN 
webvpn
 port 8443
 enable outside
 tunnel-group-list enable

Define a DNS server group
dns domain-lookup outside
DNS server-group DNS
    name-server 8.8.8.8

Define a group policy for WebVPN connection
 access-list WEBACCESS webtype permit url http://*.com

group-policy WEBVPN internal
group-policy WEBVPN attributes
 vpn-tunnel-protocol ssl-clientless
 webvpn
  filter value WEBACCESS
  url-entry enable

Define a connection-profile (tunnel-group) for WebVPN users
tunnel-group WEBVPN type remote-access
tunnel-group WEBVPN general-attributes
 default-group-policy WEBVPN
tunnel-group WEBVPN webvpn-attributes
 group-alias WEBVPN enable
 dns-group DNS

username ClientlessUser password CISCO
username ClientlessUser attributes
 group-lock value WEBVPN

Applications plug-in
ciscoasa#import webvpn plug-in protocol ssh,telnet tftp://172.20.1.6/ssh-plugin.jar
ciscoasa#import webvpn plug-in protocol vnc tftp://172.20.1.6/vnc-plugin.jar

Verification:
  • https://172.20.1.10:8443



  • ASA outputs:
ciscoasa# show vpn-sessiondb webvpn
Session Type: WebVPN
Username     : WEBVPN                 Index        : 6
Public IP    : 172.20.1.6
Protocol     : Clientless
Encryption   : RC4                    Hashing      : SHA1
Bytes Tx     : 2576                   Bytes Rx     : 19408
Group Policy : WEBVPN                 Tunnel Group : WEBVPN
Login Time   : 14:40:29 UTC Sun Apr 28 2013
Duration     : 0h:02m:39s
Inactivity   : 0h:00m:00s
NAC Result   : Unknown
VLAN Mapping : N/A                    VLAN         : none

Saturday 27 April 2013

IOS SSL - part I - Clientless

Cisco IOS SSL VPN provides SSL VPN remote-access connectivity for any internet web browser that supports SSL encryption. The SSL VPN feature extends secure enterprise network access to any authorized user by providing remote-access connectivity to corporate resources from any location with internet service.

SSL VPN delivers the following three modes of SSL VPN access:

Clientless--Clientless mode provides secure access to private web resources and web content. This mode is useful for accessing content found in web browsers, databases, and online tools that employ a web interface.
Thin-client (port-forwarding Java applet)--Thin-client mode extends the capability of the cryptographic functions of the web browser to enable remote access to TCP-based applications such as Post Office Protocol version 3 (POP3), Simple Mail Transfer Protocol (SMTP), Internet Message Access Protocol (IMAP), Telnet, and SSH.
Full tunnel client--Full tunnel client mode offers extensive application support through its dynamically downloaded Cisco AnyConnect VPN Client (next-generation SSL VPN Client) for SSL VPN. Full tunnel client mode delivers a lightweight, centrally configured, and easy-to-support SSL VPN tunneling client that provides network layer access to any application virtually.

Before you can configure the SSL VPN Smart Tunnels Support feature, the virtual gateway must be configured and enabled. This gateway configuration specifies the IP address, port number, and trustpoint for the SSL VPN. Enabling the virtual gateway enables the SSL VPN service.

An SSL VPN virtual context must be configured to associate the virtual SSL VPN gateway with the configured features.
  • WebVPN Gateway 
The WebVPN Gateway is used to terminate the SSL connection from the user. The basic configuration requires an IP address on the same subnet as one of the public network interfaces; this could be the same address used on the public network interface, or another address in the same subnet. Alternately, you can define a loopback interface, and use an address in that subnet, just as long as the address is reachable on the public network.
The other mandatory component is the crypto PKI trustpoint used. This can be a Certificate Authority (CA) signed certificate, or a self-signed certificate. 
Optionally, you may provide a hostname that is associated with the gateway, since there may be multiple WebVPN gateways. It is also a common practice to register the addresses and hostnames with a DNS authority.
  • WebVPN context 
The WebVPN context is where the SSL VPN is terminated, and the user's VPN session is established. The context also contains all of the policies that can be applied to a user, including authentication, authorization, and accounting (AAA), virtual routing and forwarding instances (VRFs), and group policies. This is where the user authentication takes place, and group policies are applied to the user session. Furthermore, the context can define the way the SSL VPN Web portal will appear to the user by specifying the colors and the images. The context is basically a container for user sessions.
The WebVPN context uses a WebVPN gateway for the SSL session termination endpoint IP address. Multiple contexts can use one WebVPN gateway by using the domain keyword, and specifying a label.


Scenario:
  •  SSL VPN gateway
webvpn gateway SSL_GW
 ip address 172.20.1.2 port 443
 ssl trustpoint TP-self-signed-4294967295
 logging enable
 inservice
where TP-self-signed-4294967295 is automatically generated by the IOS router after  webvpn gateway command
crypto pki trustpoint TP-self-signed-4294967295
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-4294967295
 revocation-check none
 rsakeypair TP-self-signed-4294967295
crypto pki certificate chain TP-self-signed-4294967295
 certificate self-signed 01
  • SSL VPN context
webvpn context WEBVPN
 title "clientless web vpn example"
 title-color blue
 ssl authenticate verify all
 !
 url-list "URLs"
   url-text "Google" url-value "http://www.google.com"
 !
 time-range "EVERYDAY"
   periodic weekdays 0:00 to 20:00
 !
 acl "WebAccess"
   permit url "http://*.com" syslog
 !
 !
 policy group SSL_POLICY
   url-list "URLs"
   acl "WebAccess"
   banner "test banner"
 default-group-policy SSL_POLICY
 aaa authentication list WEBVPN
 gateway SSL_GW
 inservice

Verification:
 VPNConcentrator# show webvpn gateway SSL_GW
Admin Status: up
Operation Status: up
Error and Event Logging: Enabled
IP: 172.20.1.2, port: 443
SSL Trustpoint: TP-self-signed-4294967295
FVRF Name not configured

VPNConcentrator# show webvpn context WEBVPN
Admin Status: up
Operation Status: up
Error and Event Logging: Disabled
CSD Status: Disabled
Certificate authentication type: All attributes (like CRL) are verified
AAA Authentication List: WEBVPN
AAA Authentication Domain not configured
Default Group Policy: SSL_POLICY
Associated WebVPN Gateway: SSL_GW
Domain Name and Virtual Host not configured
Maximum Users Allowed: 1000 (default)
NAT Address not configured
VRF Name not configured

VPNConcentrator#show webvpn policy group SSL_POLICY context all
WEBVPN: group policy = SSL_POLICY ; context = WEBVPN
      banner = "test banner"
      url list name = "MYURL"
      idle timeout = 2100 sec
      session timeout = Disabled
      citrix disabled
      dpd client timeout = 300 sec
      dpd gateway timeout = 300 sec
      keep sslvpn client installed = disabled
      rekey interval = 3600 sec
      rekey method =
      lease duration = 43200 sec

VPNConcentrator#show webvpn session context all
WebVPN context name: WEBVPN
Client_Login_Name  Client_IP_Address  No_of_Connections  Created  Last_Used
test               172.20.1.6                 1         00:40:20  00:33:35
test               172.20.1.6                 1         00:14:43  00:00:38
test               10.1.1.2                   1         00:08:50  00:04:20  

Friday 26 April 2013

ASA IPsec ezVPN server


Scenario:


  • IKE config
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption 3des
 hash md5
 group 2
 lifetime 86400
  • Tunnel-Group and Tunnel Group Policies
tunnel-group ezVPN type remote-access
tunnel-group ezVPN general-attributes
 default-group-policy ezVPN
tunnel-group ezVPN ipsec-attributes
 ikev1 pre-shared-key TEST

 group-policy ezVPN internal
group-policy ezVPN attributes
 vpn-tunnel-protocol ikev1
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT_TUNNEL
 address-pools value ezVPN
where
  • SPLIT_TUNNEL is:
access-list SPLIT_TUNNEL standard permit 10.1.1.0 255.255.255.0 
  • address-pool ezVPN is:
ip local pool EZVPN 20.0.0.1-20.0.0.254


  • IPsec config

crypto ipsec ikev1 transform-set 3DES esp-3des esp-md5-hmac
crypto dynamic-map DYNAMIC 10 set ikev1 transform-set 3DES
crypto dynamic-map DYNAMIC 10 set reverse-route
crypto map VPN 100 ipsec-isakmp dynamic DYNAMIC
crypto map VPN interface outside
  • Authentication config
username VPN_USER password  CISCO
username VPN_USER attributes
 group-lock value ezVPN
Verification:

ciscoasa# show crypto ikev1 sa detail
IKEv1 SAs:
   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1   IKE Peer: 172.20.1.6
    Type    : user            Role    : responder
    Rekey   : no              State   : AM_ACTIVE
    Encrypt : 3des            Hash    : MD5      
    Auth    : preshared       Lifetime: 86400
    Lifetime Remaining: 85154

ciscoasa# show crypto ipsec sa detail
interface: outside
    Crypto map tag: DYNAMIC, seq num: 10, local addr: 172.20.1.2
      local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      remote ident (addr/mask/prot/port): (20.0.0.1/255.255.255.255/0/0)
      current_peer: 172.20.1.6, username: CISCO
      dynamic allocated peer ip: 20.0.0.1
      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 12, #pkts decrypt: 12, #pkts verify: 12
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #pkts no sa (send): 0, #pkts invalid sa (rcv): 0
      #pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
      #pkts invalid prot (rcv): 0, #pkts verify failed: 0
      #pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0
      #pkts invalid pad (rcv): 0,
      #pkts invalid ip version (rcv): 0,
      #pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
      #pkts replay failed (rcv): 0
      #pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
      #pkts internal err (send): 0, #pkts internal err (rcv): 0
      local crypto endpt.: 172.20.1.2/0, remote crypto endpt.: 172.20.1.6/0
      path mtu 1500, ipsec overhead 58, media mtu 1500
      current outbound spi: 308A930C
      current inbound spi : 776D8DD3

ciscoasa# show ip local pool EZVPN
Begin           End             Mask            Free     Held     In use
20.0.0.1        20.0.0.254      0.0.0.0           253        0        1

Wednesday 24 April 2013

IOS IPsec ezVPN server - part II - VTI


Virtual Tunnel Interfaces (VTIs) allow for significantly simpler configuration of IPSec VPNs.
For Remote Access VPN implementation, IOS introduces special type of virtual tunnel interfaces, configured using the command interface virtual-template type tunnel.
 It is recommended to use ISAKMP profile with Easy VPN Server configurations.

The ISAKMP profile is an enhancement to Internet Security Association and Key Management Protocol (ISAKMP) configurations. It enables modularity of ISAKMP configuration for phase 1 negotiations. This modularity allows mapping different ISAKMP parameters to different IP Security (IPSec) tunnels, and mapping different IPSec tunnels to different VPN forwarding and routing (VRF) instances. 

An ISAKMP profile is a repository for IKE Phase 1 and IKE Phase 1.5 configuration for a set of peers.
n ISAKMP profile applies parameters to an incoming IPSec connection identified uniquely through its concept of match identity criteria.

ISAKMP Profile Parameters Configuration
There can be zero or more ISAKMP profiles on the Cisco IOS router. Following is a list of parameters that can be configured per profile:
1. self-identity {address | fqdn | user-fqdn user-fqdn}: Specifies the identity that the local IKE should use to identify itself to the remote peer.
• If not defined, IKE uses the global configured value.
• address-Uses the IP address of the egress interface.
• fqdn-Uses the FQDN of the router.
• user-fqdn-Uses the specified value.
2. keyring keyring-name: Specifies the keyring to use for Phase 1 authentication.
• If the keyring is not specified, the global key definitions are used.
3. ca trust-point {trustpoint-name}: Specifies a trustpoint to validate a Rivest, Shamir, and Adelman (RSA) certificate. If no trustpoint is specified in the ISAKMP profile, all the trustpoints that are configured on the Cisco IOS router are used to validate the certificate.
4. client configuration address {initiate | respond}: This command is used with Easy VPN Server; it specifies whether to initiate the mode configuration exchange or respond to mode configuration requests.
5. client authentication list list-name: AAA to use for authenticating the remote client during the extended authentication (XAUTH) exchange.
6. isamkp authorization list list-name: Network authorization server for receiving the Phase 1 preshared key and other attribute-value (AV) pairs.
7. initiate mode aggressive: Initiates aggressive mode exchange. If not specified, IKE always initiates Main Mode exchange.
8. keepalive seconds retry retry-seconds: Allows the gateway to send dead peer detection (DPD) messages to the peer. If not defined, the gateway uses the global configured value.


Scenario:

VPNConcentrator config

ISAKMP profile
crypto isakmp profile EZVPN
   match identity group ezVPN
   client authentication list ezVPN
   isakmp authorization list ezVPN
   client configuration address respond
   client configuration group ezVPN
   virtual-template 1

where
  • authentication list ezVPN is:
 aaa authentication login ezVPN local
  • authorization list ezVPN is:
aaa authorization network ezVPN local 
  •  configuration group ezVPN is:
crypto isakmp client configuration group ezVPN
 key cisco123
 pool ezVPN
 acl SPLIT_T
  • vitrual-template 1:
interface virtual-template 1 type tunnel
ip unnumbered Loopback0
tunnel protection ipsec profile EZVPN
tunnel mode ipsec ipv4

 IPSEC Profile
crypto ipsec profile EZVPN
 set transform-set 3DES
 set reverse-route tag 1

where
  • transform set is:
crypto ipsec transform-set 3DES esp-3des esp-md5-hmac 


Verification:

VPNConcentrator#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA
C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.
1002  172.20.1.2      172.20.1.6               ACTIVE 3des md5       2  23:59:07 CX
       Engine-id:Conn-id =  SW:2

VPNConcentrator#show crypto ipsec sa detail
interface: Virtual-Access2
    Crypto map tag: Virtual-Access2-head-0, local addr 172.20.1.2
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.101/255.255.255.255/0/0)
   current_peer 172.20.1.6 port 58704
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3
    #pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0
     local crypto endpt.: 172.20.1.2, remote crypto endpt.: 172.20.1.6
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
     current outbound spi: 0x830FCBA0(2198850464)

VPNConcentrator#show interfaces virtual-access 2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Interface is unnumbered. Using address of FastEthernet1/0 (172.20.1.2)
  MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL
  Tunnel vaccess, cloned from Virtual-Template1
  Vaccess status 0x0, loopback not set
  Keepalive not set
  Tunnel source 172.20.1.2, destination 172.20.1.6
  Tunnel protocol/transport IPSEC/IP
  Tunnel TTL 255
  Fast tunneling enabled
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "EZVPN")
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 00:01:54
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     3 packets input, 180 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     3 packets output, 180 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

VPNConcentrator#sh ip local pool
 Pool                     Begin           End             Free  In use   Blocked
 ezVPN                    192.168.1.100   192.168.1.200    100       1       0

Tuesday 16 April 2013

IOS IPsec ezVPN server - part I

Easy VPN (ezVPN) is an Client-Server VPN technology based on IPsec. Originally, IPsec was a peer-to-peer technology, where configurations are basically symmetrical on both ends of an IPsec tunnel. The idea of ezVPN is to make client configuration as simple as possible, while putting additional configuration on the server. In order to avoid excessive configuration on client side, additional ISAKMP SA Phase has been introduced – Phase 1.5. The purpose of this phase is to push configuration information to the client and perform additional name-based authentication (Xauth – extended authentication).
  • Phase 1: Client contacts server, sends it’s identifier (group name) either using ISAKMP Aggressive Mode, or certificate exchange
  • Phase 1.5: Based on group configuration, server may initiate additional authentication process (called Xauth) to verify user identity. After successful authentication, client sends a Configuration Request. With group and authenticated username on hand, server may then query local database or remote AAA server (e.g. RADIUS) for configuration information, which usually includes client VPN IP address, Split-Tunnel ACL, DNS/WINS servers etc.
  • Phase 2: Client obtains it’s new IP address and other additional information and then tries to establish IPsec SA based on Split-Tunnel ACL (which specifies traffic to be encrypted) and new VPN IP address. Essentially, split-tunnel ACL is used to create Proxy-Identifiers for Phase 2. As connection is established, server may create a static route, corresponding to the client VPN IP address using process know as Reverse Route Injection (RRI).
Scenario:
  • VPNConcentrator config
    • ezVPN xAuth
aaa new-model
aaa authentication login ezVPN local
aaa authorization network ezVPN local
username user1 password 0 cisco

 crypto map VPN client authentication list ezVPN
crypto map VPN isakmp authorization list ezVPN
    • ISAKMP policy
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
IOS routers use DH group 1 by default, and ezVPN client requires DH group 2 for 3DES and DH group 5 for AES-256.
    • Local address pool
ip local pool ezVPN 192.168.1.100 192.168.1.200
crypto isakmp client configuration address-pool local ezVPN
    • Split tunnel
ip access-list extended SPLIT_T
 permit ip 10.1.1.0 0.0.0.255 any
 permit ip 20.1.1.0 0.0.0.255 any
 The client will route traffic to the subnet permited by this ACL across the VPN tunnel and encrypt it.
    •  ISAKMP Group
crypto isakmp client configuration group ezVPN
 key cisco123
 pool ezVPN
 acl SPLIT_T
    • IPSEC config
crypto ipsec transform-set 3DES esp-3des esp-md5-hmac
crypto dynamic-map DYNAMIC 10
 set transform-set 3DES
 reverse-route

crypto map VPN client configuration address respond
crypto map VPN 10 ipsec-isakmp dynamic DYNAMIC 

interface FastEthernet1/0
 ip address 172.20.1.2 255.255.255.252
 crypto map VPN
If default routing is not in use, the router needs to learn about the next-hops to reach every new dynamically allocated IP address. This could be achieved using the procedure known as Reverse Route Injection (RRI). For every new IP address allocated via ISAKMP configuration mode the router will install a local static /32 route, pointing toward the next-hop to reach this particular VPN client.

Statement 
crypto map VPN client configuration address respond
instructs the router to respond to ISAKMP Mode Config messages (specifically, the IP address requests).
  • Client settup

Add new connection. Set IP address of the VPNConcentrator. The Group Authentication parameters must match the one configured on the VPNConcentrator:
crypto isakmp client configuration group ezVPN
 key cisco123
The credentials used for connection are the one defined by the aaa configuration.


Verification:

IP address allocated from VPNConcentrator poll

Static routes added for subnets specified by SPLIT_T ACL.

VPNConcentrator#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA
C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.
1008  172.20.1.2      172.20.1.6               ACTIVE 3des md5       2  23:54:38 CX
       Engine-id:Conn-id =  SW:8

VPNConcentrator#show crypto ipsec sa detail
interface: FastEthernet1/0
    Crypto map tag: VPN, local addr 172.20.1.2
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.101/255.255.255.255/0/0)
   current_peer 172.20.1.6 port 55487
     PERMIT, flags={}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0
     local crypto endpt.: 172.20.1.2, remote crypto endpt.: 172.20.1.6
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
     current outbound spi: 0xDE89E3E8(3733578728)

VPNConcentrator#show ip local pool
 Pool                     Begin           End             Free  In use   Blocked
 ezVPN                    192.168.1.100   192.168.1.200    100       1       0

Gateway of last resort is not set
     172.20.0.0/30 is subnetted, 2 subnets
C       172.20.1.0 is directly connected, FastEthernet1/0
S       172.20.1.4 [1/0] via 172.20.1.1
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, FastEthernet1/1
     192.168.1.0/32 is subnetted, 1 subnets
S       192.168.1.101 [1/0] via 172.20.1.6

JunOS: VRF configuration over MPLS

Scenario using static mapping for lsp


  • P configuration:


set protocols rsvp interface all
set protocols mpls label-switched-path TO_PE2 from 1.1.1.1
set protocols mpls label-switched-path TO_PE2 to 2.2.2.2
set protocols mpls label-switched-path TO_PE2 no-cspf
set protocols mpls label-switched-path TO_PE1 from 2.2.2.2
set protocols mpls label-switched-path TO_PE1 to 1.1.1.1
set protocols mpls label-switched-path TO_PE1 no-cspf
set protocols mpls interface all

set interfaces em0 unit 0 family inet address 172.20.1.6/30
set interfaces em0 unit 0 family mpls
set interfaces em1 unit 0 family inet address 172.20.1.10/30
set interfaces em1 unit 0 family mpls

set routing-options static route 1.1.1.1/32 next-hop 172.20.1.5
set routing-options static route 2.2.2.2/32 next-hop 172.20.1.9
  • PE1 configuration:
set interfaces em0 unit 0 family inet address 172.20.1.1/30
set interfaces em1 unit 0 family inet address 172.20.1.5/30
set interfaces em1 unit 0 family mpls
set interfaces lo0 unit 100 family inet address 1.1.1.1/32

set routing-options static route 2.2.2.2/32 next-hop 172.20.1.6
set routing-options router-id 1.1.1.1
set routing-options autonomous-system 1111

set protocols rsvp interface all
set protocols mpls label-switched-path TO_PE2 from 1.1.1.1
set protocols mpls label-switched-path TO_PE2 to 2.2.2.2
set protocols mpls label-switched-path TO_PE2 no-cspf
set protocols mpls interface all

set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL peer-as 1111
set protocols bgp group INTERNAL neighbor 2.2.2.2 local-address 1.1.1.1
set protocols bgp group INTERNAL neighbor 2.2.2.2 family inet-vpn unicast

set routing-instances VPNA instance-type vrf
set routing-instances VPNA interface em0.0
set routing-instances VPNA route-distinguisher 100:1
set routing-instances VPNA vrf-target target:100:1
set routing-instances VPNA vrf-table-label
set routing-instances VPNA protocols bgp group VPNA neighbor 172.20.1.2 peer-as 2222
  • PE2 configuration:
set interfaces em0 unit 0 family inet address 172.20.1.9/30
set interfaces em0 unit 0 family mpls
set interfaces em1 unit 0 family inet address 172.20.1.13/30
set interfaces lo0 unit 100 family inet address 2.2.2.2/32

set routing-options static route 1.1.1.1/32 next-hop 172.20.1.10
set routing-options router-id 2.2.2.2
set routing-options autonomous-system 1111

set protocols rsvp interface all
set protocols mpls label-switched-path TO_PE1 from 2.2.2.2
set protocols mpls label-switched-path TO_PE1 to 1.1.1.1
set protocols mpls label-switched-path TO_PE1 no-cspf
set protocols mpls interface all

set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL peer-as 1111
set protocols bgp group INTERNAL neighbor 1.1.1.1 local-address 2.2.2.2
set protocols bgp group INTERNAL neighbor 1.1.1.1 family inet-vpn unicast

set routing-instances VPNA instance-type vrf
set routing-instances VPNA interface em1.0
set routing-instances VPNA route-distinguisher 100:1
set routing-instances VPNA vrf-target target:100:1
set routing-instances VPNA vrf-table-label
set routing-instances VPNA protocols bgp group VPNA neighbor 172.20.1.14 peer-as 3333
  • CPE1 configuration:
set interfaces em0 unit 0 family inet address 172.20.1.2/30
set interfaces em1 unit 0 family inet address 10.11.12.13/24
set interfaces lo0 unit 100 family inet address 100.100.100.100/32

set routing-options router-id 172.20.1.2
set routing-options autonomous-system 2222

set policy-options policy-statement LOCAL_CONNECTED term loopback0 from instance VPNA
set policy-options policy-statement LOCAL_CONNECTED term loopback0 from protocol direct
set policy-options policy-statement LOCAL_CONNECTED term loopback0 then accept

set routing-instances VPNA instance-type virtual-router
set routing-instances VPNA interface em0.0
set routing-instances VPNA interface lo0.100
set routing-instances VPNA protocols bgp group VPNA type external
set routing-instances VPNA protocols bgp group VPNA export LOCAL_CONNECTED
set routing-instances VPNA protocols bgp group VPNA neighbor 172.20.1.1 peer-as 1111
  • CPE2 configuration:
set interfaces em0 unit 0 family inet address 172.16.48.178/24
set interfaces em0 unit 0 family inet address 172.20.1.14/30
set interfaces em1 unit 0 family inet address 10.11.12.13/24

set routing-options router-id 172.20.1.14
set routing-options autonomous-system 3333

set policy-options policy-statement LOCAL_CONNECTED term loopback0 from instance VPNA
set policy-options policy-statement LOCAL_CONNECTED term loopback0 from protocol direct
set policy-options policy-statement LOCAL_CONNECTED term loopback0 then accept

set routing-instances VPNA instance-type virtual-router
set routing-instances VPNA interface em0.0
set routing-instances VPNA interface lo0.100
set routing-instances VPNA protocols bgp group VPNA type external
set routing-instances VPNA protocols bgp group VPNA export LOCAL_CONNECTED
set routing-instances VPNA protocols bgp group VPNA neighbor 172.20.1.13 peer-as 1111

  • Verification: 
root@PE1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
bgp.l3vpn.0            3          3          0          0          0          0
inet.0                 0          0          0          0          0          0
Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Damped...
172.20.1.2       2222         64         67       0       0       27:57 Establ
  VPNA.inet.0: 1/2/0

2.2.2.2          1111        134        135       0       1       57:35 Establ
  bgp.l3vpn.0: 3/3/0

  VPNA.inet.0: 3/3/0

root@PE1> show route table VPNA.inet.0
VPNA.inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.100.100.100/32 *[BGP/170] 00:16:55, localpref 100
                      AS path: 2222 I
                    > to 172.20.1.2 via em0.0
172.16.48.0/24     *[BGP/170] 00:12:10, localpref 100, from 2.2.2.2
                      AS path: 3333 I
                    > to 172.20.1.6 via em1.0, label-switched-path TO_PE2
172.20.1.0/30      *[Direct/0] 01:07:41
                    > via em0.0
                    [BGP/170] 00:16:55, localpref 100
                      AS path: 2222 I
                    > to 172.20.1.2 via em0.0
172.20.1.1/32      *[Local/0] 01:07:41
                      Local via em0.0
172.20.1.12/30     *[BGP/170] 00:29:20, localpref 100, from 2.2.2.2
                      AS path: I
                    > to 172.20.1.6 via em1.0, label-switched-path TO_PE2
200.200.200.200/32 *[BGP/170] 00:11:35, localpref 100, from 2.2.2.2
                      AS path: 3333 I
                    > to 172.20.1.6 via em1.0, label-switched-path TO_PE2

 root@CPE1> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Damped...
172.20.1.1       1111         71         71       0       0       30:10 Establ
  VPNA.inet.0: 3/3/0

VPNA.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.100.100.100/32 *[Direct/0] 00:34:10
                    > via lo0.100
172.16.48.0/24     *[BGP/170] 00:13:36, localpref 100
                      AS path: 1111 3333 I
                    > to 172.20.1.1 via em0.0
172.20.1.0/30      *[Direct/0] 00:34:10
                    > via em0.0
172.20.1.2/32      *[Local/0] 00:34:10
                      Local via em0.0
172.20.1.12/30     *[BGP/170] 00:30:34, localpref 100
                      AS path: 1111 I
                    > to 172.20.1.1 via em0.0
200.200.200.200/32 *[BGP/170] 00:13:02, localpref 100
                      AS path: 1111 3333 I
                    > to 172.20.1.1 via em0.0

root@CPE1> trace routing-instance VPNA 200.200.200.200 source 100.100.100.100
traceroute to 200.200.200.200 (200.200.200.200) from 100.100.100.100, 30 hops max, 40 byte packets
 1  172.20.1.1 (172.20.1.1)  7.916 ms  0.878 ms  1.110 ms
 2  *^C
root@CPE1> ...uting-instance VPNA 200.200.200.200 source 100.100.100.100  
traceroute to 200.200.200.200 (200.200.200.200) from 100.100.100.100, 30 hops max, 40 byte packets
 1  172.20.1.1 (172.20.1.1)  0.557 ms  0.358 ms  0.316 ms
 2  * * *
 3  200.200.200.200 (200.200.200.200)  9.889 ms  1.572 ms  1.183 ms

Saturday 13 April 2013

Site to Site IOS IPsec Tunnel - Get VPN

The Cisco IOS GETVPN is a tunnel-less VPN technology that provides end-to-end security for network traffic in a native mode and maintaining the fully meshed topology.
It uses the core network's ability to route and replicate the packets between various sites within the enterprise. Cisco IOS GETVPN preserves the original source and destination IP addresses information in the header of the encrypted packet for optimal routing.

This model perfectly fits private WANs built over MPLS cores (VPN in VPN) but might not work over Internet, if the customer is using private addressing (no overlay encapsulation).

A GETVPN deployment has primarily three components, Key Server (KS), Group Member (GM), and Group Domain of Interpretation (GDOI) protocol.
GMs do encrypt/decrypt the traffic and KS distribute the encryption key to all the group members.
Since all GMs use the same key, any GM can decrypt the traffic encrypted by any other GM. GDOI protocol is used between the GM and KS for group key and group SA management. Minimum one KS is required for a GETVPN deployment.
  • GM
The group member registers with the key server to get the IPSec SA that is necessary to encrypt data traffic within the group. The group member provides the group ID to the key server to get the respective policy and keys for this group. These keys are refreshed periodically by KS, and before the current IPSec SAs expire, so that there is no loss of traffic.
  • KS
Key server is responsible for maintaining security policies, authenticating the GMs and providing the session key for encrypting traffic. KS authenticates the individual GMs at the time of registration. Only after successful registration the GMs can participate in group SA.

A group member can register at any time and receive the most current policy and keys. When a GM registers with the key server, the key server verifies the group id number of the GM. If this id number is a valid and the GM has provided valid Internet Key Exchange (IKE) credentials, the key server sends the SA policy and the Keys to the group member.

There are two types of keys that the GM will receive from the KS: the Key Encryption Key (KEK) and the Traffic Encryption Key (TEK). The TEK becomes part of the IPSec SA with which the group members within the same group encrypt the data. KEK is used to secure rekey messages between the key server and the group members.

The Key Server sends out rekey messages either because of an impending IPSec SA expiration or because the security policy has changed on the key server. Keys can be distributed during re-key using either multicast or unicast transport. Multicast method is more scalable as keys need not be transmitted to each group member individually. Unlike in unicast, KS will not receive acknowledgement from GM about the success of the rekey reception in multicast rekey method. In unicast rekey method, KS will delete a GM from its database if three consecutive rekeys are not acknowledged by that particular GM.
  • GDOI
GDOI protocol is used for Group key and group SA management. GDOI uses Internet Security Association Key Management Protocol (ISAKMP) for authenticating the GMs and KSs. All the standard ISAKMP authentication schemes like RSA Signature (certificates) and Pre-shared key can be used for GETVPN.
All the necessary crypto policies are configured only on the KS. This includes the crypto access list, crypto policies, life times etc.


Scenario:

  • KS config
    • ISAKMP
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key CISCO address 172.20.1.0 255.255.255.0
    • IPsec
crypto ipsec transform-set GETVPN esp-3des esp-md5-hmac
crypto ipsec profile GETVPN_PROFILE
 set transform-set GETVPN 

    •  RSA keys to sign the re-keying messages
crypto key generate rsa general-keys label GETVPN_KEYS
modulus 1024 exportable
    • GDOI
crypto gdoi group GETVPN_GROUP_1
 identity number 1
 server local
  rekey retransmit 10 number 2
  rekey authentication mypubkey rsa GETVPN_KEYS
  rekey transport unicast
  sa ipsec 1
   profile GETVPN_PROFILE
   match address ipv4 GETVPN_TRAFFIC
   replay time window-size 3
  address ipv4 4.4.4.4
    • ACL
ip access-list extended GETVPN_TRAFFIC
 deny   ip host 1.1.1.1 host 2.2.2.2
 deny   ip host 2.2.2.2 host 1.1.1.1
 permit ip any any
Only traffic which matches the  "permit" lines will be encrypted
  • GM config
    • ISAKMP
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key CISCO address 4.4.4.4

    • GDOI
crypto gdoi group GETVPN_GROUP
 identity number 1
 server address ipv4 4.4.4.4
crypto map GETVPN 10 gdoi
 set group GETVPN_GROUP
interface FastEthernet1/0
 crypto map GETVPN

Verification:
  • KS
KS# show crypto gdoi ks      
Total group members registered to this box: 0
Key Server Information For Group GETVPN_GROUP_1:
    Group Name               : GETVPN_GROUP_1
    Group Identity           : 1
    Group Members            : 0
    IPSec SA Direction       : Both
    ACL Configured:
access-list GETVPN_TRAFFIC

KS# show crypto gdoi group GETVPN_GROUP_1
    Group Name               : GETVPN_GROUP_1 (Unicast)
    Group Identity           : 1
    Group Members            : 0
    IPSec SA Direction       : Both
    Active Group Server      : Local
    Group Rekey Lifetime     : 86400 secs
    Group Rekey
        Remaining Lifetime   : 85960 secs
    Rekey Retransmit Period  : 10 secs
    Rekey Retransmit Attempts: 2
    Group Retransmit
        Remaining Lifetime   : 0 secs
      IPSec SA Number        : 1
      IPSec SA Rekey Lifetime: 3600 secs
      Profile Name           : GETVPN_PROFILE
      Replay method          : Time Based
      Replay Window Size     : 3
      SA Rekey
         Remaining Lifetime  : 3161 secs
      ACL Configured         : access-list GETVPN_TRAFFIC
    Group Server list        : Local

KS# show crypto gdoi ks rekey
Group GETVPN_GROUP_1 (Unicast)
    Number of Rekeys sent               : 0
    Number of Rekeys retransmitted      : 0
    KEK rekey lifetime (sec)            : 86400
        Remaining lifetime (sec)        : 85791
    Retransmit period                   : 10
    Number of retransmissions           : 2
    IPSec SA 1  lifetime (sec)          : 3600
        Remaining lifetime (sec)        : 2992
  • GM
R1#show crypto gdoi gm
Group Member Information For Group GETVPN_GROUP:
    IPSec SA Direction       : Both
    ACL Received From KS     : gdoi_group_GETVPN_GROUP_temp_acl
    Re-register
        Remaining time       : 2498 secs

R1#show crypto gdoi gm acl
Group Name: GETVPN_GROUP
 ACL Downloaded From KS 4.4.4.4:
   access-list  deny ip host 1.1.1.1 host 2.2.2.2
   access-list  deny ip host 2.2.2.2 host 1.1.1.1
   access-list  permit ip any any
 ACL Configured Locally: 

R1#show crypto gdoi group GETVPN_GROUP  
    Group Name               : GETVPN_GROUP
    Group Identity           : 1
    Rekeys received          : 0
    IPSec SA Direction       : Both
    Active Group Server      : 4.4.4.4
    Group Server list        : 4.4.4.4
                             
    GM Reregisters in        : 2274 secs
    Rekey Received           : never

    Rekeys received        
         Cumulative          : 0
         After registration  : 0
    Rekey Acks sent          : 0
 ACL Downloaded From KS 4.4.4.4:
   access-list  deny ip host 1.1.1.1 host 2.2.2.2
   access-list  deny ip host 2.2.2.2 host 1.1.1.1
   access-list  permit ip any any
KEK POLICY:
    Rekey Transport Type     : Unicast
    Lifetime (secs)          : 86237
    Encrypt Algorithm        : 3DES
    Key Size                 : 192  
    Sig Hash Algorithm       : HMAC_AUTH_SHA
    Sig Key Length (bits)    : 1024  
TEK POLICY:
  FastEthernet1/0:
    IPsec SA:
        sa direction:inbound
        spi: 0x4D42DDBA(1296227770)
        transform: esp-3des esp-md5-hmac
        sa timing:remaining key lifetime (sec): (1822)
        Anti-Replay(Time Based) : 3 sec interval
    IPsec SA:
        sa direction:outbound
        spi: 0x4D42DDBA(1296227770)
        transform: esp-3des esp-md5-hmac
        sa timing:remaining key lifetime (sec): (1822)
        Anti-Replay(Time Based) : 3 sec interval

Thursday 11 April 2013

Site to Site IOS IPsec Tunnel - DMVPN


DMVPN relies on next technologies
  • Multipoint GRE (mGRE)
  • Next-Hop Resolution Protocol (NHRP)
  • Dynamic Routing Protocol (EIGRP, RIP, OSPF, BGP)
  • Dynamic IPsec encryption
  • Cisco Express Forwarding (CEF)
  • Multipoint GRE (mGRE)
Classic GRE tunnel is point-to-point, but mGRE generalizes this idea by allowing a tunnel to have “multiple” destinations. mGRE is similar to any NBMA technology such as Frame-Relay or ATM.
The mappings between tunnel IP address and real IP address is done using NHRP.
  • Next-Hop Resolution Protocol (NHRP)
With NHRP, systems attached to an NBMA network dynamically learn the NBMA address of the other systems that are part of that network, allowing these systems to directly communicate without requiring traffic to use an intermediate hop (NHRP provides an ARP-like solution for NBMA netwroks).
For NHRP to work you need one or more entities that are capable of answering NHRP Resolution Requests. These entities are next-hop servers (NHS). Every other node will register their tunnel-to-NBMA address mapping with the server and query the server when they need to resolve
peer’s tunnel address. The use of NHRP allows dynamic discovery of new endpoints added
to the DMVPN network and thus frees the administrator from the need of extra
provisioning.
  • Dynamic Routing Protocol 
DMVPN design recommends the use of a dynamic routing protocol to propagate routes from the headend to the branch offices. 
The benefits provided by a dynamic routing protocol are:
    • Network topology information
    • Topology change notification
    • Remote peer status
EIGRP is recommended as the dynamic routing protocol because of its conservation of router CPU cycles and network bandwidth, as well as its quick convergence times. EIGRP also provides a range of options for address summarization and default route propagation.
RIP, OSPF and BGP can also be used as routing protocols for DMVPN
  • Dynamic IPsec encryption
DMVPN use an IPSec profile that is applied dynamically to the GRE over IPSec tunnels. Using an IPsec profile a static mapping to the physical interface (using crypto ACL) is not required.

Traffic is encrypted when it is forwarded from or to the tunnel interface
  • Cisco Express Forwarding (CEF)
CEF will trigger NHRP request to the NHS and learn the NBMA IP address corresponding to the
tunnel IP address. For a prefix dynamic learned across the DMVPN cloud, CEF will only attempt to resolve the next-hop IP address.

In order to permit direct routing between spokes, all prefixes should be learned by spokes with the next-
hop IP addresses pointing to the route origin.
    • In order to accomplish this when dynamic routing protocol is EIGRP use command  
no ip next-hop-self eigrp [AS_Number]
    • In order to accomplish this when dynamic routing protocol is OSPF use command 
ip ospf network-type broadcast

DMVPN Topologies
  • Dual hub-dual DMVPN cloud
  • Dual hub-single DMVPN cloud
Wherever dual hub is mentioned it means two or more hubs. In these topologies at least two hubs are recommended for redundancy.

A DMVPN cloud topology can support either a hub-and-spoke or spoke-to-spoke deployment model.
In a hub-and-spoke deployment model, each headend uses an mGRE interface and each branch uses a p2pGRE or mGRE interface. In a spoke-to-spoke deployment model, both the headend and the branch must use mGRE interfaces.

  • Dual DMVPN Cloud Topology





  • Single DMVPN Cloud Topology



The difference between the two topologies is most apparent on the branch router. With a single DMVPN subnet, the branch router has a single mGRE tunnel, and both headends are mapped to this tunnel through this mGRE interface. In a dual DMVPN topology, the branch router has a unique tunnel pointing to a unique headend. Standard routing protocols such as EIGRP, BGP or OSPF are used to determine the active hub over either topology.

In general the single DMVPN cloud topology is best when dynamic spoke-spoke tunnels are required, because spoke-spoke tunnels can only be built within a DMVPN cloud not between DMVPN clouds. The dual DMVPN cloud topology is often easier for hub-and-spoke only networks, in this case it can be easier to configure the routing protocol to prefer one DMVPN cloud (hub) over the other since the routing protocol receives routing information from the hubs on different tunnel interfaces. 



Scenario A - Single Cloud Single Hub, hub-and-spoke DMVPN
    • In a hub-and-spoke model tunnels are continuously up.
    • When a spoke wants to transmit a packet to another spoke, traffic will be routed trough hub router.
    • Tunnel created on the spoke to the hub will be a point-to-point tunnel.
  • ISAKMP and IPsec config
Same config on all devices (hub and spokes)
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key CISCO address 0.0.0.0 0.0.0.0
crypto ipsec transform-set 3DES esp-3des esp-md5-hmac
crypto ipsec profile DMVPN
 set transform-set 3DES 
  • Tunnel configuration - hub
interface Tunnel100
 ip address 10.1.1.1 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 tunnel source Loopback100
 tunnel mode gre  multipoint
 tunnel protection ipsec profile DMVPN
  • Tunnel configuration - spoke
    • spoke1 
interface Tunnel100
 ip address 10.1.1.2 255.255.255.0
 ip nhrp map 10.1.1.1 1.1.1.1
 ip nhrp network-id 1
 ip nhrp nhs 10.1.1.1
 tunnel source Loopback100
 tunnel destination 1.1.1.1
 tunnel protection ipsec profile DMVPN
    • spoke2 
interface Tunnel100
 ip address 10.1.1.3 255.255.255.0
 ip nhrp map 10.1.1.1 1.1.1.1
 ip nhrp network-id 1
 ip nhrp nhs 10.1.1.1
 tunnel source Loopback100
 tunnel destination 1.1.1.1
 tunnel protection ipsec profile DMVPN
  • EIGRP configuration 
    • hub
router eigrp 100
 network 10.1.1.0 0.0.0.255
 network 192.168.1.0
 no auto-summary
Because of EIGRP split-horizon filters updates received by hub from spoke1 and spoke2 are never sent back on the Tunnel 100 interface. If communication between spoke1 and spoke2 is required you need to disable split-horizon on hub device.
 interface Tunnel100
 no ip split-horizon eigrp 100
Verification:
hub#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA
C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.
1001  1.1.1.1         2.2.2.2                  ACTIVE 3des md5  psk  2  23:48:31  
       Engine-id:Conn-id =  SW:1
1002  1.1.1.1         3.3.3.3                  ACTIVE 3des md5  psk  2  23:48:45  
       Engine-id:Conn-id =  SW:2

hub#show crypto ipsec sa detail
interface: Tunnel100
    Crypto map tag: Tunnel100-head-0, local addr 1.1.1.1
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)
   current_peer 2.2.2.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 152, #pkts encrypt: 152, #pkts digest: 152
    #pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0
     local crypto endpt.: 1.1.1.1, remote crypto endpt.: 2.2.2.2
     path mtu 1514, ip mtu 1514, ip mtu idb Loopback100
     current outbound spi: 0x4DAA0FBB(1302990779)
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/47/0)
   current_peer 3.3.3.3 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 150, #pkts encrypt: 150, #pkts digest: 150
    #pkts decaps: 143, #pkts decrypt: 143, #pkts verify: 143
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0
     local crypto endpt.: 1.1.1.1, remote crypto endpt.: 3.3.3.3
     path mtu 1514, ip mtu 1514, ip mtu idb Loopback100
     current outbound spi: 0x62CB1B9B(1657478043)

hub#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   10.1.1.3                Tu100             10 00:11:05  681  5000  0  7
0   10.1.1.2                Tu100             12 00:11:06   36  5000  0  7
spoke1#show ip route eigrp
D    192.168.1.0/24 [90/297372416] via 10.1.1.1, 00:10:33, Tunnel100
D    192.168.3.0/24 [90/310172416] via 10.1.1.1, 00:09:37, Tunnel100
spoke1#traceroute 192.168.3.1    
Type escape sequence to abort.
Tracing the route to 192.168.3.1
  1 10.1.1.1 40 msec 8 msec 8 msec
  2 10.1.1.3 16 msec *  16 msec
Scenario B - Single Cloud Single Hub, spoke-to-spoke DMVPN
    • Unlike hub-and-spoke model, when one spoke wants to communicate to another spoke it doesn't do so via the hub.
    • When a spoke wants to transmit a packet to another spoke, it uses NHRP to dynamically determine the required destination address of the target spoke.
    • The hub router acts as the NHRP server and handles this request for the source spoke, but there ends it's role in this particular transaction
    • The two spokes dynamically create an IPsec tunnel between them (via the single mGRE interface) and data can be directly transferred. 
    • This dynamic spoke-to-spoke tunnel will be automatically torn down after a (configurable) period of inactivity
    • The spokes can no longer be a point-to-point tunnel. Like the hub they will need to be able to dynamically accept incoming SA requests. Tunnels in a spoke-to-spoke setup are multipoint (mGRE) tunnels.
    • The spokes still learn all routing updates via the hub. Neighborships are still formed only         between the hub and the spoke. The hub must be configured so that it doesn't set itself as the next hop for all routes that it advertises
  • ISAKMP and IPsec config
Same config on all devices (hub and spokes)
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key CISCO address 0.0.0.0 0.0.0.0
crypto ipsec transform-set 3DES esp-3des esp-md5-hmac
crypto ipsec profile DMVPN
 set transform-set 3DES 
  • Tunnel configuration - hub
interface Tunnel100
 ip address 10.1.1.1 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 no ip split-horizon eigrp 100
 tunnel source Loopback100
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN
  • Tunnel configuration - spoke
    • spoke1
interface Tunnel100
 ip address 10.1.1.2 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp map 10.1.1.1 1.1.1.1
 ip nhrp map multicast 1.1.1.1
 ip nhrp network-id 1
 ip nhrp nhs 10.1.1.1
 tunnel source Loopback100
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN
    • spoke2 
interface Tunnel100
 ip address 10.1.1.3 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp map 10.1.1.1 1.1.1.1
 ip nhrp map multicast 1.1.1.1
 ip nhrp network-id 1
 ip nhrp nhs 10.1.1.1
 tunnel source Loopback100
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN
Without "ip nhrp map multicast 1.1.1.1" command, EIGRP protocol will not exchange any multicast packets between hub and spokes.
  • EIGRP configuration 
    • hub
router eigrp 100
 network 10.1.1.0 0.0.0.255
 network 192.168.1.0
 no auto-summary
Because of EIGRP split-horizon filters updates received by hub from spoke1 and spoke2 are never sent back on the Tunnel 100 interface. 
in this model design traffic from spoke1 to spoke2 should not pass trough hub device. In order to accomplish this next EIGRP configuration is needed:
interface Tunnel100
 no ip next-hop-self eigrp 100
 no ip split-horizon eigrp 100

Verification
spoke1#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA
C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.
1003  2.2.2.2         1.1.1.1                  ACTIVE 3des md5  psk  2  23:37:29  
       Engine-id:Conn-id =  SW:3
1004  2.2.2.2         3.3.3.3                  ACTIVE 3des md5  psk  2  23:45:08  
       Engine-id:Conn-id =  SW:4

spoke1#show crypto ipsec sa detail
interface: Tunnel100
    Crypto map tag: Tunnel100-head-0, local addr 2.2.2.2
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/47/0)
   current_peer 1.1.1.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 333, #pkts encrypt: 333, #pkts digest: 333
    #pkts decaps: 339, #pkts decrypt: 339, #pkts verify: 339
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 1, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0
     local crypto endpt.: 2.2.2.2, remote crypto endpt.: 1.1.1.1
     path mtu 1514, ip mtu 1514, ip mtu idb Loopback100
     current outbound spi: 0xE6C15153(3871428947)
protected vrf: (none)
   local  ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/47/0)
   current_peer 3.3.3.3 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 7, #pkts encrypt: 7, #pkts digest: 7
    #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0
     local crypto endpt.: 2.2.2.2, remote crypto endpt.: 3.3.3.3
     path mtu 1514, ip mtu 1514, ip mtu idb Loopback100
     current outbound spi: 0xF31F30FC(4078907644)

 hub#show ip eigrp neighbors          
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   10.1.1.3                Tu100             13 00:16:59   43  5000  0  21
0   10.1.1.2                Tu100             11 00:16:59  848  5000  0  23
spoke1#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.1.1.1                Tu100             11 00:16:53  119  5000  0  24
spoke1#show ip route eigrp
D    192.168.1.0/24 [90/297372416] via 10.1.1.1, 00:17:30, Tunnel100
D    192.168.3.0/24 [90/310172416] via 10.1.1.3, 00:17:30, Tunnel100
spoke1#traceroute 192.168.3.1
Type escape sequence to abort.
Tracing the route to 192.168.3.1
  1 10.1.1.3 40 msec *  4 msec