What is Service?

What is Service?

  January 17, 2016    Raj

---

Read More

EZVPN between ASAs

EZVPN between ASAs

  January 15, 2016    Raj

---

Server:
===========
Server configuration will be like RAVPN configuration.

Phase 1 policy
Phase 2 policy
Create a pool
Create Split access list (Extended)
Create group policy
Create a tunnel group and call-in the group policy

In the group policy attributes, put this additional command:
nem enable

Create dynamic map and then call the dynamic map in crypto map
Enable crypto map on interface.

Client end configuration:
===================
vpnclient server "ip add of server ASA"
vpnclient mode network-extentention-mode
vpnclient vpngroup <tunnel group name that we have created on other ASA> 
password <Password that we have created as pre-shared key in our tunnel group on server ASA>
vpnclient username <a username that we have created on server ASA> password <password for that user>
client nem-st-autoconnect
vpnclient enable


Debugs::

Debug cry isa 200

Read More

Could not connect to server : Anyconnect

Could not connect to server : Anyconnect

  January 13, 2016    Raj

---

Back once again!

This time its my Any-connect. It gives me an error the moment I hit Connect :
"Could not connect to server. Please verify Internet connectivity and server address"

I am using any-connect 3. 1.13015. When I try to connect I get an immediate error message as shown above.

Debugs were saying :
Not calling vpn_remove_uauth: not IPv4!
webvpn_svc_np_tear_down: no IPv6 ACL

Luckily I had  Any-connect 4.2 installed on one of my machine and when I tested it from that machine it works fine.
I then figured out that Any-connect 3.x supports only TLSv1 and not 1.1 or 1.2, so I thought of verifying that: sh run all ssl

sh run all ssl
ssl server-version tlsv1.2
ssl client-version tlsv1.1
ssl cipher default custom "DES-CBC3-SHA:AES128-SHA:AES256-SHA"
ssl cipher tlsv1 custom "DES-CBC3-SHA:AES128-SHA:AES256-SHA"
ssl cipher tlsv1.1 medium
 
What did I do to fix this issue ?
conf t
 ssl client-version tlsv1
 

Read More

Replay check failed on Cisco Router with IPsec

Replay check failed on Cisco Router with IPsec

  January 13, 2016    Raj

---

Hello Again!!!

You are absolutely right, I am back with another issue with VPN :(

So this time, I have a router and have VTI tunnel setup on it. I don't know how it all started but I now see some logs on my router :

%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
        connection id=3625, sequence number=1281790

So I started to figure out what does this message mean?

Replay Attack: A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. In a replay attack someone records legitimate communications and repeats them in order to impersonate a valid user, and to disrupt or cause negative impact for legitimate connections.

 Replay Check Failure: IPSec provides anti-replay protection against an attacker who duplicates encrypted packets with the assignment of a monotonically increasing sequence number to each encrypted packet. The receiving IPSec endpoint keeps track of which packets it has already processed on the basis of these numbers with the use of a sliding window of all acceptable sequence numbers. Currently, the default anti-replay window size in Cisco IOS implementation is 64 packets.

How the incoming IPSec traffic on the receiving tunnel endpoint will be processed with anti-replay enabled?

 

1. When a packet is received, if the sequence number falls within the window and was not previously received, the packet is accepted, and marked as received before it is sent to integrity verification.
2. If the sequence number falls within the window and was previously received, the packet is dropped, and the replay counter is incremented. (In this case a replay check failure occurs, and the router displays an error message similar to this: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed)
3. If the sequence number is greater than the highest sequence number in the window, the packet is accepted, and marked as received. The sliding window is then moved to the right.
4. If the sequence number is less than the lowest sequence in the window, the packet is dropped, and the replay counter is incremented. (In this case a replay check failure occurs, and the router displays an error message similar to this: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed)

I have referred this doc here:

http://www.cisco.com/c/en/us/support/docs/ip/internet-key-exchange-ike/116858-problem-replay-00.html#anc2



If the window size is small (which it is by default 64) then the packet gets dropped due to a replay failure (it is not really an attack).
In such scenarios, increase the size of the replay window in order to ensure that such delays are accounted for and prevent legitimate packets from being dropped. By default, the window size is fairly small (window size of 64). If you increase the size, it does not greatly increase the risk of an attack.

Use show crypto ipsec sa peer ip-address platform command in order to verify the hardware anti-replay window size.
 
How can I change the Window size?

1. Change the window size globally : Configure IPsec Anti-Replay Window: Expanding and Disabling globally (so that it affects all SAs that are created— except for those that are specifically overridden on a per-crypto map basis)
crypto ipsec security-association replay window-size 512

2. Configuring IPsec Anti-Replay Window: Expanding and Disabling
on a Crypto Map 

crypto map Test 10 ipsec-isakmp
set security-association replay window-size 512

 

  

 

 

Read More

Ipsec on router (with HSRP failover) doesn't work after failover

Ipsec on router (with HSRP failover) doesn't work after failover

  January 07, 2016    Raj

---

This made me really scratch my head!

Here I am first trying to put a picture of the scenario:

This looks cool, whats the problem ?

Well, the problem is I have R1 and R2 running as HSRP peers. I have SLA monitoring going on to even check Internet connectivity, if Internet connectivity goes down, it will failover.

R1 and R2 both have a tunnel with R3. Under normal circumstances both R1 and R2 show the tunnel is UP and Active and I can reach the remote end subnets from both R1 and R2 when sourced it from inside interface.

Lets say there is some ongoing traffic over the tunnel, for some reason R1 fails and Failover occurs. R2 becomes the active router now and VPN traffic works fine as well.

Lets say there is no ongoing traffic over the tunnel and for some reason R1 fails and Failover occurs.
R2 becomes active router now. Now if we try to initiate the traffic for the tunnel it won't work, you wait as long as you want, it just won't work. (Clearing the session was the only thing that will make it work : clear crypto session)

ON R2:
==========
So when I further investigated, found that "sh cry ipsec sa peer 3.3.3.3" shows me encaps increasing but no decaps.

It starts making some sense now. So we are doing encaps and sending to peer , but peer is not sending it back to us. WHY ?

Let's take a look at the R3:
=====================
"Sh cry isa sa" on R3 shows that the tunnel is still UP with R1 and there are Ipsec as well. And its doing encap for peer 1.1.1.1 which is no longer alive, but this router R3 doesn't know that.

Now the question comes, why doesn't R3 know R1 has gone down?

DPD : Dead peer Detection

On R3 : sh run | in keepalive
crypto isakmp keepalive 30 5

Router supports two kind of keep-alives : 1. On-Demand DPD and 2. Periodic

This document really helped me to understand these two different keep alives :
https://supportforums.cisco.com/document/32546/dead-peer-detection

DPD is disabled by default on Cisco routers. The default mode is "on-demand" if not specified.

Here is how did I fix it:
==================
Changed the keepalive mode to periodic:
conf t
crypto isakmp keepalive 30 5 periodic

Voila!

Thanks to periodic keep-alive feature.

Read More