At first I thought “Oh great, the syntax has changed, there’s another post to update“. But no, the command is correct. This is what what pointed me in the right direction.
[box]
Petes-ASA# show module
Mod Card Type Model Serial No.
---- -------------------------------------------- ------------------ -----------
1 ASA 5506-X with FirePOWER services, 8GE, AC, ASA5506 JAD1233AAAA
sfrUnsupportedUnsupported
Mod MAC Address Range Hw Version Fw Version Sw Version
---- --------------------------------- ------------ ------------ ---------------
1 6cb2.aede.0106 to 6cb2.aede.010f 2.0 1.1.8 9.10(1)11
Mod SSM Application Name Status SSM Application Version
---- ------------------------------ ---------------- --------------------------
Mod Status Data Plane Status Compatibility
---- ------------------ --------------------- -------------
1 Up Sys Not Applicable
[/box]
Solution
FirePOWER SFR IS NO LONGER SUPPORTED ON ASA 5506-X and ASA5512-X
Cisco’s official wording from the 9.10 version release says;
“The ASA 5506-X series and 5512-X no longer support the ASA FirePOWER module in 9.10(1) and later due to memory constraints. You must remain on 9.9(x) or lower to continue using this module. “
So downgrade the OS, at time of writing the newest supported is 9.9(2).
Related Articles, References, Credits, or External Links
If you attempt to restore items from a backup of a server where the data was stored on a deduplicated volume, you may see the following error;
Copying data from deduplicated volumes requires that the console is installed on Windows Server 2012 R2 or later with the data duplication feature enabled.
Restoring files from deduplicated volumes requires that the mount server associated with the source backup repository uses Windows Server 2012 R2 or later with data deduplication feature enabled.
This tells me two things, firstly no one at Veeam can use a comma, and secondly we are missing a Windows feature.
Solution
Normally if you see posts for this, it will tell you to install the deduplication on the Veeam server, (because that fixed their problem). That worked because the mount server and the Veeam Backup and Replication management server were the same server. However if you are remote managing Veeam, then the mount server is the server you are running backup and replication management on. You need to bear this in mind, if you are managing Veeam from an OS that does not support Deduplication, then you may need to remote onto another server to perform the restore.
Open a PowerShell session, and execute the following commands; (That last one will reboot!)
After a colleague deployed Citrix for a customer the other day, they complained that they had a mac user that was getting certificate errors. They had a publicly signed wildcard certificate, but this user was still having problems.
After I heard a few “tell him to stop using a mac” comments, I said, “I’m using a MacBook here, would you like me to test it?” The URL opened fine in Safari, and the certificate looked good (all green), I was prompted to install the Citrix receiver, and was presented with a session to open, when I did so, I got this;
You have chosen not to trust {Certificate-Name} the issuer of the servers security certificate.
Solution
Head over to https://www.sslchecker.com and put your Citrix URL in and check it, I found this. So I downloaded the two certificates it said I was missing.
Note: For someone who works with certificates, this makes no sense, (as I got to the portal without an error). I had to trust the root CA, and its intermediate CA, (what’s being called a Chain Cert below). But I thought I’d play along to see what happened.
‘Double Click’ each downloaded certificate, then choose ‘Add’, (repeat for each certificate in the chain).
Close any open Citrix receiver sessions, restart you browser, and try again.
Related Articles, References, Credits, or External Links
If you want to get hold of the actual drivers from VMware tools, e.g. to have them in a machine that you will be deploying into VMware ESX/Workstation etc, then this is how to do it.
Solution
I’m using WinSCP to connect to one of my ESXi servers, (it’s free, and just works!) From the root directory locate vminages and open that.
Tools-isoimages, (this might seem long-winded, but if you keep an eye on the path, you will see we are actually going to a Linux symlink directory).
Here’s the VMtools ISO files, I want the Windows one. (Note: theres a Windows (pre-vista) one, for older versions of Windows and a Linux one also). Simply use WinSCP to download it.
I’ve opened the ISO with 7-Zip, (again free and it just works!) You can simply mount the ISO and copy the files out if you wish.
Run the following commands, (if running from command line, you wont need the dot slash!);
[box]
cd {Your-Directory}
./Setup64.exe /a /p {Your-Directory}
[/box]
When prompted select your directory, (again!)
Navigate to {Your-Directory}\VMware\VMware Tools\VMware\Drivers, here are all the divers extracted.
Related Articles, References, Credits, or External Links
Recently I’ve looked a lot at converting VMware resources to either Hyper-V, or Azure. But what if you want to take a Microsoft machine (or workload) and run it in VMware?
Well the easiest way is to use some freeware, “StarWind V2V Image Converter”. These days I’m dubious about any piece of freeware, because it’s either a) Not Free when you actually want to use it in anger, b) Full of adware and nastiness, c) Just a vehicle to get your email address to send you marketing and junk.
Well you do need to supply an email address to get it but, other than suggesting I might want to take a look at their free VSAN software, they have left me alone (ThanQ).
Solution
Launch the software, and browse to the folder containing your .vhd to .vhdx file. (Note: You can connect directly to a Hypervisor if you wish).
Again I’m going to output to a local file, (faster) but as above, you can output to a Hypervisor. (I’ll simply just SCP the image into VMware and create a VM with it, when I’m finished).
Select your output type, basically they are; VMware Workstation (thick or thin), Stream optimised (.OVA), or the one we want, ESXi.
Note: You can also output to RAW file or GQCOW2 (Handy for if you run EVE-NG and what to upload a server/workstation into it!)
Time for a coffee! Hopefully this is what you will see.
Related Articles, References, Credits, or External Links
This covers the, (more modern) Route based VPN to a Cisco ASA that’s using a VTI (Virtual Tunnel Interface).
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 Route Based, for the older Policy Based option, see the following link;
These were typically used with routers, because routers used 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). 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.
Policy Based
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.
Configure Azure for ‘Route 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 > Route Based > 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’m using 9.9(2)36, VTIs are supported on 9.7, but as with all new things, I’d assume that was buggy and go for 9.8 or above.
To Avoid Emails:
What IP do I put on my Tunnel interface / Where do I get that from? Use whatever you want, NO it does not have to be on the same network as something in Azure, in fact I’m using an APIPA 169.254.x.x. address, and it works fine, (think of it like a local loopback address, though do note the difference to the last octet in the route statement!)
Where’s the Crypto Map? It doesn’t need one.
Do I need to do NAT Exemption? NO (Unless you were hair pinning a traditional VPN from another ASA into this tunnel, or an AnyConnect client VPN session.)
There’s No ACL to Allow the Traffic, or an Interesting Traffic ACL? That’s correct, you don’t need any, (unless you apply an access-list to the the tunnel interface).
There are a couple of extra commands you will need, these are sysops commands. Their purpose is to 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.
The last thing to do, is tell the firewall to ‘route’ the traffic for Azure though the VTI. Note: The last octet in the destination IP is different from the VTI IP!
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 ASA the first thing to make sure is that the Tunnel Interface is up!
[box]
Petes-ASA# show interface tunnel 1
Interface Tunnel1 "AZURE-VTI01", is up, line protocol is up
Hardware is Virtual Tunnel MAC address N/A, MTU 1500
IP address 169.254.225.1, subnet mask 255.255.255.252
Tunnel Interface Information:
Source interface: outside IP address: 126.63.123.43
Destination IP address: 40.115.49.202
Mode: ipsec ipv4 IPsec profile: AZURE-PROFILE
[/box]
You can also use the following;
[box]
Petes-ASA# show crypto ikev2 sa
IKEv2 SAs:
Session-id:2, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
268975001 123.123.12.1/500 40.115.49.202/500 READY INITIATOR
Encr: AES-CBC, keysize: 256, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 28800/814 sec
Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535
remote selector 0.0.0.0/0 - 255.255.255.255/65535
ESP spi in/out: 0x7b10e41a/0xfcb4576a
[/box]
Thats Phase 1 connected, you will also need to check Phase 2
[box]
Petes-ASA(config)# show crypto ipsec sa
interface: AZURE-VTI01
Crypto map tag: __vti-crypto-map-11-0-1, seq num: 65280, local addr: 82.21.58.194
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: 40.115.49.202
#pkts encaps: 32, #pkts encrypt: 32, #pkts digest: 32
#pkts decaps: 33, #pkts decrypt: 33, #pkts verify: 33
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 32, #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.: 123.123.123/500, remote crypto endpt.: 40.115.49.202/500
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: DA3A1C28
current inbound spi : B562D9C6
inbound esp sas:
spi: 0xB562D9C6 (3043154374)
SA State: active
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, VTI, }
slot: 0, conn_id: 11, crypto-map: __vti-crypto-map-11-0-1
sa timing: remaining key lifetime (kB/sec): (3962877/28755)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x000003FF 0xFFFFFFFF
outbound esp sas:
spi: 0xDA3A1C28 (3661241384)
SA State: active
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, VTI, }
slot: 0, conn_id: 11, crypto-map: __vti-crypto-map-11-0-1
sa timing: remaining key lifetime (kB/sec): (4193277/28755)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Petes-ASA(config)#
[/box]
Related Articles, References, Credits, or External Links
Back in PART ONE, we setup our Azure Site Replication Server, now we create a “Replication Policy“, and perform a test failover. In addition to the pre-requisites we needed before to perform the following steps, we will also require you to create a “Storage Account” in your Azure Subscription.
Solution
Locate the Replication Vault we already created > SiteRecovery > Prepare Infrastructure > Set your requirements > OK.
I have not run the deployment planner, this is a PowerShell tool that will give you some stats on what your replication performance will be like, with your VMs and internet connection. I am simply putting “I will run it later: > OK.
Select your onsite Configuration Server > Select your vCenter/Hyper-V server > OK.
Note: I was worried about the “vCenter discovery status is NotConnected Click here to read more” Notice, but everything worked OK?
Select your Storage Account > and LAN/Subnet > OK.
Azure Create an ASR Replication Policy
Create and Associate.
Give the policy a name (accept the defaults) > OK.
Once you are “all-green” > OK.
Select Step 1: Replicate Application > Select your replication preferences > OK.
Enter the Azure ‘target VM‘ settings > OK.
Select the VM(s) that you want to replicate > OK.
Make sure an account with the correct access is chosen > OK.
OK.
Enable Replication.
Obviously, this may take some time, I left it running and checked the following day.
Replication Vault > Overview > Sire Recovery > Wait until all your replicated items are “Healthy”.
Azure SRS Perform Test Failover
Replication Vault > Replicated Items > Select your replicated machine > Test Failover.
Select your latest replication > and destination network > OK.
Wait till we are “all-green” In practicality you need to wait a while longer, you will see, (if you go to boot login and watch the screen), the VM will boot up install new hardware items, it will be a while before you see the login screen.
At this point if you have failed over into a ‘production LAN” you will be able to connect to the failed over machine.
Warning: The failed over machine will have a DHCP address, if you have failed over a domain controller, or asset that needs a static IP, then you will need to manually rectify that, when moving it into production.
In my case I just want to give my machine a Public IP so I can connect to to via RDP (to Test)
Azure: How To Assign a Public IP to a VM
All Services > Public IP addresses > Create Public IP Addresses > Give it a name > Choose your Resource Group > OK.
On your VM > Networking > Select the NIC.
IP Configuration > Select the configuration.
Select “Enabled” > Assign the public IP object > Save.
You can now connect to your VM.
You can now, perform a “Cleanup Test Failover” and perform a live failover.
Related Articles, References, Credits, or External Links
ASR (Azure Site Recovery) is primarily used to provide a ‘failover’ environment to be used in a disaster or major outage scenario. Essentially you deploy an Azure Site Recovery Configuration Server in your environment, then in your Azure Portal you create and configure a failover vault.
OK, but we are talking about migrations, well we can use exactly the same procedure to migrate from on premises virtual machines, (or physical machines). We setup replication, then failover to Azure, then simply DON’T fail back 🙂
Networking Considerations
We are dealing with getting your machines replicated to Azure, and then failing over to them. You will also need to consider how you will connect the them ‘Post Migration’ This is usually via VPN from your location(s) into Azure. (If you have Cisco networking equipment you are in luck, see the links at the bottom of the page for further help). I’m making the assumption that you have already got this covered.
While the initial ‘work’ is carried out on your own site, there are a few things that will need to already exist in Azure before you start, you will need a ‘Resource Group‘.
I’m creating a Virtual LAN, for Failover only, theres nothing to stop you using your existing Azure networking but you will need a ‘Virtual Network‘, and a ‘Subnet‘, here I’m using 192.168.0.0/16 and 192.168.100.0/24 respectively.
You will also need to create a ‘Recovery Service Vault‘
Deploying Microsoft Azure Site Recovery Configuration Server
As you can see I’m running VMware vCenter (6.7), you can also download an image for Hyper-V. Download the ‘appliance’ as an OVA image and deploy it into your VMware infrastructure.
What you will get is a Windows 2016 server (on 180 day eval) as soon as it starts, it will ask you to set the LOCAL administrator password, then reboot, once rebooted, log in and this wizard will launch. Give the server a name, and let it connect to the internet.
Authenticate to your Azure Subscription.
Give the server a static IP, (or it will complain later)
As usual, Microsoft assumes everyone’s American, change the Time Zone and ENSURE the time is set correctly.
Configure Microsoft Azure Site Recovery Configuration Server
Launch the desktop shortcut.
Select your subscription > Resource Group and Recovery Services Vault. Then proceed to installing MySQL. (How times have changed eh?)
Continue > It will perform some checks, if any of them fail, then rectify the problem, and re-run the tests.
Continue > Enter your vCenter, (or ESXi if you have stand alone hosts) details.
Add > Ensure the correct details are listed, and any other vCenters/ESXi hosts as appropriate.
Add in some credentials, either local admin credentials for the servers, or some domain admin credentials, (currently) it does not like the UPN username format so use DOMAIN\Username format > Add > Continue.
Don’t know if I hit a bug here, but selecting “No” didn’t do anything, i.e. I could not progress, so I clicked “Yes” and it let me “Finalize Configuration“, (once you change your locale to non American, I wish it would spell things correctly!)
