Categories

CUC (6) CUCM (27) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Tuesday, 7 August 2018

F5 webtop access policy and resource assignment configuration


F5 webtops can be used to provide 3rd party portal access into your network. A webtop is essentially nothing more that a very fancy VIP hosted on the F5 appliance itself. You can do 2FA authentication (see my previous post), you can customise the look and feel of the portal for instance by sticking your company's logo in it. but that is all cosmetic.  The real smarts of a webtop, lie within the access profile, or better the access profiles' access policy.

So lets get started, go to the access profile associated with your webtop ACCESS POLICY > ACCESS PROFILES > ACCESS PROFILES LIST,  then go to the visual policy editor (see below).

Fig. 1 - Access Profile on F5

As you can see in the screenshot of the visual policy editor below,  there are two main threads, one for staff access and one for vendor access (discrimination done on the basis of AD group).

Fig.2.- Visual Policy editor

I would like to focus on the vendor access, so after 2FA has taken place and it has been established, based on the user's AD group member ship, that the user is a vendor, how can we assign certain resources/access methods to this user and can we differentiate between vendors.  To answer this. let me drill into the "Vendor Resource Assign" element in Fig 2. visual policy editor.

Fig, 3 shows the resource assignment screen in detail

Fig. 3 resource assignment detail visual policy editor
in this example there are 3 vendor groups, each with their own resources, they have access to once successfully authenticated through 2FA. these 3 groups all have their own AD group. (see Expression user is a member of CN=blahblah). These 3 vendors/AD groups each have their own resources assigned to them (app tunnels and Remote Desktops). These are all individual resources, i,e, they only connect to a single IP address.  For instance the RDP resource called "EXEC", that gets assigned to the first AD group "networks" is defined as follows:

Fig.4.-Remote Desk top details
so this remote desktop only allows access to 10.x.y.17.  This is all good and well if your vendor only requires access to a limited amount of IP addresses, but it quickly gets out of hand if access to dozens if not hundreds of IP addresses is required.

Figure 5 shows a wildcard destination IP address, using % as the host name (pre populating last IP address logged into).


Fig. 5- multiple IP RDP access

Of course this would gives no control over what gets access and what not. So you would need to put an ACL in places.  Fig. 3 shows you can add a static ACL to the AD group's resource assignment. Fig. 6 show the "vendor_access" ACL that gets assigned to all vendors. which restricts access to only 2 subnets, in this case. 

Fig. 6 User defined ACLs


Sunday, 5 August 2018

Call Manager Music on Hold multicasting




Music on hold (MOH) using, multi casting can be a bit of a challenge to set up, that is possibly why a lot of people don't bother.  Multicast music on hold, uses the capability of a voice gateway's capability to stream a wave file  (i.e. your music on hold file), from flash. In order for this to work, call manager fall back needs to be configured.


Bandwidth savings across the WAN (although not dramatically) and SRST are the main reasons for implementing multicast music on hold.

So how do Cisco phones use and invoke MOH?

The phone (holder) that puts the other phone on hold (holdee), will dictate what music on hold is being streamed to the holdee.  The Media resource group (list) on the phone being put on hold decides how this is done; either through a unicast or a multicast. 

So music on hold is essentially streamed from our (SRST) router and so it will be the multicast server, from a multicast point of view, and all phones that need to have that particular MOH file played out to them, i.e. are being put on hold will join that particular multicast address

So first of all,  upload the file onto CUCM  (media resources > MOH audio file management). Then, create a music on hold source on CUCM and allow it to use multicast (see pic below).




Now, if you use periodic announcements and periodic announcements, you will have an issue, because the MOH stream will comprise of multiple separate wav files. If you want to replicate that to multicast MOH, you will need to record that into a single wav file for the voice gateways flash. Realistically, if your announcements are fairly dynamic, I would not bother with Multicast MOH. Because the call manager fallback configuration does not allow for periodic announcements in separate wav files. At least not out of the box. If your MOH file is a single wav file without any periodic announcement, then keep reading.  

OK, so my example is based on CarribeanBlue.wav as stream number 5 and multicast address 239.1.1.5.


