VPN IPSEC Replay errors

 Sometimes you see erros like this on a Cisco router.

 %IOSXE-3-PLATFORM: R0/0: cpp_cp: QFP:0.0 Thread:000 TS:0002185922034562192 %IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay error, DP Handle 13, src_addr <A.A.A.A>, dest_addr <B.B.B.B>, SPI 0x3caaaeb7

 

If you know that these packets are legitimate packets from your VPN endpoints, it means that some mechanism changes the order of the packets and these causes packet drops on the receiving end. 

In order to overcome this one can apply the following command in order to increase the IPSec receive window.

crypto ipsec security-association replay window-size 1024

Cisco Reference:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dplane/configuration/15-mt/sec-ipsec-data-plane-15-mt-book/sec-ipsec-antireplay.pdf

IKEv1 VPN messages

All Credits for this go to Jack Rhysider and his excellent work at https://www.tunnelsup.com/ and https://darknetdiaries.com/

ISAKMP (IKE Phase 1) Negotiations States

The MM_WAIT_MSG state can be an excellent clue into why a tunnel is not forming. If your firewall is hanging at a specific state review this graph below to find where along the path the VPN is failing.

ASA ISAKMP STATES

Graph source: tunnelsup.com

These are the possible ISAKMP negotiation states on an ASA firewall. ISAKMP stands for: The Internet Security Association and Key Management Protocol

• MM_WAIT_MSG2 Initiator Initial DH public key sent to responder. Awaiting initial contact reply from other side. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. If stuck here it usually means the other end is not responding. This could be due to no route to the far end or the far end does not have ISAKMP enabled on the outside or the far end is down.

• MM_WAIT_MSG3 Receiver Receiver is sending back its IKE policy to the initiator. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. Hang ups here may also be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.

• MM_WAIT_MSG4 Initiator Initiator is sending the Pre-Shared-Key hash to its peer. Initiator sends a hash of its PSK. Initiator will stay at MSG4 until it gets a PSK back from its peer. If the receiver is missing a tunnel group or PSK the initiator will stay at MM_WAIT_MSG4

• MM_WAIT_MSG5 Receiver Receiver is sending its PSK hash to its peer. Receiver does not yet check if PSK hashes match. If receiver has a tunnel-group and PSK configured for this peer it will send the PSK hash to the peer. If PSKs don’t match, receiver will stay at MM_WAIT_MSG5. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off.

• MM_WAIT_MSG6 Initiator Initiator checks if PSK hashes match. If PSK keys match, Initiator becomes MM_ACTIVE and lets receiver know of match. If PSK doesn’t match, initiator stays at MM_WAIT_MSG6. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off. However, if the state goes to MSG6 then the ISAKMP gets reset that means phase 1 finished but phase 2 failed. Check that IPSEC settings match in phase 2 to get the tunnel to stay at MM_ACTIVE.

• AM_ACTIVE / MM_ACTIVE The ISAKMP negotiations are complete. Phase 1 has successfully completed.

PIX ISAKMP STATES

• MM_NO_STATE

ISAKMP SA has been created but nothing else has happened yet.

• MM_SA_SETUP

The peers have agreed on parameters for the ISAKMP SA.

• MM_KEY_EXCH

The peers have exchanged Diffie-Hellman public keys and have generated a shared secret. The I SAKMP SA remains unauthenticated.

• MM_KEY_AUTH

The ISAKMP SA has been authenticated. If the router initiated this exchange, this state trans itions immediately to QM_IDLE and a Quick mode exchange begins.

• AG_NO_STATE

The ISAKMP SA has been created but nothing else has happened yet.

• AG_INIT_EXCH

The peers have done the first exchange in Aggressive mode but the SA is not authenticated.

• AG_AUTH

The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to QM_IDLE and a Quick mode exchange begins.

• QM_IDLE

The ISAKMP negotiations are complete. Phase 1 successfully completed. It remains authenticated with its peer and may be used for subsequent Quick mode exchanges.

What is the difference between MM and AM?

Main mode vs Aggressive mode. Here is a image taken from Cisco’s website to show the difference.

As you can see the Main mode is the same as the flowchart at the top of the page. Aggressive mode only uses 4 steps to establish the tunnel.

Troubleshooting ISAKMP Or Phase 1 VPN connections

When troubleshooting VPNs, a very common problem is phase 1 not establishing correctly. Here’s a quick checksheet to make sure you have the configuration correct.

