Showing posts with label VPN. Show all posts
Showing posts with label VPN. Show all posts

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

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

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

Monday, 8 April 2013

Site to Site IOS IPsec Tunnel - Part V - GRE over IPsec


Although IPsec provides a secure method for tunneling data across an IP network, it has limitations.
IPsec does not support IP broadcast or IP multicast, preventing the use of protocols that rely on these
features, such as routing protocols. IPsec also does not support the use of multiprotocol traffic.
Generic Route Encapsulation (GRE) is a protocol that can be used to “carry” other passenger protocols,
such as IP broadcast or IP multicast, as well as non-IP protocols.


Although IPsec provides a secure method for tunneling data across an IP network, it has limitations.
IPsec does not support IP broadcast or IP multicast, preventing the use of protocols that rely on these
features, such as routing protocols. IPsec also does not support the use of multiprotocol traffic.
Generic Route Encapsulation (GRE) is a protocol that can be used to “carry” other passenger protocols,
such as IP broadcast or IP multicast, as well as non-IP protocols.


Before the introduction of VTI, using GRE over IPSec was the only way to configure dynamic routing over encrypted tunnels.

To encrypt GRE tunneled traffic, you can use also an IPSec encryption profile (like with VTI implementation)

Scenario A (with crypto map)

  • R1 config
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
crypto isakmp key CISCO address 172.20.1.6

crypto ipsec transform-set 3DES esp-3des esp-md5-hmac 

crypto map VPN 10 ipsec-isakmp
match address GRE_VPN
set peer 172.20.1.6
set transform-set 3DES

ip access-list extended GRE_VPN
permit gre host 172.20.1.2 host 172.20.1.6

interface Tunnel100
 ip address 192.168.1.2 255.255.255.252
 tunnel source 172.20.1.2
 tunnel destination 172.20.1.6
 tunnel mode gre ip
interface FastEthernet1/0
 ip address 172.20.1.2 255.255.255.252
 crypto map VPN
  • R2 config
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
crypto isakmp key CISCO address 172.20.1.2

crypto ipsec transform-set 3DES esp-3des esp-md5-hmac 

crypto map VPN 10 ipsec-isakmp
match address GRE_VPN
set peer 172.20.1.2
set transform-set 3DES

ip access-list extended GRE_VPN
permit gre host 172.20.1.6 host 172.20.1.2

interface Tunnel100
 ip address 192.168.1. 255.255.255.252
 tunnel source 172.20.1.6
 tunnel destination 172.20.1.2
 tunnel mode gre ip
interface FastEthernet1/0
 ip address 172.20.1.6 255.255.255.252
 crypto map VPN
Scenario B (with ipsec profile)
  • R1 config
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
crypto isakmp key CISCO address 172.20.1.6

crypto ipsec transform-set 3DES esp-3des esp-md5-hmac 

crypto ipsec profile VTI
 set transform-set 3DES 

interface Tunnel100
 ip address 192.168.1.2 255.255.255.252
 tunnel source 172.20.1.2
 tunnel destination 172.20.1.6
 tunnel mode gre ip
 tunnel protection ipsec profile VTI
  • R2 config
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
crypto isakmp key CISCO address 172.20.1.2

crypto ipsec transform-set 3DES esp-3des esp-md5-hmac 

crypto ipsec profile VTI
 set transform-set 3DES 

interface Tunnel100
 ip address 192.168.1.1 255.255.255.252
 tunnel source 172.20.1.6
 tunnel destination 172.20.1.2
 tunnel mode gre ip
 tunnel protection ipsec profile VTI


Site to Site IOS IPsec Tunnel - Part IV Virtual Tunnel Interface

Cisco IPSec VTIs are a tool that customers can use to configure IPSec-based VPNs between site-to-site devices.

Benefits

  • Supports multicast encryption---Customers can use the Cisco IOS Software IPSec VTIs to transfer the multicast traffic, control traffic, or data traffic
  • Provides a routable interface---Cisco IOS Software IPSec VTIs can support all types of IP routing protocols. 
  • Improves scaling---IPSec VTIs need fewer established security associations to cover different types of traffic, both unicast and multicast, thus enabling improved scaling.
  • Offers flexibility in defining features---An IPSec VTI is an encapsulation within its own interface.
An IPSec virtual tunnel configuration does not require a static mapping of IPSec sessions to a physical interface. This allows for the flexibility of sending and receiving encrypted traffic on any physical interface, such as in the case of multiple paths. Traffic is encrypted when it is forwarded from or to the tunnel interface. The traffic is forwarded to or from the tunnel interface by virtue of the IP routing table. Dynamic or static IP routing can be used to route the traffic to the encryption engine. Using IP routing to forward the traffic to encryption simplifies the IPSec VPN configuration when compared with using access control lists (ACLs) with the crypto map in native IPSec configuration.

  • Dynamic routing---Dynamic routing is used in this configuration to propagate the remote network addresses to the local site. Using dynamic routing simplifies manageability of the IPSec network and enables it to expand without having to manually maintain reach information.
  • Quality of service (QoS)---QoS can be used to improve the performance of different applications across the network. In this configuration, traffic shaping is used between the two sites to limit the total amount of traffic that should be transmitted between the two sites. Additionally, the QoS configuration can support any combination of QoS features offered in Cisco IOS Software to support any of the voice, video, or data applications.