now configure your voice gateway to allow multicast music on hold:

ccm-manager music-on-hold bind GigabitEthernet0/0  

call-manager-fallback
 max-conferences 8 gain -6
 transfer-system full-consult
 ip source-address 10.10.10.10 port 2000  (ip address of the bind interface)
 max-ephones 10
 max-dn 10
 moh enable-g711 "flash0:/CaribbeanBlue.wav"
 multicast moh 239.1.1.5 port 16384      <----based on stream 5 and base address 239.1.1.1


Now that the voice gateway and cucm have been configured to allow an MOH file to multicast, you will need a media resource group that will attempt  to call for a multicast resource as soon as a phone that has that media resource group configured, if being put o hold.



A good way to trouble shoot is to see if all your Media resource group, moh server and audio source are configured properly, is to put a multicast enabled phone on hold and check were the stream is set up to. Do this by browsing to the IP address of the phone that is being put on hold and check its Stream1. 





In the screen shot above, you can see the phone is trying to become a member of the 239.1.1.5 multicast address, which is MOH file number 5, starting from the 239.1.1.1 base multicast address. 


another way to do this is by debugging pim on your router:

sw1#debug ip pim
PIM debugging is on
sw1#
Oct 16 04:02:05: PIM(0): Building Graft message for 239.1.1.5, Vlan40: no entries


Tools:

  • ping a multicast IP address
  • sh ip mroute
  • on your multicast enabled interface configure "ip igmp join group 239.1.1.5"




when pinging 239.1.1.5, from our multicast server:

voipgw#ping 239.1.1.5
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.5, timeout is 2 seconds:

Reply to request 0 from 10.61.1.11, 1 ms

you can see that 10.61.1.11 responded to the multicast ping.   10.61.1.11 also contains an interface that has statically joined the 239.1.1.5 igmp group  as can be seen from the  show ip mroute command





(10.61.1.201  (=source), 239.1.1.5 (=group)), 00:01:24/00:01:37, flags: LT
  Incoming interface: Vlan11, RPF nbr 10.61.1.201, Partial-SC
  Outgoing interface list:
    Vlan40, Forward/Sparse-Dense, 00:01:24/00:00:00, H











check this post on how to manually join a multicast group:

http://packetlife.net/blog/2008/jul/21/two-ways-force-igmp-join/




How to add a Fabric extender (FEX) to a Nexus

make sure the feature fex  is on in the config

add the fex:

fex 101
  pinning max-links 1
  description "FEX0101"
  type N2348UPQ
  port 1-16 type fc     <----------(this is optional and depending on requirments)



add the port channel

interface port-channel101
  description PC to RICH-FEX-101
  switchport mode fex-fabric
  fex associate 101


configure physical ports that will make up the port channel:

for instance;


interface Ethernet2/1
  description FEX-101 Port 1
  switchport mode fex-fabric
  fex associate 101
  channel-group 101

interface Ethernet2/2
  description FEX-101 Port 2
  switchport mode fex-fabric
  fex associate 101
  channel-group 101




check status of FEX

CORE-SW1# show fex 101 detail
FEX: 101 Description: FEX0101   state: Image Download
  FEX version: 7.0(6)N1(1) [Switch version: 7.3(0)N1(1)]
  FEX Interim version: 7.0(6)N1(1)
  Switch Interim version: 7.3(0)N1(1)
  Module Sw Gen: 21  [Switch Sw Gen: 21]
  Post level: complete
  Pinning-mode: static    Max-links: 1
  Fabric port for control traffic: Eth2/1
  FCoE Admin: false
  FCoE Oper: true
  FCoE FEX AA Configured: false
  Fabric interface state:
    Po101 - Interface Up. State: Active
    Eth2/1 - Interface Up. State: Active
    Eth2/2 - Interface Up. State: Active
Logs:
08/06/2018 01:06:19.692901: Module register received
08/06/2018 01:06:19.694800: Image Version Mismatch
08/06/2018 01:06:19.696044: Registration response sent
08/06/2018 01:06:19.696325: Requesting satellite to download image<<<<<<

