NDES, is the name for what we used to call MSCEP, which was an ‘add-on’ for the Server 2003 family of servers. In Server 2008 it was renamed to NDES. It is a role service that runs on a Certificate Services Server, and is used to create a registration authority (RA) that can issue certificates from your PKI infrastructure to network devices, i.e. Routers, Firewalls and Switches.
Solution
Installing Network Device Enrollment Service
I’m assuming you already have an Active Directory Certificate Services Server setup, if not you can deploy that and add in NDES at the same time.
1. Either: Launch Server Manager > Manage > Add Roles and Features > Below Active Directory Certificate Services select Network Device Enrollment Service.
2. Or: From within PowerShell run the following command;
1. Create a domain user (below I’ve called it SVC_NDES) > Add that user to the IIS_IUSRS group on the CA server.
2. From within Server Manager launch the post deployment configuration wizard.
3. Next.
4. Select Network Device Enrollment Service, (if not already selected).
5. Change the account details, to the service account you created above.
6. Enter the details that will be used to enroll the RA certificate.
7. Accept the defaults > Next.
8. Configure.
9. Close.
10. Launch the Certificate Authority management console > Certificate Templates > Right Click > Manage.
11. Open the properties of the ‘IPSec (Offline request)’ certificate > Security Tab > Make sure the account you created (above) has the ‘Enroll’ permission.
NDES Disable Password Requirement.
I’ve read a few blogs and articles that say;
“There is no way for Cisco devices to supply the required password to enroll with NDES/MSCEP, so you need to disable the requirement for a password.”
This is NOT TRUE, however the whole point of issuing certificates via your PKI infrastructure, is that it can scale dramatically. If you are creating passwords and embedding those passwords in all your enrollments, it can get a little unwieldy. So it may be sensible to remove the password requirement.
Update: 22/10/21: You may also need to recycle the SCEP application pool in IIS (on the Certificate Services Server)
From IIS Manager > CA > Application Pools, SCEP. > From the right hand panel > Advanced Settings. > Set Load User Profile to ‘True‘ > OK.
Again in the right panel > Recycle > From IIS Manager > Sites > Default Web Site. > From the right panel, click Restart.
Below you can see the difference, with the password requirement enforced, and without.
2. Restart the Certificate Services Service;
[box] net stop certsvc net start certsvc [/box]
NDES More Password Options and Renewing Certificates
If you do want the more secure option of using passwords, but don’t want to ad a new password every time you have a new enrollment, you can specify that the password does not expire after the default 60 minutes, in fact it never expires. This is handy if you want to renew certificates without generating new passwords. To do that carry out the following procedure;
[box] HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Cryptography > MSCEP[/box]
Create a new 32 bit DWORD value called ‘DisableRenewalSubjectNameMatch’ Set the value to 1 (one).
3. If (as above), you are running NDES under a service account, ensure that account has full control of the MSCEP key. (Again don’t forget to restart the Certificate Server service.)
IIS Query String Problem
You may find that with the default IIS settings you may encounter some problems. This is because (by default) IIS will only accept a Query String that’s less than 2048 characters long. If that happens you may see the following errors;
Request URL Too Long
HTTP Error 414. The request URL is too long.
HTTP Error 404.15 – Not Found
The request filtering module is configured to deny a request where the query string is too long.
I was debugging a VPN tunnel today. (From a Fortigate to a Cisco ASAv). I was messing around with the encryption and hashing, when the tunnel fell over. Phase 1 was establishing fine but not Phase 2 (IPSEC).
I’ve got better skills on the ASA, so that’s where I was debugging;
[box]
IPSEC: Received a PFKey message from IKE
IPSEC: Parsing PFKey GETSPI message
IPSEC: Creating IPsec SA
IPSEC: Getting the inbound SPI
IPSEC DEBUG: Inbound SA (SPI 0x00000000) state change from inactive to embryonic
IPSEC: New embryonic SA created @ 0x00007fc98613ea60,
SCB: 0x85567700,
Direction: inbound
SPI : 0x3B5A332E
Session ID: 0x00004000
VPIF num : 0x00000002
Tunnel type: l2l
Protocol : esp
Lifetime : 240 seconds
IPSEC: Received a PFKey message from IKE
IPSEC DEBUG: Received a DELETE PFKey message from IKE for an inbound SA (SPI 0x3B5A332E)
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) destroy started, state embryonic
IPSEC: Destroy current inbound SPI: 0x3B5A332E
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) free started, state embryonic
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) state change from embryonic to dead
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) free completed
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) destroy completed
[/box]
Solution
Google that error and you get some posts about NAT, that we’re not applicable to me. I took a look on the Fortigate and the only clue there was;
sa=0 There is a mismatch between selectors (or no traffic is being initiated). sa=1 IPsec SA is matching and there is traffic between the selectors. sa=2 Only seen during IPsec SA rekey
So I went back to basics and checked the Phase 2 on BOTH, firstly the Fortigate;
For the uninitiated: GCM Protocols DON’T require a hashing algorithm, (that’s why you can’t see SHA or MD5 on there), they disappear when a GCM protocol is selected.
Then on the Cisco ASA;
[box]
Cisco-ASA(config-ipsec-proposal)# show run crypto ipsec
crypto ipsec ikev2 ipsec-proposal FORTIGATE
protocol esp encryption aes-gmac-256
protocol esp integrity null <--Note: This can say anything it gets ignored!
THE ANSWER IS STARING YOU/ME IN THE FACE. I just didn’t realise yet, I changed the phase 2 protocols to DES/MD5 and the tunnel came up, I walked up through the protocols and options and discovered what I’d done wrong.
Root Cause: The ASA is set to use AES-GMAC-256 that’s a DIFFERENT PROTOCOL to the AES256GCMconfigured on the Fortigate! The ASA should be set to AES-GCM-256! (So the Phase 2 proposals didn’t match).
I was assisting a colleague to setup some AnyConnect for a client this afternoon, when all of a sudden I was met with this;
VPN
Logon denied, unauthorised connection mechanism, contact your administrator
Solution
This was a confusing one, I replicated the problem on my own test firewall. All I had done was change the AAA method from LOCAL to LDAP? It took me a while to figure out what was going on?
The reason why this is happening is because the GROUP POLICY your AnyConnect PROFILE is using does not have SSL enabled. (This makes no sense as it was working with LOCAL authentication, but this is how I fixed it).
You will be either using a specific group policy or the DfltGrpPolicy
[box]
IF USING THE DEFAULT GROUP POLICY
Petes-ASA(config)# group-policy DfltGrpPolicy attributes
Petes-ASA(config-group-policy)# vpn-tunnel-protocol ssl-client ssl-clientless
IF USING A SPECIFIC GROUP POLICY (Remember to include any, that already exist! e.g. l2tp-ipsec)
Petes-ASA(config)# group-policy PNL-GP-ANYCONNECT-ACCESS attributes
Petes-ASA(config-group-policy)# vpn-tunnel-protocol ssl-client ssl-clientless l2tp-ipsec
Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.
If you have a spare/available public IP address you can statically map that IP address to one of your network hosts, (i.e. for a mail server, or a web server, that needs public access).
This is commonly referred to as a ‘Static NAT’, or a ‘One to One translation’. Where all traffic destined for public address A, is sent to private address X.
Note: This solution is for firewalls running versions above version 8.3. If you are unsure what version you are running use the following article.
In the following example I will statically NAT a public IP address of 81.81.81.82 to a private IP address behind the ASA of 172.16.254.1. Finally I will allow traffic to it, (in this example I will allow TCP Port 80 HTTP/WWW traffic as if this is a web server).
Create a Static NAT and allow web traffic via ASDM
3. Give the ‘object’ a name (I usually prefix them with obj-{name}) > It’s a Host > Type in it’s PRIVATE IP address > Tick the NAT section (press the drop-down if its hidden) > Static > Enter it’s PUBLICIP address > Advanced > Source = Inside > Destination > Outside > Protocol TCP. Note: You could set this to IP, but I’m going to allow HTTP with an ACL in a minute, so leave it on TCP > OK > OK > Apply.
4. Now navigate to Firewall > Access Rule > Add > Add Access Rule.
5. Interface = outside > Permit > Source = any > Destination = PRIVATEIP of the host > Service > Press the ‘more’ button > Locate TCP/HTTP > OK > OK > Apply.
6. Then save your work with a File > Save Running Configuration to Flash.
Create a Static NAT and allow web traffic via Command Line
2. Log In > Go to enable mode > Go to configure terminal mode.
[box]
User Access Verification
Password:*******
Type help or '?' for a list of available commands.
PetesASA> enable
Password: *******
PetesASA# conf t
PetesASA(config)
[/box]
3. First I’m going to allow the traffic to the host (Note: after version 8.3 we allow traffic to the private (per-translated IP address). This assumes you don’t have an inbound access list if you are unsure execute a “show run access-group” and if you have one applied substitute that name for the word ‘inbound’.
Warning before carrying out applying the ‘access-group’ command, see the following article;
This procedure was done on Cisco ASA (post) version 8.4, so it uses all the newer NAT commands. I’m also going to use self signed certificates so you will see this error when you attempt to connect.
Solution
1. The first job is to go get the AnyConnect client package(s), download them from Cisco, (with a current support agreement). Then copy them into the firewall via TFTP. If you are unsure how to do that see the following article.
2. Create a ‘pool’ of IP addresses that the ASA will allocate to the remote clients, also create a network object that covers that pool of addresses we will use later.
[box]
Petes-ASA(config)# ip local pool ANYCONNECT-POOL 192.168.100.1-192.168.100.254 mask 255.255.255.0
Petes-ASA(config)# object network OBJ-ANYCONNECT-SUBNET
Petes-ASA(config-network-object)# subnet 192.168.100.0 255.255.255.0
[/box]
3. Enable webvpn, set the package to the one you uploaded earlier, then turn on AnyConnect.
[box]
Petes-ASA(config)# webvpn
Petes-ASA(config-webvpn)# enable outside
INFO: WebVPN and DTLS are enabled on 'outside'.
Petes-ASA(config-webvpn)# tunnel-group-list enable
Petes-ASA(config-webvpn)# anyconnect image disk0:/anyconnect-win-4.8.02042-webdeploy-k9.pkg 1
Petes-ASA(config-webvpn)# anyconnect enable
[/box]
4. I’m going to create a LOCAL username and password, I suggest you do the same, then once you have proved it’s working OK, you can. change the authentication method, (see links below). I’m also going to create an ACL that we will use for split-tunneling in a minute.
Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.
You want a secure IPSECVPN between two sites using IKEv2.
Note: If the device you are connecting to does not support IKEv2 (i.e. it’s not a Cisco ASA, or it’s running code older than 8.4) then you need to go to the older version of this article;
Before you start – you need to ask yourself “Do I already have any IPSEC VPN’s configured on this firewall?” Because if it’s not already been done, you need to enable ISAKMP IKEv2 on the outside interface. To ascertain whether yours is on or off, issue a “show run crypto ” command and check the results, if you do NOT see “crypto ikev2 enable outside” then you need to issue that command.
[box]
PetesASA# show run crypto
crypto ikev2 enable outside << Mines already enabled and its IKE version 2
crypto ikev2 policy 10 encryption aes-256
integrity sha256
group 19
prf sha256
lifetime seconds 86400
crypto ikev2 enable outside
[/box]
1. I’m going to create access control lists next, one to tell the ASA what is “Interesting traffic”, that’s traffic that it needs to encrypt.
So below I’m saying “Don’t NAT Traffic from the network behind the ASA (10.254.254.0) that’s going to network behind the VPN device at the other end of the tunnel (172.16.254.0).
2. Now I’m going to create a “Tunnel Group” to tell the firewall it’s a site to site VPN tunnel “l2l”, and create a shared secret that will need to be entered at the OTHER end of the site to site VPN Tunnel. I also set a keep alive value.
Note: Ensure the Tunnel Group Name is the IP address of the firewall/device that the other end of the VPN Tunnel is terminating on.
3. Now we need to create a policy that will setup how “Phase 1” of the VPN tunnel will be established. It sets the encryption type (AES-256), the hashing/integrity algorithm (SHA-256), The Diffie Hellman group exchange version, and the Level of PRF (Pseudo Random Function). Finally it sets the timeout before phase 1 needs to be re-established. It sets the timeout value to 86400 seconds (That’s 1440 Minutes – or 24 hours if your still confused 🙂 ).
5. Finally we need to create a “Cryptomap”, this is the ‘thing’ that fires up the tunnel, when the ACL INTERESTING TRAFFIC is used, it also defines the transform set for “Phase 2” of the VPN Tunnel, that will also use 3DES and SHA and PFS. And last of all we apply that Cryptomap to the outside interface.
5. Don’t forget to save your hard work with a “write mem” command.
[box]
PetesASA(config)#
PetesASA(config)# write mem
Building configuration...
Cryptochecksum: 5c8dfc45 ee6496db 8731d2d5 fa945425
8695 bytes copied in 3.670 secs (2898 bytes/sec)
[OK]
PetesASA(config)#
[/box]
6. Simply configure the other end as a “Mirror Image” of this one.
ASA 5500 Site to Site IKEv2 VPN Copy and Paste Config
Note: This uses AES-256 and SHA-256. It also assumes your outside interface is called ‘outside’. Check! I’ve seen them called Outside (capital O), wan, and WAN.
With the newest version of AnyConnect (4.7) there’s an added feature called ‘Management VPN’. It’s there, so that if you have remote users who don’t VPN in very often, then you may struggle to mange them, e.g. put software updates, AV updates, SCCM packages etc. down to them.
Before version 4.7 you could configure ‘Automatically Connect’, or ‘Start before Logon’ to handle these problems, well now you can use Management VPN. What it does is, it automatically connects (using the computer certificate to authenticate), and it automatically disconnects when a remote user brings up a normalAnyConnect VPN user connection. When they disconnect again, the Management VPN (after a few seconds) will re-establish again.
As usual the Cisco documentation is not brilliant! So I built it out in EVE-NG to test. Here’s the Lab I used;
I’ve got a Windows 2012 R2 Server that’s doing Certificate services and DHCP, I’ve also got an external (Windows 7) client with AnyConnect 4.7 installed.
Solution
My first task was to setup normal user AnyConnect, which I secured with certificates, (user certificates), I sent the certificates out using auto-enrollment. Also while I had my certificate hat on, I generated a certificate for the outside of the ASA as well. (I didn’t bother setting up NDES I just imported the CA Certificate eon the ASA).
Note: If you already have working AnyConnect, then you can skip this section.
In addition, (much as I prefer to work at CLI, you need to go into the ASDM to do the following). Create a new connection profile and associate it with the group policy we just created (above).
Add to the ‘Server list‘ the URL you specified (above).
To avoid being prompted for which certificate to use, untick ‘Disable Automatic Certificate Selection’ (Yes the name makes no sense to me either!) Save the profile.
Then make sure the VPN works as expected.
Setup AnyConnect Management VPN
Prerequisites
Your ASA needs to be running newer than version 9, and your ASDM image needs to be 7.10(1) or newer.
You need to have the Anyconnect client software (4.7 or newer!)
I’ve already mentioned certificates, but you will need to have the CA certificate from the CA that’s generating your COMPUTER certificates installed and trusted, mine’s already there, as I’m already authenticating my USER certificates with it.
Add another Tunnel-Group and Group-Policy for your Management-VPN, I’ll drop back to CLI to do that (to keep things neat and tidy).
Add a new connection profile, set the type to ‘AnyConnect Management VPN Profile’, and link it to the Group-Policy for your AnyConnect USER connections.
As before add an entry to the server list with the same URL you specified in the Management VPN tunnel group.
Add an Automatic VPN policy, to connect whenever you are on a network that is NOT your corporate network. Here if a client sees my server, on the same network, or gets my domain name via DHCP it WONT connect.
Additional Settings Required for Management VPN
Edit the Group-Policy you are using for Management VPN > AnyConnect Client > Custom Attributes > Add > Create an Attribute called: ManagementTunnelAllAllowed.
Create a value for it called true/true.
In the ‘AnyConnect Client‘ section, ENABLE ‘Client Bypass Protocol’.
Your client will need to connect at least once to get the new settings, once they have when they disconnect the Management VPn will establish.
As soon as the user tunnel comes up, the Management VPN tunnel will drop.
Related Articles, References, Credits, or External Links
A few weeks ago this was asked on one of the forums I post in. For a long time the ASA didn’t support DHCP relay then finally in version 9 it was added. The question was, can I provide DHCP relay but have the DHCP server on another site (connected via VPN).
Well I wasn’t sure, so I put it on the mental back burner, until I got my EVE-NG server rebuilt. Below I knocked up a simple two site setup, then connected them via IPSEC VPN. The DHCP client is Windows 7, and the DHCP Server is 2012 R2.
Solution
To be honest it could not be simpler! Obviously the site to site VPN needs to be up or it wont work! The config is simply added to the ASA on the DHCP Client side, (or the left hand one in the example above).
The one reason I prefer Cisco over Microsoft is they rarely change things, you learn how to do something and it’s learned. This is the second time have had to write this article purely because the Azure UI has changed!
Virtual Network Gateway Options
With VPN’s into Azure you connect to a Virtual Network Gateway, of which there are TWO types Policy Based, and Route Based. This article will deal with Policy Based, for the more modern Route based option, see the following link;
These came first, essentially they work like this, “If traffic is destined for remote network (x) then send the traffic ‘encrypted’ to local security gateway (y).” Note: Where Local Security Gateway is a firewall at YOUR site, NOT in Azure! This is the way traditionally VPNs have been done in Cisco ASA, In Cisco Firewall speak it’s the same as “If traffic matches the interesting traffic ACL, then send the traffic ‘encrypted’ to the IP address specified in the crypto map”.
Advantages:
Can be used on older Cisco Firewalls (ASA 5505, 5510, 5520, 5550, 5585).
Can be used on newer Cisco Firewalls (ASA 5506-x, 5508-X, 5512-x, 5515-x, 5516-x, 5525-X, 5545-X, 5555-x, 5585-X)
Can be used with Cisco ASA OS (pre 8.4) IKEv1 only,
Disadvantages
Can only be used for ONE connection from your Azure Subnet to your local subnet. Note: You could ‘hairpin’ multiple sites over this one tunnel, but that’s not ideal.
Route Based
These were typically used with routers, because routers use Virtual Tunnel Interfaces to terminate VPN tunnels, that way traffic can be routed down various different tunnels based on a destination, (which can be looked up in a routing table). But Cisco ASA now supports Virtual Tunnels Interfaces (After version 9.7(1))
Advantages
Can be used for VPNs to multiple sites.
Disadvantages
Requires Cisco ASA OS 9.7(1) So no ASA 5505, 5510, 5520, 5550, 5585 firewalls can use this.
Configure Azure for ‘Policy Based’ IPSec Site to Site VPN
You may already have Resource Groups and Virtual Networks setup, if so you can skip the first few steps.
Sign int0 Azure > All Services > Resource Groups > Create Resource Group > Give your Resource Group a name, and select a location > Create.
OK, if you’re used to networking this can be a little confusing, we are going to create a virtual network, and in it we are going to put a virtual subnet, (yes I know this is odd, bear with me!) It’s the ‘Subnet Name‘and ‘address range‘ that things will actually connect to, (10.0.0.0/24).
All Services > Virtual Networks > Create Virtual Network > Give the Virtual Network a name, a subnet, select your resource group > Then create a Subnet, give it a name and a subnet > Create.
To further confuse all the network engineers, we now need to add another subnet, this one will be used by the ‘gateway’. If you are a ‘networking type’ it’s part of the virtual network, but is more specific than the subnet you already created.
With your virtual network selected >Subnets > +Gateway Subnet.
You can’t change the name, (you could before, then it wouldn’t work, which was strange, but I suppose it’s fixed now) > put in another network that’s part of the Virtual-Network, but does not overlap with the subnet you created in the previous step > OK.
All Services > Virtual Network Gateways > Create Virtual Network Gateway > Name it > Policy Based (Note: This will change the SKU to Basic) > Create New Public IP > Give it a Name > Create.
Note: This will take a while, go and put the kettle on! Make sure all running tasks and deployments are complete before continuing.
You can do the next two steps together, but I prefer to do then separately, or it will error if the first one does not complete!
Now you need to create a Local Security Gateway. (To represent your Cisco ASA). All Services > Local Security Gateway > Create Local Security Gateway > Name it > Supply the public IP > Supply the Subnet(s) ‘behind’ the ASA > Select your Resource Group > Create.
Finally create the VPN > Select your Virtual Network Gateway > Connections > Add.
Give the tunnel a name > Site-to-Site IPSec > Select your Local Network Gateway (ASA) > Create a pre-shared-key (you will need this for the ASA config!) > Select your Resource Group > OK.
Configure the Cisco ASA for ‘Policy Based’ Azure VPN
I read somewhere that the ASA had to be at 9.1? That’s not true, I’ve done it with a firewall running 8.3, and I’ve read blog posts from people who have done this with a Cisco PIX (running version 6). But the firewall does have to support AES encryption (‘show version’ will tell you). There are some subtle differences in the code which I will point out below, but essentially you should be running an OS newer than 8.4 for this config to work. (As I’ve said I’ll address 8.4, and 8.3 (or earlier) below).
Connect to the ASA and create an object group for your local subnet, and the subnet that you are using in Azure, (Called Azure-SN above).
[box]
Type help or '?' for a list of available commands.
Petes-ASA> enable
Password: ********
Petes-ASA# configure terminal
Petes-ASA(config)# object-group network OBJ-AZURE-SN
Petes-ASA(config-network-object-group)# description Azure Subnet
Petes-ASA(config-network-object-group)# network-object 10.0.0.0 255.255.255.0
Petes-ASA(config-network-object-group)# exit
Petes-ASA(config)# object-group network OBJ-LOCAL-SN
Petes-ASA(config-network-object-group)# description Local Subnet
Petes-ASA(config-network-object-group)# network-object 192.168.100.0 255.255.255.0
Petes-ASA(config-network-object-group)# exit
[/box]
Then create an access-list, this will alert the firewall that there is some ‘interesting traffic’ that needs to be encrypted (we will call this ACL later on, from the crypto-map). Then create a NAT rule that stops traffic that’s going over the VPN tunnel from being NATTED.
Our VPN is going to use a pre-shared-key, (you created in Azure above). It will use AES-256 for encryption, SHA for hashing, and Diffie Hellman version 2 for key exchange. So we need to have a matching ‘phase 1’ (that’s ISAKMP) policy.
Enable ISAKMP (version 1) on the outside interface, then configure the parameters that will be used in ‘phase 2’ (that’s IPSEC). Note: If your outside interface is called something else like Outside or WAN substitute that!
Next, you need a tunnel-group, in this case the only job of the tunnel group has is to keep the pre-shared-key (PSK) to the peer you specify. Which in this case is the Azure Gateway.
The thing that ties it all together is the crypto map. Here I’ve called it “AZURE-CRYPTO-MAP”, WARNING if you already have a crypto map, use the name of that one, or all your existing VPNS will stop working, (show run crypto will tell you). This is because, you can only have one crypto map applied to an interface, but you can have many crypto map numbers, i.e crypto map {NAME} {NUMBER} {COMMAND}. And each VPN tunnel has its own number.
There are a couple of extra commands you will need, these are sysops commands. Their purpose set things globally, and are generally hidden from the config, (i.e ‘show run’ wont show them). These are recommendations from Azure. The first one drops the maximum segment size to 1350.The second command keeps the TCP session information even if the VPN tunnel drops.
To test we usually use ‘ping’, the problem with that is, if you are using Windows Servers they will have their Windows firewall on by default, which blocks pings, (bear this in mind when testing). Also your ASA needs to be setup to allow pings, (try pinging 8.8.8.8 that usually responds), if yours doesn’t then configure your ASA to allow ping traffic.
As mentioned above, you might want to turn the firewalls off to test.
On the Cisco ASA you can see the tunnel is established at Phase 1 (ISAKMP)
[box]
Petes-ASA# show cry isa
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: 40.113.16.195
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
[/box]
If yours says something else, (or nothing at all) then phase 1 has not established. You need to Troubleshoot phase 1 of the VPN tunnel. (Probably: Public IP is wrong, or pre-shared-key (shared secret) has been mistyped, check these first).
Assuming that’s working, your next test is to make sure that Phase 2 has established. You should see packets encrypting and decrypting.
[box]
Petes-ASA(config)# show cry ipsec sa
interface: outside
Crypto map tag: AZURE-CRYPTO-MAP, seq num: 1, local addr: 128.65.98.43
access-list ACL-AZURE-VPN extended permit ip 192.168.100.0 255.255.255.0 10.0.0.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)
current_peer: 40.113.16.195
#pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
#pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 2, #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.: 128.65.98.43/0, remote crypto endpt.: 40.113.16.195/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 97624DA8
current inbound spi : D7705547
inbound esp sas:
spi: 0xD7705547 (3614463303)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 335872, crypto-map: AZURE-CRYPTO-MAP
sa timing: remaining key lifetime (kB/sec): (97199999/3556)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x0000000F
outbound esp sas:
spi: 0x97624DA8 (2539802024)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 335872, crypto-map: AZURE-CRYPTO-MAP
sa timing: remaining key lifetime (kB/sec): (97199999/3556)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Petes-ASA(config)#
[/box] If phase 2 did not connect, then you need to troubleshoot phase 2 of the VPN tunnel. (Probably: Transform set is wrong, or routing being the ASA is not working).
Azure to Cisco VPN ‘Policy Based’ IKEv1 Complete Code Snippets to Copy and Paste
(Change the values highlighted in red)WARNING: re-read the warning about crypto map names above! [box]
You want to wipe the firewall’s config and revert to the factory settings (passwords blank – management or inside set to 192.168.1.1 and DHCP enabled, with all other settings wiped).
Solution
1. Connect to the ASA via the console Cable. CLICK HERE
2. log in and go to configure terminal mode.
3. Execute the following command “config factory-default”
4. Press the space bar a few times to execute the commands.
5. When you get back to command prompt Execute the following command “reload save-config noconfirm” (Or on a Cisco PIX, write mem {enter} > reload {enter}{enter}).
6. The Firewall will reboot, (set to factory settings).
Procedure carried out on a Cisco ASA 5508-X (Running version 9)
Procedure carried out on a Cisco PIX 515E (Running version 8)
Note: Now the management interface, (if you have one) will be set to lease DHCP addresses. If you don’t have a management interface, (i.e. you have an ASA 5505, or an older PIX,) then the inside interface will lease DHP addresses instead. The outside interface will be set to obtain its IP address via DHCP.
Related Articles, References, Credits, or External Links