Scenario:

  • R1 config
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
crypto isakmp key CISCO address 172.20.1.6

crypto ipsec transform-set 3DES esp-3des esp-md5-hmac 

crypto ipsec profile VTI
 set transform-set 3DES 

interface Tunnel100
 ip address 192.168.1.2 255.255.255.252
 tunnel source 172.20.1.2
 tunnel destination 172.20.1.6
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
  • R2 config
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
crypto isakmp key CISCO address 172.20.1.2

crypto ipsec transform-set 3DES esp-3des esp-md5-hmac 

crypto ipsec profile VTI
 set transform-set 3DES 

interface Tunnel100
 ip address 192.168.1.1 255.255.255.252
 tunnel source 172.20.1.6
 tunnel destination 172.20.1.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

Verification:

 R1#show crypto ipsec profile
IPSEC profile VTI
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
3DES,
}


R1#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.
1004  172.20.1.2      172.20.1.6               ACTIVE 3des md5  psk  1  21:27:07    
       Engine-id:Conn-id =  SW:4

R1#show crypto ipsec sa detail
interface: Tunnel100
    Crypto map tag: Tunnel100-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): (0.0.0.0/0.0.0.0/0/0)
   current_peer 172.20.1.6 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
    #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.: 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: 0x635E3D56(1667120470)



Friday, 5 April 2013

Site to Site IOS IPsec Tunnel - Part II NAT-T

ESP  encrypts all critical information, encapsulating the entire inner TCP/UDP datagram within an ESP header. ESP is an IP protocol in the same sense  that TCP and UDP are IP protocols (OSI Network Layer 3), but it does not  have any port  information like TCP/UDP (OSI Transport Layer 4).  This is a difference from  ISAKMP which uses UDP port 500 as its transport layer.

Because ESP is a protocol without ports, traffic encapsulated with ESP can not pass through PAT devices.

NAT Traversal performs two tasks:

  • Detects if both ends support NAT-T 
  • Detects NAT devices along the transmission path (NAT-Discovery)
Step one occurs in ISAKMP Main Mode messages one and two.  If both devices support NAT-T, then NAT-Discovery is performed in ISKAMP Main Mode messages (packets) three and four.  THe NAT-D payload sent is a hash of the original IP address and port. Devices exchange two NAT-D packets, one with source IP and port, and another with destination IP and port. The receiving device recalculates the hash and compares it with the hash it received; if they don't match a NAT device exists.  

If a NAT device has been determined to exist, NAT-T will change the ISAKMP transport with ISAKMP Main Mode messages five and six, at which point all ISAKMP packets change from UDP port 500 to UDP port 4500.  NAT-T encapsulates the Quick Mode (IPsec Phase 2) exchange inside UDP 4500 as well.  After Quick Mode completes data that gets encrypted on the IPsec Security Association is encapsulated inside UDP port 4500 as well, thus providing a port to be used in the PAT device for translation

To visualize how this works and how the IP packet is encapsulated:
  • Clear text packet will be encrypted/encapsulated inside an ESP packet
  • ESP packet will be encapsulated inside a UDP/4500 packet.
Scenario:

  • ISAKMP configuration
    • R1
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
crypto isakmp key CISCO address 172.20.1.5
    • R2
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
crypto isakmp key CISCO address 0.0.0.0 0.0.0.0
  • IPsec configuration
    • R1
ip access-list extended SITE1_TO_SITE2
 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255

crypto ipsec transform-set 3DES_MD5 esp-3des esp-md5-hmac 

 crypto map VPN_SITE_TO_SITE 10 ipsec-isakmp
 set peer 172.20.1.5
 set transform-set 3DES_MD5
 match address SITE1_TO_SITE2
 crypto map VPN_SITE_TO_SITE
    • R2
crypto ipsec transform-set 3DES_MD5 esp-3des esp-md5-hmac 

crypto dynamic-map NAT_T_MAP 10
 set transform-set 3DES_MD5 

crypto map VPN_SITE_TO_SITE 10 ipsec-isakmp dynamic NAT_T_MAP 
  • ASA configuration
access-list TRAFIC_IN extended permit udp any any eq isakmp
access-list TRAFIC_IN extended permit udp any any eq 4500
access-group TRAFIC_IN in interface outside
Verification:

R2#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.
1007  172.20.1.5      172.20.1.6               ACTIVE 3des md5  psk  1  23:49:30 N  
       Engine-id:Conn-id =  SW:7

R2#show crypto dynamic-map
Crypto Map Template"NAT_T_MAP" 10
No matching address list set.
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
3DES_MD5,
}

R2#show crypto ipsec sa detail
interface: FastEthernet1/0
    Crypto map tag: VPN_SITE_TO_SITE, local addr 172.20.1.5
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
   current_peer 172.20.1.6 port 4500
     PERMIT, flags={}
    #pkts encaps: 715, #pkts encrypt: 715, #pkts digest: 715
    #pkts decaps: 715, #pkts decrypt: 715, #pkts verify: 715
    #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.5, remote crypto endpt.: 172.20.1.6
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
     current outbound spi: 0x810D44F8(2165130488)

ciscoasa# show nat detail
Manual NAT Policies (Section 1)
1 (inside) to (outside) source static INSIDE interface
    translate_hits = 4, untranslate_hits = 9
    Source - Origin: 172.20.1.0/30, Translated: 172.20.1.6/30