as you can see, the fex will need to change version, so be in sync with the Nexus 5000


give it a couple of minutes and check the fex again:

08/06/2018 01:18:11.631914: Module Online Sequence
08/06/2018 01:18:23.635025: Module Online<------------------------------

FEX: 101 Description: FEX0101   state: Online
  FEX version: 7.3(0)N1(1) [Switch version: 7.3(0)N1(1)]
  FEX Interim version: 7.3(0)N1(1)
  Switch Interim version: 7.3(0)N1(1)
  Extender Serial: abcdefghijklmn
  Extender Model: N2K-C2348UPQ-10GE,  Part No: 73-15489-04
  Card Id: 265, Mac Addr: 9c:57:ad:22:82:02, Num Macs: 96
  Module Sw Gen: 21  [Switch Sw Gen: 21]
  Post level: complete
  Pinning-mode: static    Max-links: 1
  Fabric port for control traffic: Eth2/1
  FCoE Admin: false
  FCoE Oper: true
  FCoE FEX AA Configured: false
  Fabric interface state:
    Po101 - Interface Up. State: Active
    Eth2/1 - Interface Up. State: Active
   Eth2/2 - Interface Up. State: Active
  Fex Port        State  Fabric Port
      Eth101/1/17  Down        None
      Eth101/1/18  Down        None
      Eth101/1/19  Down        None
      Eth101/1/20  Down        None
      Eth101/1/21  Down        None
      Eth101/1/22  Down        None
      Eth101/1/23  Down        None
      Eth101/1/24  Down        None
      Eth101/1/25  Down        None
      Eth101/1/26  Down        None
      Eth101/1/27  Down        None
      Eth101/1/28  Down        None
      Eth101/1/29  Down        None
      Eth101/1/30  Down        None
      Eth101/1/31  Down        None
      Eth101/1/32  Down        None
      Eth101/1/33  Down        None
      Eth101/1/34  Down        None
      Eth101/1/35  Down        None
      Eth101/1/36  Down        None
      Eth101/1/37  Down        None
      Eth101/1/38  Down        None
      Eth101/1/39  Down        None
      Eth101/1/40  Down        None
      Eth101/1/41  Down        None
      Eth101/1/42  Down        None
      Eth101/1/43  Down        None
      Eth101/1/44  Down        None
      Eth101/1/45  Down        None
      Eth101/1/46  Down        None
      Eth101/1/47  Down        None
      Eth101/1/48  Down        None
        fc101/1/1  Down       Po101
        fc101/1/2  Down       Po101
        fc101/1/3  Down       Po101
        fc101/1/4  Down       Po101
        fc101/1/5  Down       Po101
        fc101/1/6  Down       Po101
        fc101/1/7  Down       Po101
        fc101/1/8  Down       Po101
        fc101/1/9  Down       Po101
       fc101/1/10  Down       Po101
       fc101/1/11  Down       Po101
       fc101/1/12  Down       Po101
       fc101/1/13  Down       Po101
       fc101/1/14  Down       Po101
       fc101/1/15  Down       Po101
       fc101/1/16  Down       Po101
Logs:
08/06/2018 01:06:19.692901: Module register received
08/06/2018 01:06:19.694800: Image Version Mismatch
08/06/2018 01:06:19.696044: Registration response sent
08/06/2018 01:06:19.696325: Requesting satellite to download image
08/06/2018 01:11:41.264825: Image preload successful.
08/06/2018 01:11:43.001463: Deleting route to FEX
08/06/2018 01:11:43.009575: Module disconnected
08/06/2018 01:11:43.011006: Module Offline
08/06/2018 01:11:43.037788: Deleting route to FEX
08/06/2018 01:11:43.045576: Module disconnected
08/06/2018 01:11:43.047727: Offlining Module
08/06/2018 01:14:58.667377: Module register received
08/06/2018 01:14:58.670556: Registration response sent
08/06/2018 01:14:59.393077: Deleting route to FEX
08/06/2018 01:14:59.402292: Module disconnected
08/06/2018 01:14:59.403727: Module Offline
08/06/2018 01:14:59.434418: Deleting route to FEX
08/06/2018 01:14:59.442054: Module disconnected
08/06/2018 01:14:59.444168: Offlining Module
08/06/2018 01:14:59.485257: Deleting route to FEX
08/06/2018 01:14:59.500412: Module disconnected
08/06/2018 01:14:59.502546: Offlining Module
08/06/2018 01:15:28.668480: Module timed out
08/06/2018 01:18:11.583865: Module register received
08/06/2018 01:18:11.586904: Registration response sent
08/06/2018 01:18:11.630954: create module inserted event.
08/06/2018 01:18:11.631914: Module Online Sequence
08/06/2018 01:18:23.635025: Module Online<---------------------------------------

