“Hi thanks for your video. I have two win 2012 DC DHCP on a failover/load balance config and want to migrate to new Win 2022 VMs. What’s the exact procedure? If it’s a single VM it’s easy but I’m not sure about if it’s on a failover setup.”
Well migrating the domain controller element I’ve covered before.
But what if you have your DHCP servers deployed in HA – be that Load Balanced, or Hot Standby (failover)?
How do you migrate DHCP to a new platform then ?
Solution: Migrate DHCP HA
There was very little information I could find on this subject, you can drop down to one DHCP server and perform a simple migration to Server 2022 then setup HA again of course, but I think the following solution is much more elegant, and there’s NO DOWNTIME to worry about.
Windows Migrate DHCP HA – Step 1 Remove HA
In my example I have some 2012 R2 Servers running DHCP (it does not matter if they are in Load balancing mode or Hot Standby, the approach is the same just the commands will vary.
I’ve got two new Windows Server 2022 servers updated and added to the domain ready to take on the DHCP HA roles.
The first thing I’m going to do is remove the failover partnership. You can do this on either of the legacy DHCP servers but the one you run the command on will be the DHCP server that remains operational after you remove the partnership (in this case 2012-dhcp-1.dingdong.com).
Use the following syntax, the first command gets the failover groups name, you then delete that failover group.
Windows Migrate DHCP Failover – Step 3 Create HA to Server 2022
We will now create a failover partnership to the first of our two new Windows Servers.
Firstly we need to install the DHCP role on BOTH of our new Windows Servers, register them in AD, and change a registry key to stop server manager bugging you about running the DHCP setup wizard.
Windows Migrate DHCP Failover – Step 4 Break Replication
If you are replicating many scopes then wait a while for the servers to be ‘in sync’, the next step seems counter intuitive, as you are going to delete the very thing you have just created, but this procedure is carried out on the NEW DHCP SERVER NOT THE LEGACY ONE, (so the DHCP scope is removed from the last remaining legacy DHCP server.)
On the first new DHCP server execute the following commands. (same commands you used above in step 1).
Windows Migrate DHCP Failover – Step 6 Deploy new DHCP HA Configuration
Lastly, we setup a new failover relationship that is setup the same as the one we setup in step 3, but this time with the last remaining new DHCP server.
You normally have to go to Server Manager and run the configuration wizard, but as were are already in PowerShell lets do that here 🙂 (That’s three commands if the last one wraps!)
On the original, (already working,) DHCP server, right click the scope you want to replicate > Configure Failover. Note: If you have multiple scopes you can right click at the IPv4 or IPv6 level, and run the same wizard to replicate multiple scopes at once).
Next.
Browse to, and select the target (new DHCP server) > Next.
Select Load Balancing or Hot Standby (as required) > Enter a shared secret password > Next.
Review the Settings and click Finish.
Hopefully you should see the following.
Configure DHCP Failover via PowerShell
To do the same from PowerShell.
PowerShell DHCP Load Balancing
Note: Where DC-01 is the source DHCP server and PNL-MGMT is the new one.
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!)
You want to deploy 2 Cisco ASA 55xx Series firewalls in an Active/Standby failover configuration.
Solution
Assumptions.
Hardware on both ASA firewalls is identical.
The correct license’s for failover are installed on both firewalls.
The same software versions are installed on both firewalls.
You have your PRIMARY firewall set up and running correctly (Everything works!).
In this example the firewalls were ASA5510’s and all interfaces were being used, so the Management port was used as the “Failover Link” (That needs a security plus license!).
This Link will use a crossover cable (Only available after version 7.0(2) before that you had to use a switch – I think!).
Also I’m using the same link for LAN Based failover (heartbeat) AND Stateful replication.
IP Addresses
Each interface will need its existing IP address, and an address to use whilst in “Standby”. In this example I will use the following,
4. Set up the failover LAN interface (In config mode!).
[box]
PetesASA(config)#
PetesASA(config)# failover lan interface FAIL-OVER Gigabitethernet1/7
INFO: Non-failover interface config is cleared on Management0/0 and its sub-interfaces
PetesASA(config)#
ciscoasa(config)#
ciscoasa(config)# failover lan interface FAIL-OVER Gigabitethernet1/7
INFO: Non-failover interface config is cleared on Management0/0 and its sub-interfaces
ciscoasa(config)#
[/box]
YES: that’s the same as the primary firewall there WON’T be a conflict).
Detected an Active mate
Beginning configuration replication from mate.
[/box]
19. When is says that is has ended replication On the secondary firewall, issue a “show failover” (Note: the hostname will have changed to the one on the primary firewall).
[box]
PetesASA(config)#
PetesASA(config)# show failover
Failover On
Failover unit Secondary
Failover LAN Interface: failover Management0/0 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 250 maximum
Version: Ours 7.2(2), Mate 7.0(5)
Last Failover at: 14:49:43 UTC May 4 2007
This host: Secondary - Standby Ready
Active time: 0 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.2(2)) status (Up Sys)
Interface Outside (123.123.123.124): Link Down (Waiting)
Interface DMZ1 (192.168.1.254): Link Down (Waiting)
Interface DMZ2 (192.168.2.254): Link Down (Waiting)
Interface Inside (172.16.1.254): Link Down (Waiting)
slot 1: empty
Other host: Primary - Active
Active time: 514 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.0(5)) status (Up Sys)
Interface Outside (123.123.123.123): Link Down (Waiting)
Interface DMZ1 (192.168.1.1): Link Down (Waiting)
Interface DMZ2 (192.168.1.1): Link Down (Waiting)
Interface Inside (172.16.1.1): Link Down (Waiting)
slot 1: empty
[/box]
20. To double check go back to the PRIMARY firewall and issue the same command.
[box]
PetesASA(config)# show failover
Failover On
Failover unit Primary
Failover LAN Interface: failover Management0/0 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 15 seconds
Interface Policy 1
Monitored Interfaces 4 of 250 maximum
Version: Ours 7.0(5), Mate 7.2(2)
Last Failover at: 13:21:42 UTC May 4 2007
This host: Primary - Active
Active time: 616 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.0(5)) status (Up Sys)
slot 1: empty
Interface Outside (123.123.123.123): Link Down (Waiting)
Interface DMZ1 (192.168.1.1): Link Down (Waiting)
Interface DMZ2 (192.168.2.1): Link Down (Waiting)
Interface Inside (172.16.1.1): Link Down (Waiting)
Other host: Secondary - Standby Ready
Active time: 0 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.2(2)) status (Up Sys)
slot 1: empty
Interface Outside (123.123.123.124): Link Down (Waiting)
Interface DMZ1 (192.168.1.254): Link Down (Waiting)
Interface DMZ2 (192.168.2.254): Link Down (Waiting)
Interface Inside (172.16.1.254): Link Down (Waiting)
[/box]
21. The failover time out of the box is a bit pants, to nail it down a little, on the PRIMARY ASA
22. Save the config. (Note: config changed WILL be replicated to the standby firewall).
[box]
PetesASA(config)#
PetesASA(config)# write mem
Building configuration...
Cryptochecksum: 6650f6c9 09bbb5f0 0dafa0d1 8fc08aba
8756 bytes copied in 3.680 secs (2918 bytes/sec)
[OK]
PetesASA(config)#
[/box]
23. When done pull the power on ASA 1 to fail. With a constant ping running you usually will only lose 1 ping packet.
Failover Commands to Copy and Paste
Note: This assumes you have already added ‘standby’ IP addresses to all you interfaces and is using GigabitEthernet0/4 as the failover interface. Change the values in bold to match your requirements.
[box]
Primary Firewall Config
clear configure interface GigabitEthernet0/4
interface GigabitEthernet0/4
no shut
exit
!
failover lan interface failover GigabitEthernet0/4
failover interface ip failover 192.168.255.9 255.255.255.252 standby 192.168.255.10
failover lan key 666999
failover lan unit primary
failover
failover link failover GigabitEthernet0/4
!
failover poll 1 hol 3
failover poll interface 3
interface GigabitEthernet0/4
failover poll interface 3
exit
!
Standby Firewall Config
clear configure interface GigabitEthernet0/4
interface GigabitEthernet0/4
no shut
exit
!
failover lan interface failover GigabitEthernet0/4
failover interface ip failover 192.168.255.9 255.255.255.252 standby 192.168.255.10
failover lan key 666999
failover lan unit secondary
failover
failover link failover GigabitEthernet0/4
!
[/box]
Related Articles, References, Credits, or External Links
Thanks to Barry van Dijk for correcting up my syntax mistake 🙂
Usually when I’m asked to setup Active/Active I cringe, not because its difficult, its simply because people assume active/active is better than active/standby. I hear comments like ‘we have paid for both firewalls lets use them’, or ‘I want to sweat both assets’.
The only real practical use cases I can think of for Active /Active are;
You have a multi-tenancy environment and want to offer your tenants failover firewall capability.
You have multiple LAN subnets and what to split them though different firewalls.
What Active/Active Wont Give You
Load balancing: It’s a firewall! If you want load balancing buy a load balancer! People assume because both firewalls are passing traffic, they must load balance, they don’t, in fact they don’t even pass traffic from the same subnet.
VPNS: Yes theres no VPNs with Active Active. (This is 100% the case up to an including version 9.0, after version 9.0 they have stopped saying it’s not supported, but don’t say it’s supported).
Deploy Cisco ASA in Active/Active Failover
Here’s what Im going to setup;
For a more ‘logical’ view heres what is actually being setup;
1. Make sure the Licences are on the firewalls allow multiple contexts. and Active/Active, for 5510, 5512-X, and 5508-X that means Security Plus, for all other models a ‘base’ licence is required. (Note: This CANNOT be done on an ASA 5505 or 5506-X).
[box]
ciscoasa(config)# show version
Cisco Adaptive Security Appliance Software Version 8.4(2)
——OUTPUT REMOVED FOR THE SAKE OF BREVITY—
Failover : Active/Active perpetual
VPN-DES : Enabled perpetual
VPN-3DES-AES : Disabled perpetual
Security Contexts : 5 perpetual
GTP/GPRS : Disabled perpetual
——OUTPUT REMOVED FOR THE SAKE OF BREVITY—
Configuration last modified by enable_15 at 08:04:40.249 UTC Wed Oct 14 2015
ciscoasa(config)#
[/box]
2. Put the firewalls in Multiple context mode.
[box]
ciscoasa(config)# mode multiple
WARNING: This command will change the behavior of the device
WARNING: This command will initiate a Reboot
Proceed with change mode? [confirm]
Convert the system configuration? [confirm]
!
The old running configuration file will be written to flash
Converting the configuration - this may take several minutes for a large configuration
The admin context configuration will be written to flash
The new running configuration file was written to flash
Security context mode: multiple
[/box]
3. Let it reboot.
4. Make sure the firewall is in routed mode, and multiple context mode, repeat on the other firewall.
[box]
ciscoasa> enable
Password: *********
ciscoasa# show mode
Security context mode: multiple
ciscoasa# show firewall
Firewall mode: Router
ciscoasa#
[/box]
5. Once ASA1 is backup give it a sensible hostname, and ensure all the physical interfaces (and any sub interfaces) are NOT shutdown, and add then to the relevant VLAN (they are shut down by default).
6. Failover link NEEDS to be configured and used by the SYTEM Context, so its configured here. (Note: I’m using the same physical interface for LAN and Stateful failover information).
[box]
PHYSICAL-ASA(config)# failover lan unit primary
PHYSICAL-ASA(config)# failover lan interface FAILOVER GigabitEthernet2
INFO: Non-failover interface config is cleared on GigabitEthernet2 and its sub-interfaces
PHYSICAL-ASA(config)# failover link FAILOVER GigabitEthernet2
PHYSICAL-ASA(config)# failover interface ip FAILOVER 172.16.1.1 255.255.255.0 standby 172.16.1.2
PHYSICAL-ASA(config)#
[/box]
7. You can only have TWO failover groups (you can have many contexts, depending on the licence on your firewall).
PHYSICAL-ASA(config)# changeto context vASA1
PHYSICAL-ASA/vASA1(config)# interface outside_vASA 1
PHYSICAL-ASA/vASA1(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
PHYSICAL-ASA/vASA1(config-if)# ip address 123.123.123.123 255.255.255.0 standby 123.123.123.124
PHYSICAL-ASA/vASA1(config-if)# no shut
PHYSICAL-ASA/vASA1(config)# interface inside_vASA 1
PHYSICAL-ASA/vASA1(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default.
PHYSICAL-ASA/vASA1(config-if)# ip address 10.5.100.1 255.255.255.0 standby 10.5.200.2
PHYSICAL-ASA/vASA1(config-if)# no shut
PHYSICAL-ASA/vASA1(config-if)# exit
PHYSICAL-ASA/vASA1(config)# route outside 0.0.0.0 0.0.0.0 123.123.123.1
PHYSICAL-ASA/vASA1(config)# monitor-interface inside
PHYSICAL-ASA/vASA1(config)# monitor-interface outside
PHYSICAL-ASA/vASA1(config)# object network obj_any
PHYSICAL-ASA/vASA1(config-network-object)# subnet 0.0.0.0 0.0.0.0
PHYSICAL-ASA/vASA1(config-network-object)# nat (inside,outside) dynamic interface
PHYSICAL-ASA/vASA1(config-network-object)# exit
PHYSICAL-ASA/vASA1(config)# exit
PHYSICAL-ASA/vASA1#
[/box]
11. Now configure vASA2.
[box]
PHYSICAL-ASA/vASA1(config)# changeto context vASA2
PHYSICAL-ASA/vASA2(config)# interface inside_vASA 2
PHYSICAL-ASA/vASA2(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default.
PHYSICAL-ASA/vASA2(config-if)# ip address 10.6.200.1 255.255.255.0 standby 10.6.200.2
PHYSICAL-ASA/vASA2(config-if)# no shut
PHYSICAL-ASA/vASA2(config)# interface outside_vASA 2
PHYSICAL-ASA/vASA2(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
PHYSICAL-ASA/vASA2(config-if)# ip address 120.120.120.120 255.255.255.0 standby 120.120.120.122
PHYSICAL-ASA/vASA2(config-if)# exit
PHYSICAL-ASA/vASA2(config)# route outside 0.0.0.0 0.0.0.0 120.120.120.1
PHYSICAL-ASA/vASA2(config)# object network obj_any
PHYSICAL-ASA/vASA2(config-network-object)# subnet 0.0.0.0 0.0.0.0
PHYSICAL-ASA/vASA2(config-network-object)# nat (inside,outside) dynamic interface
PHYSICAL-ASA/vASA2(config-network-object)# exit
PHYSICAL-ASA/vASA2(config)#
[/box]
12. Go back the the System context and save ALL the changes.
[box]
PHYSICAL-ASA/vASA2(config)# changeto system
PHYSICAL-ASA(config)# wr mem all
Building configuration...
Saving context : system : (000/003 Contexts saved)
Cryptochecksum: e63d00e3 18224da1 be9d77c6 27c6e54d
2109 bytes copied in 0.300 secs
Saving context : admin : (001/003 Contexts saved)
Cryptochecksum: f2f07827 f2784851 89925ac1 86c1e96f
974 bytes copied in 0.330 secs
Saving context : vASA1 : (002/003 Contexts saved)
Cryptochecksum: 037e3a39 fe10e4d0 ff72d306 36fcf1ed
1930 bytes copied in 0.330 secs
Saving context : vASA2 : (003/003 Contexts saved)
Cryptochecksum: e9024f22 53ad6316 70f7ccad 4394c81c
1879 bytes copied in 0.230 secs
[OK]
PHYSICAL-ASA(config)#
[/box]
Note: Configuration on the main (physical) firewall is complete, the ‘failover’ configuration needs to now be setup on the second physical ASA.
13. On the ’Secondary’ Physical ASA.
[box]
ciscoasa# configure terminal
ciscoasa(config)# interface gigabitEthernet 0
ciscoasa(config-if)# no shut
ciscoasa(config-if)# interface gigabitEthernet 0.1
ciscoasa(config-subif)# no shut
ciscoasa(config-subif)# vlan 800
ciscoasa(config-subif)# interface gigabitEthernet 0.2
ciscoasa(config-subif)# no shut
ciscoasa(config-subif)# vlan 900
ciscoasa(config-subif)# interface gigabitEthernet 1
ciscoasa(config-if)# no shut
ciscoasa(config-if)# interface gigabitEthernet 1.1
ciscoasa(config-subif)# no shut
ciscoasa(config-subif)# vlan 100
ciscoasa(config-subif)# interface gigabitEthernet 1.2
ciscoasa(config-subif)# no shut
ciscoasa(config-subif)# vlan 200
ciscoasa(config-subif)# exit
ciscoasa(config)# failover lan unit secondary
ciscoasa(config)# failover lan interface FAILOVER GigabitEthernet2
INFO: Non-failover interface config is cleared on GigabitEthernet2 and its sub-interfaces
ciscoasa(config)# failover link FAILOVER GigabitEthernet2
ciscoasa(config)# failover interface ip FAILOVER 172.16.1.1 255.255.255.0 standby 172.16.1.2
ciscoasa(config)#
[/box]
14. Remember failover is off by default, and we have not switched it on, this needs to be done on both of the physical ASA’s (primary and secondary). Note: Make sure the ‘failover’ interface is NOT in a shut down state first!
[box]
Secondary
ciscoasa(config)# interface GigabitEthernet2
ciscoasa(config)# no shut
ciscoasa(config)# failover
ciscoasa(config)#
Primary
PHYSICAL-ASA(config)# int gigabitEthernet 2
PHYSICAL-ASA(config-if)# no shut
PHYSICAL-ASA(config)# failover
PHYSICAL-ASA(config)#
[/box]
Note: If building in GNS3 sometimes you need to put a switch in the middle of the ‘backup link’ or the firewalls don’t detect each other!
17. Top Tip: Remember that you need to make the changes on the active firewall context in the correct failover group. Change the firewall prompt to show you all this information.
[box]
PHYSICAL-ASA# conf t
PHYSICAL-ASA(config)# prompt hostname context priority state
PHYSICAL-ASA/pri/act(config)#
Note: Moral of the story is you need to be aware what physical firewall you are on (primary or secondary) what mode you are in (active or standby) and what context you are in (vASA1 or vASA2). So in this example to make a change to vASA2 you would need to go to Secondary/Standby/vASA2 to edit the active firewall, (confusing eh! That’s why I change the firewall prompt).
Now you will want to test things, probably by pinging, don’t forget ICMP is not enabled by default an you will need to enable it, (in each context).
[box]
vASA1 (as specified above), make sure it says ‘act’ on the end of the prompt.
PHYSICAL-ASA/pri/act(config)# changeto context vASA1
PHYSICAL-ASA/vASA1/pri/act(config)# policy-map global_policy
PHYSICAL-ASA/vASA1/pri/act(config-pmap)# class inspection_default
PHYSICAL-ASA/vASA1/pri/act(config-pmap-c)# inspect icmp
PHYSICAL-ASA/vASA1/pri/act(config-pmap-c)# exit
PHYSICAL-ASA/vASA1/pri/act(config-pmap)# exit
PHYSICAL-ASA/vASA1/pri/act(config)# exit
PHYSICAL-ASA/vASA1/pri/act#
vASA2 (as specified above), make sure it says ‘act’ on the end of the prompt.
PHYSICAL-ASA/sec/stby# changeto context vASA2
PHYSICAL-ASA/vASA2/sec/act# conf t
PHYSICAL-ASA/vASA2/sec/act(config)# policy-map global_policy
PHYSICAL-ASA/vASA2/sec/act(config-pmap)# class inspection_default
PHYSICAL-ASA/vASA2/sec/act(config-pmap-c)# inspect icmp
PHYSICAL-ASA/vASA2/sec/act(config-pmap-c)# exit
PHYSICAL-ASA/vASA2/sec/act(config-pmap)# exit
PHYSICAL-ASA/vASA2/sec/act(config)# exit
If you are used to setting up DNS records, then the BT Web Portal (btdomainmanager.com) can be a little confusing. I was stuck yesterday, luckily I had another client I could get to check their records for me.
Solution
In the example below I’ve got two IP addresses to which I want mail delivering to, 123.123.123.123 and 123.123.123.125, (yours may be on completely different ranges, that’s OK.)
In addition to the two MX records, I’ve also setup two A (host) records that point the host-names mail and mail2 to those two IP addresses.
Note: Most of you, will only have one IP address, and one host record to create.
Related Articles, References, Credits, or External Links
One great new feature of Server is bult in network ‘Teaming’. To do this normally takes some third party software, either form the server vendor (HP Teaming) or from the NIC manufacturer.
It utilises a new Windows feature called LBFO, this lets you both aggregate links, and have links available in the event of failover.
Note: NIC Teaming only supports up to 32 network cards.
Solution
1. Launch Server manager > All Servers > Select the server you ant to create a team on > Right Click > Configure NIC Teaming.
2. Select the NICs you want to add to the team > Right Click > Add to New Team.
3. Give the Team a name > OK.
Note: By default ‘Switch independent’ will be selected, this is probably what you want (see below) > OK.
Windows Server 2012 NIC Teaming Modes
Static Teaming: Requires configuration on the switch, which must be configured for IEEE 803.3ad (draft v1).
Switch Independent: Generally requires no switch configuration and can be connected to multiple switches.
LACP: Requires configuration on the switch, which must be configured for IEEE 802.1ax, and support LACP. Note: On a Cisco Catalyst this would be a port-channel, on an HP Networking switch this would be called an LACP trunk.
4. Now if you look under ‘Network Connections’ you will see a new one with the name you created.
5. Configure this new Teamed NIC, and simply treat it as a single network card.
Configure Teaming via PowerShell
To do the same as we did above use the following command;
[box]
New-NetLbfoTeam -Name TEAM -TeamMembers NIC1,NIC2,NIC3,NIC4 -TeamingMode SwitchIndependent
[/box]
Related Articles, References, Credits, or External Links
Setting up ‘Static NAT’ is the process of taking one of your ‘spare’ public IP addresses, and permanently mapping that public IP to a private IP address on your network.
In the example above I want to give my web sever which has an internal IP address of 192.168.1.10/24, the public IP address of 1.1.1.5/24. So if someone out on the Internet wants to view my website, they can browse to http://1.1.1.5 (or a URL that I’ve pointed to 1.1.1.5 like http://www.mywebsite.com). Then that traffic will be NATTED, on the firewall for me.
Solution
1. Create a rule-set from the ‘untrust’ zone. Then add a rule to that rule-set, that has a destination of 1.1.1.5/32, and finally set it to NAT that traffic to 192.168.1.10/32.
[box]login: root
Password: *******
— JUNOS 12.1X44-D30.4 built 2014-01-11 03:56:31 UTC
[edit]
root@FW-02# set security nat static rule-set UNTRUST-TO-TRUST from zone untrust
[edit]
root@FW-02# set security nat static rule-set UNTRUST-TO-TRUST rule NAT-RULE-1 match destination-address 1.1.1.5/32
[edit]
root@FW-02# set security nat static rule-set UNTRUST-TO-TRUST rule NAT-RULE-1 then static-nat prefix 192.168.1.10/32
[/box]
2. Set the firewall to proxy-arp (advertise your pubic IP address with is MAC address), then add the web server to the global address book.
Note: ge-0/0/0.0 is the physical address you are advertising the new IP address from, on firewalls in a failover cluster you would use the Reth address i.e. reth0.0
[edit]
root@FW-02# set security address-book global address WEB-SERVER 192.168.1.10/32
[/box]
3. Allow traffic OUT from the web server. Here I’m letting out all ports, if you wanted just web traffic then use the keyword junos-http (TCP Port 80 (http)).
[box]
[edit]
root@FW-02# set security policies from-zone trust to-zone untrust policy WEB-SERVER-OUT match source-address WEB-SERVER
[edit]
root@FW-02# set security policies from-zone trust to-zone untrust policy WEB-SERVER-OUT match destination-address any
[edit]
root@FW-02# set security policies from-zone trust to-zone untrust policy WEB-SERVER-OUT match application any
[edit]
root@FW-02# set security policies from-zone trust to-zone untrust policy WEB-SERVER-OUT then permit
[/box]
4. Then allow traffic IN to the web server, (here I’m locking it down to just http).
[box] [edit]
root@FW-02# set security policies from-zone untrust to-zone trust policy WEB-SERVER-IN match source-address any
[edit]
root@FW-02# set security policies from-zone untrust to-zone trust policy WEB-SERVER-IN match destination-address WEB-SERVER
[edit]
root@FW-02# set security policies from-zone untrust to-zone trust policy WEB-SERVER-IN match application junos-http
[edit]
root@FW-02# set security policies from-zone untrust to-zone trust policy WEB-SERVER-IN then permit
Juniper Allowing Traffic To Custom Ports And Applications
1. Although Juniper have a lot of built in ‘applications’ you can allow, what if you want to create your own? Below I’ll create a custom application for Remote Desktop Protocol (TCP port 3389).
[box] [edit]
root@FW-A# set applications application APP-RDP protocol tcp
[edit]
root@FW-A# set applications application APP-RDP destination-port 3389
[/box]
2. You could now use this application in your security policies e.g.
2. Load factory defaults, at this point you cannot commit/save the configuration unless you set a password, so do that next.
[box]
[edit]
PeteL@Petes-SRX# set system root-authentication plain-text-password
New password: Password123
Retype new password: Pasword123
[edit]
PeteL@Petes-SRX#
[/box]
3. Save the changes then reboot.
[box] [edit]
PeteL@Petes-SRX# commit and-quit
commit complete
Exiting configuration mode
PeteL@Petes-SRX> request system reboot
Reboot the system ? [yes,no] (no) yes
Shutdown NOW!
[pid 1904]
PeteL@Petes-SRX>
*** FINAL System shutdown message from root@FW-01 ***
System going down IMMEDIATELY
[/box]
Reset To Factory Settings if the SRX is part of a Chassis Cluster (is in Failover mode)
1. If the firewall is part of the Chassis cluster then you need to the following before you can carry out the procedure above.
[box]
PeteL@Petes-SRX> set chassis cluster disable reboot
For cluster-ids greater than 15 and when deploying more than one
cluster in a single Layer 2 BROADCAST domain, it is mandatory that
fabric and control links are either connected back-to-back or
are connected on separate private VLANS.
{primary:node0}
PeteL@Petes-SRX>
*** FINAL System shutdown message from root@FWA ***
System going down IMMEDIATELY
[/box]
Completely Wipe the Juniper SRX
Alternatively you can also do the following.
[box]
root> request system zeroize
warning: System will be rebooted and may not boot without configuration
Erase all data, including configuration and log files? [yes,no] (no) yes
warning: zeroizing re0
root>
[/box]
Related Articles, References, Credits, or External Links