• Verify ISAKMP parameters match exactly.
• Verify pre-shared-keys match exactly.
• Check that each side has a route to the peer address that you are trying to form a tunnel with.
• Verify ISAKMP is enabled on the outside interfaces.
• Is ESP traffic permitted in through the outside interface?
• Is UDP port 500 open on the outside ACL?
• Some situations require that UDP port 4500 is open for the outside.

Firepower VPN Filter via Flexconfig

The following information provided as is with not guaranties  that it works and support will not be provided! Test in a lab before deploying in production.

If you don't know what you're doing hire a trained engineer!



VPN filter for Site to site VPN is not supported from GUI in Firepower. see CSCvj86972


You have to create a new policy and attach it to tunnel-group.
Create your VPN configuration and save it.

Assuming that Remote VPN peer IP = 10.10.10.10

Do the following:


1) Under objects create an extended access list to be used as VPN Filter with the name VPN_FILTER, this ACL is your actual VPN filter and will be attached to your VPN tunnel.



2) On the same page under Flexconfig-> Text Object Create a new text object for your tunnel group IP as Single and assign a value of 10.10.10.10 (replace with your peer IP)


3) Under Flexconfig Object create a new object with Deployment: "Everytime" and Type: "Append"


4) Insert a new policy object -> Extended ACL object and choose your created ACL

5) Insert a new policy object -> Text Object and choose your previously created "TUNNEL_GROUP"


6) Copy and paste the following to flex config window
    Note: adjust any vpn attributes here except the vpn-filter value

group-policy VPN_FILTER_POL internal
group-policy VPN_FILTER_POL attributes
 vpn-idle-timeout 30
 vpn-idle-timeout alert-interval 1
 vpn-session-timeout none
 vpn-session-timeout alert-interval 1
 vpn-filter value $VPN_ACL
 vpn-tunnel-protocol ikev1 ikev2

tunnel-group $VPN_TUNNEL general-attributes
 default-group-policy VPN_FILTER_POL

Your config should look like this






7) Now attached the configured policy to you flex config for the specific device under Devices -> FlexConfig (If you dont have a policy create a new one, assign it to the proper device and insert the FLEX_VPN_FILTER found in user defined policies).


8) Save and deploy!

FTD RA VPN with Microsoft NPS server

 ORIGINAL POST FROM Jatin Katyal  (Thanks)

Introduction
Steps needs to be followed on the Microsoft Radius server to configure group-lock and tunnel-group-lock
Configuration Steps

    Go to Remote Access Policies.
    Go to the remote access policy/network policy, make a right click on the policy and click on the "Properties"
    Click on Edit Profile.
    Click on Advanced Tab settings and add ( For IAS)
    Click on settings (For NPS)
    Scroll down to "Vendor-Specific" Radius attribute.
    Select it, from scroll down use custom and click on Add.
    Make sure Attribute Number is set to 26.
    Click on Add.
    Enter Vendor Code: 3076.
    Select radio button : Yes. It confirms.
    Click on Configure Attributes.
    Vendor-Assigned attribute number: 25 (group-lock) and 085 (tunnel-group-lock)
    Attribute format: String.
    Attribute Value: <group-policy-name> or <tunnel-group name>
    Apply.

In order to troubleshoot any issues look at event-viewer logs on Radius server.
Configure NPS Event Logging
NPS Events and Event Viewer

Finally, this document with ASA AAA configuration documentation could be useful too:
http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/general/asa_91_general_config/aaa_radius.pdf

Anyconnect DNS issues on VPN

If you 're facing troubles with clients connecting to VPN and can't resolve DNS please check the following

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuz27826/?rfs=qvred

In short
Anyconnect creates a static route on the client for the DHCP server. if your DHCP server also servers as DNS etc. this breaks the DNS resolution for your client.
Apply the following as workaround

group-policy DfltGrpPolicy attributes
  webvpn
     anyconnect-custom-attr no-dhcp-server-route
     anyconnect-custom-data no-dhcp-server-route no-dhcp-server-route true

group-policy <XXX> attributes 
  anyconnect-custom no-dhcp-server-route value no-dhcp-server-route

Fortinet SSL VPN Windows 10

Recently I had to connect to a remote VPN session using Fortinet SSL VPN.
I installed the simple SSL VPN via Microsoft store on Windows 10 and I run into an issue because the firewall was using an untrusted certificate.
There are no relative option to change in the settings of the client, so searching the Internet I found the following solution that worked:
When you declare your server name use the following URL,

https://<vpn.server.addresss>:443/realmname?ignore-certificate-errors=1


relative Fortinet forum thread:
https://forum.fortinet.com/tm.aspx?m=118768&mpage=3