Thursday, 21 June 2018

ASA AnyConnect VPN 2 Factor authentication configuration

RADIUS and Symantec VIP.

I will use screenshots of ASDM, and at the end I will add the required CLI commands.  the diagram below show a diagram of the steps the FW goes through when using 2FA authentication:


Fig.1 -  2FA steps ASA

As you can see in Fig. 1 the first step in the authentication process is to connect to ISE which then connects to AD, you could configure it to go to AD directly.


Configuration:


Any Connect Connection Profile


  • enable Cisco Anyconnect acces on the outside interface.
    • choose to "Bypass interface access lists for inbound VPN sessions
Fig.2. - remote VPN connection profile


Now drill into the connection profile itself.  (Fig.2)


Fig -2 Main Anyconnect connection profile window
Fig.2. shows that the authentication is set to AAA, which is offloaded to ISE using RADIUS, which authenticates, on (very likely) AD credentials. I will address the ISE configuration part of this in a separate post. So pretty much the first factor is the RADIUS authentication.

Because 2FA, uses two authentication sources, as the name suggest, you will also need to add a secondary authentication method, this time I have used a server group called VIP (using Symantec's VIP service).





If you are using Symantec or any 3rd party 2FA provider, such as through MS Azure, then you can decide to point your secondary AAA server to either an on premise 2FA gateway or a cloud thingy. Either way, from an ASA point of view you will need a different IP address. Typically, you will connect on ports tcp/1812 for authentication and tcp/1813 for accounting.


Group Policy


Configure a group policy to assign to your connection profile. I prefer to create a separate group policy for each profile, even though I would inherit most of the parameters from the default policy. This makes it easier to make changes that do not impact other connection profiles using the same default values. Assign this group policy to the connection profile in the step above. If you are going to use the Anyconnect client. You would need to select SSL VPN client.

Anyconnect prompt customisation

you might decide to change the anyconnect login prompt to state  that the second authentication of a 2FA security code is required. for instance:




To do this, you will need to customize the client's language file:


Config > Remote Access VPN > Network (Client) Access > AnyConnect Customization/Localization > GUI Text and Messages. Edit the language file:

msgid "Second Password"
msgstr "VIP Access Security Code:"

CLI COMMANDS:


group-policy AnyConnect_2FA attributes
 vpn-simultaneous-logins 2
 vpn-tunnel-protocol ssl-client 
 webvpn
  anyconnect profiles value Test_Client_Profile type user


webvpn
 enable Internet
 anyconnect image disk0:/anyconnect-win-4.5.01044-webdeploy-k9.pkg 1
 anyconnect image disk0:/anyconnect-macos-4.5.01044-webdeploy-k9.pkg 2
 anyconnect profiles Test_Client_Profile disk0:/test_client_profile.xml
 anyconnect enable
 tunnel-group-list enable

tunnel-group 2FA_AnyConnect general-attributes
 address-pool Pool1
 authentication-server-group ISERADIUS
 secondary-authentication-server-group VIP use-primary-username
 default-group-policy 2FA_SSL

if you want to use alias for the vpn connection profile:

tunnel-group 2FA_AnyConnect webvpn-attributes
 group-alias Test_2FA enable

aaa-server VIPRADIUS (Inside) host 192.168.100.10
 timeout 60
 key *****
 authentication-port 1812
 accounting-port 1813
aaa-server VIPRADIUS (Inside) host 192.168.200.10
 timeout 60
 key *****
 authentication-port 1812

 accounting-port 1813


Namaste!




Monday, 18 June 2018

F5 Application Policy Manager Authentication using AD

Apart from a F5 BIG-IP being an awesome load balancer with all sorts of VIPs and SSL offloading capabilities, it is also capable of providing VPN and portal capabilities. These capabilities are configured under the Access Policy tab of your F5 and become available once the correct license is installed. To find out your licensed entitlements, go to SYSTEM > License.


Ok, so let's assume you want to give external users (or roaming users) access to some sort of web portal, that is facing the internet (for instance a website for your employees to enter their time sheets, or some ordering tool for your sales force, could be anything).


So the first thing you will need to do is set up your authentication, for this example we will use Active Directory as our source for authentication.

Authentication using Active Directory:

In your access policy tab, go to AAA servers > Active directory (please note that you can also chooose LDAP, RADIUS, TACACS, SAML and a few more).

Essentially, you will now add 1 or more AD servers to a pool that the access profile (next step) can point to. The F5 will use a service account to allow credentials checks on AD. This of course will need to be pre-provisioned in AD.


Access policy configuration.

Below is a screenshot of an access policy called SSO_portal.


Figure 1, access policy configuration








I have added two AAA active directory pools: aaa_ad and aaa_r.

Apart from the AAA servers, all the smarts lie in the actual policy itself. In figure 1, this policy can be view through the visual policy editor. So lets have a look at the actual policy



Figure 2. Visual policy editor
As you can see in the policy above, the first check is that of the IP address of the party that is trying to log in. Based on that WebAuth, or Kerberos is used and Webauth for all others (Fallback). After this the userID is checked, to see if it is part of a certain predefined AD group. If it is, the authentication is successful and the authentication is ALLOWED (figure 2 , right hand side)


Fig.3 SSO authentication domain


Apply the Access policy to the LTM VIP

of course the access policy will need to be applied to a VIP. because this will actually land the traffic on the F5 platform. I like to look at a VIP as some sort of socket that you can plug into the F5 so it can apply smarts.
Below is  a screenshot of part of the Virtual Server configuration in LTM, here the previously configured Access Profile "SSO_Portal" is assigned to the VIP



Access Policy Reporting.

In order to troubleshoot user not being able to log into your application for some reason, the access policy reporting page on the BIG-IP is a good resource for trying to figure out why. Son on your BIG-IP got to Access Policy > Reports >View Reports. As can be seen  in figure 5, my login with user ID "mink" failed



Figure 5 -Denied access
Please note that these reports are run per partition, so run the report for the partition, your VIP is running on. To view the details on how the access policy flow is applied against the login attempt; click on session ID details.





Thursday, 7 June 2018

Troubleshoot TLS using wireshark

Because you cant be a good network engineer if you do not know how to drive wireshark, i decided to put a post up on how to capture and analyse TLS negotiation.  For this purposes, I used www.cnn.com.  Before you do the capture, its good to do an nslookup for the domain so you can filter out relevant traffic (yes wireshark calls it 'ssl'). But really you can just use the public IP address on your BIG-IP F5 is that is what you want to analyse.  so hit your website, using https. Once pulled up, stop the capture.

Figure 1 - filter on ssl
So put a display filter in using 'ssl' as the syntax (sure if you are real smart you could have already used ssl as the capture filter).You might now have multiple TLS sessions t multiple destination, so the output needs to be more granular even. Choose the IP address you are interested in 151.101.81.67 in this case (which is the IP address used by some wanky cloud provider that cnn uses). so let us follow a particular stream:

Fig.2 -Follow SSL Stream

Following the ssl stream will give you a clear picture of the whole TLS hand shake and exchange of public keys, cert up to the exchange of symmetric key used for further encryption (through for instance AES 256).

the first thing that always happens when connecting using https is the client (your browser) announcing its cipher capabilities, it basically tells the server you are connecting to what security algorithms you are capable of. This is shown in the screen shot below

Fig.3 Client Hello

This is a client Hello, using Chrome v 67, as you can see only Elliptic Curve Diffie Helman predominately. It is also interesting to see that the client attempts TLSv1.2. In the opposite direction a server hello is sent to the client:

Fig. 4 Server Hello
Basically the server has decided it will use the securest possible cipher set. in this case ECDH, AES128 and Sha256. This is why it is important to define cipher suites on your webserver/F5 so security cant be forced by the client into using lower security ciphers such as DES or 3DES. by simply removing it from the capability of the server.

So the next thing that would happen, is the server issuing its certificate. As can be seen in figure 5

Fig. 5 -server issuing certificate to client

In Figure 5 you can see the common name of the cert. and the CA (global Sign) and a stack of subject alternative names. After that the cert finalizes the Hello phase with a Hello done.  in short:


Figure 6-  Hello summary

the next thing that happens is the exchange of "change cipher specs". essentially this is where the negotiation of symmetric session encryption keys takes place that will be used for further encryption of traffic (for instance by means of AES). as can be seen in Figure 6, this happens straight after the server Hello done.

Ofcourse the symmetric encryption keys cannot be exchanged without being encrypted themselves. so in order to hide them from a man in the middle attach, Diffie Helman comes into play. So If i drill into the client key exchange packet, I can see in our example that Elliptic Curve Diffie Helman is being used:

Fig. 7- ECDHE Elliptic curve Diffie Helman


As you can see, all of this TLS exchange is aimed to provide confidentiality and integrity. The actuall exchange of the X509 cert. provides the authentication portion of this.

Namaste





Monday, 19 March 2018

IPSEC Site to site VPN 101


Little post on IPSEC, also a good recap for myself. I will outline the components used in IPSEC when setting up a site  to site VPN for instance. I dont really want to drill down too much into the details of each protocol. This post is more around the components needed and steps/tips to trouble shoot.

IPSEC VPN is described in RFC 4301.

IPSEC is not a protocol, its is more similar to an architecture, that contains a number of protocols (mainly isakmp, AH and ESP)

IPSEC comprises of the following main elements:
  • IKE/IKEv2: which is used to negotiate tunnel parameters. These parameters are: (H.A.G.L.E)
    • Hashing for data integrity (md5/sha)
    • Authentication (certs or preshared key (PSK))
    • Group (Diffie-Hellman group)
    • Lifetime (how long will the tunnel be up for (seconds)
    • Encryption for data confidentiality (AES, 3DES, AES-256)
  • AH which is more or less become obsolete because of it inability to deal with NAT
  • ESP Encapsulation for encryption and authentication.

In order to have a fully functional site to site VPN, there are 2 types of SA's (Security Association) that need to be established:

  1. ISAKMP SA's (Phase 1), bidirectional SA, used as a management channel, to exchange keys between the peers for instance (similar to the B-channel on a BRI)
  2. IPSEC SA's (Phase 2), these are unidirectional, so you will need 2 IPSEC SA's. This happens once Phase 1 is successful. These IPSEC SA's are used to define how the end user data is protected, using transform sets
So for a functional IPSEC tunnel, a total of 3 SA's are required. These two types of SA's are also referred to as Phase 1 and Phase 2. Here is a visualization of this:






ESP (encapsulating Security Payload) and SPI

Once the SA's have been established, ESP does the hard work of protecting the traffic across the tunnel. ESP uses IP as its Layer 3 protocol and puts itself at layer 4. So if you were to Wireshark capture Tunneled traffic, you would not see a TCP port, but an ESP header containing an SPI (security Perimeter Index), a sequence number, followed by an encrypted payload.  

SPI are a 32bit random number that is associated with an IPSEC sa. As soon as a VPN endpoint receives an ESP encapsulated packet with a certain SPI, it knows exactly what transform set to apply to decrypt and integrity check the payload. If your firewall/router has multiple site to site IPSEC VPNs, you will have a multitude of SPI.

If you issue a sh crypto ipsec sa on a firewall or router, this will show you the associated SPI's. for example:



fw01/pri/act# sh cry ipsec sa
    <output omitted>
    inbound esp sas:
      spi: 0xE11468F9 (3776211193)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373768/1686)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0x859B5920 (2241550624)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373506/1686)
         IV size: 8 bytes
As you can see there are 2 IPSEC SA's one for inbound, one for outbound, each with their own SPI, on the remote end these values will be opposite of course.

You can also clearly see the applied transform sets of each SA, using ESP with Triple DES encryption and HMAC-MD5 for message authentication and integrity.

Remember every SA can have a different transform set, although this is not recommended.


Diagnostics on Cisco devices

Of course, when will you be most likely to set up a site to site VPN? Correct, when talking into some 3rd party systems, or when some 3rd party needs to talk into some of your systems.  What sort of Forewall/VPN concentrator does this party have? Really could be anything, Juniper, Palo alto, Sonic. I have had my fair share of pain getting VPN's set up inter vendor. And before you blame the other guy for not sending you the right transform set, make damn sure that you are right. So I think a few hints and tips could make a lot of difference.

There are really two commands available that should be your best friend when diagnosis IPSEC VPN issues:

  • sh crypto isakmp sa
  • sh crypto ipsec sa


fw01/pri/act# show crypto isakmp sa  detail
IKEv1 SAs:
   Active SA: 5
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 5
1   IKE Peer: 214.20.7.16
    Type    : L2L             Role    : responder
    Rekey   : no              State   : MM_ACTIVE
    Encrypt : 3des            Hash    : MD5
    Auth    : preshared       Lifetime: 28800
    Lifetime Remaining: 16894

As you can see above, there is your 'HAGLE' (hash, authentication,Group (well sort of), Lifetime, Encryption). What is important above is that the ISAKMP SA is established  (MM_ACTIVE). If you do not see your ISAKMP SA established, go no further, trouble shoot Phase1 first. Other states are:

MM_NO_STATE (typically cause by connectivity issue with the peer), MM_KEY_EXCH (could mean PSK mismatch), MM_SA_SETUP (peers agree on isakmp sa and will continue the process of negotiation).


If your Phase1 SA is not established, you will need to run debug commands to see what transform set are being attempted and what the remote end is sending you. for this you can use:

  • debug crypto isakmp
  • debug crypto isakmp error
  • debug crypto isakmp ha
Before you do this, you might want to consider, using conditional debugging, i.e. only capture debug information related to the failing VPN tunnel/peer. This because you might be running a large number of tunnels which would result in large amount of debug information.  To enable conditional crypto debugging:

debug crypto condition <cond-type> <cond-value>

as a condition value, you could choose the peer IP address for instance. To reset the condition use: debug crypto condition reset

Now the next test phase 2, if phase 1 is established, use the show cypto ipsec sa command. You would get something similar to the output below:

fw01/pri/act# sh crypto ipsec sa peer 214.20.187.17
peer address: 214.20.187.17
    Crypto map tag: outside_map, seq num: 2, local addr: 229.198.80.10
      access-list Internet_cryptomap_1 extended permit ip 192.168.71.0                   255.255.255.0 192.168.171.0 255.255.255.0
      local ident (addr/mask/prot/port): (192.168.71.0255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.171.0/255.255.255.0/0/0)
      current_peer: 214.20.187.17
      #pkts encaps: 359869, #pkts encrypt: 358126, #pkts digest: 358126
      #pkts decaps: 280949, #pkts decrypt: 279563, #pkts verify: 279563
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 359869, #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
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0
     local crypto endpt.: 229.198.80.10/0, remote crypto endpt.: 214.20.187.17/0
      path mtu 1500, ipsec overhead 58(36), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: 67EA5A7C
      current inbound spi : 08278FA3
    inbound esp sas:
      spi: 0x08278FA3 (136810403)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373709/1407)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0x67EA5A7C (1743411836)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373391/1407)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

The SA will show you H.A.G.L.E for both inbound and outbound SA's. It will also show you what traffic is protected by the VPN Tunnel. 

Good luck and namaste!!