Implementing and Operating
F5 BIG-IP in Microsoft Azure
** **
In this lab you will be deploying a standalone F5 BIG-IP in Azure to sit in front of an instance of WordPress.
In this lab, you will complete the following steps:
- Generate SSH keys for CLI access to the F5 BIG-IP and WordPress Server
- Deploy a standalone F5 BIG-IP in Azure
- Modify the Security Group for the F5 BIG-IP to permit appropriate network access
- License and apply a base F5 BIG-IP configuration
- Deploy and configure a WordPress instance within Azure
- Secure access to the WordPress instance by routing all traffic through the BIG-IP instance
Before you begin the deployment process, you first need to generate an SSH Key Pair which will be used for authentication to the F5 BIG-IPs in this and subsequent labs.
For Linux / Mac Users:
- From CLI
ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (…./id_rsa): /tmp/azure |
---|
Result:
Your identification has been saved in /tmp/azure.
Your public key has been saved in /tmp/azure.pub.
Example:
Example public RSA key Linux / Mac:
For Windows Users:
- Use PuTTY
Create SSH keys using WinSCP (PuTTY)
Open PuTTYgen and accept all defaults.
Click “Generate”.
Save both Public and Private keys (do not protect with passphrase) in an easy accessible place on your laptop.
Click “Save public key” and “Save private key”.
Example public RSA key Windows:
LATER STEP: When making a connection to WordPress using SSH during the Lab, load the Private Key into PuTTY.
From PuTTY, go to “Connection” -> “SSH” -> “Auth” and brows to the location of your private key.
In this step you will deploy a new Azure Resource Group, F5 BIG-IP VE, and other supporting configuration items. Below is a list of items created during this step.
- Resource Group
- Virtual Machine for BIG-IP
- Network Interface for BIG-IP
- Public IP Address for BIG-IP
- Network Security Group
- Storage Account
- Virtual Network
To begin, log into the Microsoft Azure Portal – https://portal.azure.com
Click the green + sign at the top left corner of the screen and start searching the marketplace by typing ‘F5’ in the search field and hit “Enter”.
Take your time to view the different F5 products available.
Click F5 BIG-IP ADC BETTER – BYOL. An appropriate license is delivered by your lab proctor. The proctor will explain why you use BYOL in this lab.
At the bottom of the next page, make sure you have selected Resource Manager as the deployment model and not Classic. NOTE: This is the default option.
Click “Create”.
You will now start the deployment process. Use the information provided in Table 1.1 below to complete the “Create virtual machine” Basics page.
Table 1.1
Key | Value |
---|---|
BIG-IP Image | F5 BIG-IP ADC BETTER – BYOL |
Deployment Model | Resource Manager |
Name | f5bigipuser<student number>bigip1 |
VM disk type | SSD |
User name | f5bigipuser<student number> |
Authentication Type | SSH public key |
SSH public key | From Lab1 Step 1 |
Subscription | <User Unique> |
Resource group | Create new |
Resource group name | f5bigipuser<student number>usergroup |
Location | <Closest Azure DC> |
Once done, Click “OK”.
You now need to select the Virtual Machine disk type and image size. Using the information in Table 1.2 complete the “Size” page.
NOTE: For a complete list of compatible Azure instance sizes, refer to the “BIG-IP Virtual Edition and Microsoft Azure: Setup” guide.
Table 1.2
Key | Value |
---|---|
Disk Type | HHD |
Size | D2_V2 Standard |
Select HDD from “Supported disk type” then “View all” to browse the available VM sizes and features.
Select “D2_V2 Standard”.
Click “Select”.
In the “Settings” page, provide the remaining information required for the BIG-IP deployment and associated resources. Using the information in Table 1.3 complete the “Settings” page.
Table 1.3
Key | Value |
---|---|
Storage Type | HHD |
Use managed disks | No |
Under Settings, change “Disk type” to HDD and “Use managed disk” to “No”.
Look around at the various configurable items but leave them unchanged.
Once done, click “OK”.
Lastly, review the Summary page.
Note, in the screenshot below:
- “new” - meaning that the virtual network, subnet, Public IP and Network Security Group will be created for your VM
- “Validation passed”
Check the purchase you are about to make.
Notice that the BYOL is not charged, but the VM where the BIG-IP VE will land on is.
Click “Purchase” or “Create”.
In this step you will permit management access and HTTPS access to the BIG-IP by modifying the Network Security Group “Inbound” network access rule set.
Go to Resource groups.
Expand your Resource group and select the Network security group.
Notice that you only have an inbound rule allowing SSH.
Add rules to allow HTTPS for F5 BIG-IP management and data plane by clicking on “Inbound security rules” (to the left of the screen below)
Click “+ Add”.
Using the information provided in Table 1.4, add a rule to allow F5 BIG-IP management traffic.
Table 1.4
Key | Value |
---|---|
Source | Any |
Source Port | * |
Destination | Any |
Destination Port | 8443 |
Protocol | Any |
Action | Allow |
Priority | 100 |
Name | f5-allow-mgmt |
Click “OK”.
Repeat the previous step to add another rule using the information provided in Table 1.5, this time allowing external HTTPS traffic via the F5 BIG-IP.
Table 1.5
Key | Value |
---|---|
Source | Any |
Source Port | * |
Destination | Any |
Destination Port | 443 |
Protocol | Any |
Action | Allow |
Priority | 101 |
Name | f5-allow-external-https |
Once complete, the end results should look as follows:
In this step you will connect to the BIG-IP CLI and GUI, license the device, and complete a base configuration.
First, you need to identify the BIG-IPs public IP address to which you will connect.
Return to the resource group and select “Network Interface” to see the F5 BIG-IP’s private and public IP addresses.
Take note of the F5 BIG-IP’s public IP address. This will be used in subsequent steps.
Wait until the deployment is completed: you will see “Deployments succeeded” under “Notifications”. To view, click on the bell symbol in the upper right corner of the screen.
You now need to connect to the F5 BIG-IP CLI in order to; license the F5 BIG-IP, configure the hostname, create an admin account, and set the password.
SSH Connectivity for Linux / Mac Users:
- From CLI
Connect using ssh -i <private_key> f5bigipuser<Student Number>@<F5 BIG-IP public IP>, where private_key is the one corresponding to the public key uploaded when creating the F5 BIG-IP and f5bigipuserx is the user you created during the same step (“Create virtual machine/Basics”).
ssh -i <private_key> f5bigipuser<Student Number>@<F5 BIG-IP public IP> |
---|
Example:
SSH Connectivity for Windows Users:
- Use PuTTY
Install the F5 BIG-IP license
License your F5 BIG-IP using SOAPLicenseClient --basekey <license provided by the proctor>
SOAPLicenseClient --basekey <BIG-IP License> |
---|
Example:
Update the hostname
Change the F5 BIG-IP’s hostname. Replace x with the number assigned by your proctor.
tmsh modify sys global-settings hostname f5bigipuserx.azure.local |
---|
Example:
Create a password for f5bigipuserx. Replace x with the number assigned by your proctor.
tmsh modify auth user f5bigipuserx password "Demo123" |
---|
Example:
Wait until the system prompt changes to:
[f5bigipuserx@f5bigipuserx:Active:Standalone] ~ #
Changes made in the CLI are only present in the running configuration until they are saved. Save the system configuration.
tmsh save sys config |
---|
Example:
Connect F5 GUI using your favourite browser; go to https://<F5BIG-IP public IP>:8443
Accept the SSL certificate warning and log into the BIG-IP using username and password configured in the previous steps.
Click “Log in”.
In this step you will deploy another virtual machine and install the WordPress application to be place behind the BIG-IP.
From the Microsoft Azure Portal, click the green + sign at the top left corner of the screen and start searching the marketplace by typing “bitnami wordpress” in the search field and hit enter.
Select “WordPress Certified by Bitnami”.
Click on “Create” at the bottom of the screen.
Use the information in Table 1.6 to complete the “Basics” configuration page during this deployment.
Table 1.6
Key | Value |
---|---|
Name | f5bigipuser<student number>wordpress |
VM disk type | SSD |
User name | f5bigipuser<student number> |
Authentication type | SSH public key |
SSH public key | From Lab 1 Step 1 |
Subscription | <User Unique> |
Resource Group | Use existing previously created in step 1 |
Location | <Closest Azure DC> |
Click “OK” at the bottom of the page.
Table 1.7
Key | Value |
---|---|
Disk Type | HHD |
Size | A1 Basic |
Choose “A1 Basic”
Click “Select”.
NOTE: On the Settings page you’ll see a warning concerning the VM size selected. Change the disk type to HDD and set “Use managed disk” to “No”. Keep the other configurations unmodified.
Table 1.8
Key | Value |
---|---|
Storage Type | HHD |
Use managed disks | No |
Click “OK”.
Verify the summary.
Click “Create”.
Go to “Resource groups”, click on your resource group then select your WordPress “Public IP address”.
Take note of the WordPress public IP address. This will be used in subsequent steps.
Configure the WordPress system to accept HTTPS traffic only.
For Linux / Mac Users:
- From CLI
ssh -i <private_key> f5bigipuser<Student Number>@@<WordPress VM public IP> |
---|
Example:
For Windows Users:
- Use PuTTY
You will now modify the wp-config.php file.
sudo vim /opt/bitnami/apps/wordpress/htdocs/wp-config.php |
---|
In the vim editor, type /SITEURL to jump to the 2 lines you need to modify.
/SITEURL |
---|
The lines you are going to modify are:
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/');
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/');
Type “i” to enter “edit/insert mode”. Change http to https.
define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/'); define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] . '/'); |
---|
The end results should look as follows:
Hit escape, then :wq. Hit “Enter” to save and exit.
You now need to restart Apache for the changes to take effect.
sudo /opt/bitnami/ctlscript.sh restart apache |
---|
Verify that https://<Public IP address of WordPress> displays the Wordpress blog (Accept the security warning).
Restrict direct Internet access to the WordPress application
You now need to modify the Network security group to remove direct inbound access to the WordPress application.
From the Microsoft Azure Portal, go to “Resource groups”, click on your resource group then select your WordPress Network security group.
Remove the HTTP and HTTPS inbound rules leaving SSH access, as you will only allow web access to the WordPress blog via the F5 BIG-IP.
To do this, click on the “…” link at the far right side of the rule to be deleted.
Click “Delete” and confirm the delete action when prompted by clicking “Yes”.
Confirm web access has been restricted to WordPress.
Open a private browser windows and verify that https:<Public IP address> and http:<Public IP address> do NOT display the WordPress blog.
In this step you will configure the BIG-IP with a Virtual Server and Pool to allow inbound Internet access to the WordPress application.
Identify the private IP address for the WordPress instance.
From the Microsoft Azure Portal, select your WordPress Network Interface.
Take note of the F5 BIG-IP’s private IP address. This will be used in subsequent steps.
This completes work in the Microsoft Azure Portal. You will now configure the F5 BIG-IP.
Connect to the BIG-IP using https:<public IP>:8443
From the BIG-IP GUI, go to “Local traffic” -> “Pools” -> “Pool List” and click on the + sign.
Configure the pool using the information provided in Table 1.8 below leaving all other fields set to defaults.
Table 1.8
Key | Value |
---|---|
Name | wordpress_pool |
Health Montitor | HTTPS |
Node Name | wordpress |
Address | <your WordPress private IP address> |
Service Port | 443 |
Click “Finished”.
Configured correctly, the pool status will be green.
You now need to configure the Virtual server. For this you first need to find the private IP of your F5 BIG-IP.
From the BIG-IP GUI, go to “Network” -> “Self IPs” and note the IP Address.
Next you will create a virtual server by going to “Local Traffic” -> “Virtual Servers” -> “Virtual Server List” and click on the + sign.
Configure the Virtual Server using the information provided in Table 1.9 below leaving all other fields set to defaults.
Table 1.9
Key | Value |
---|---|
Name | vs_wordpress |
Destination Address | <Self IP address of the BIG-IP> |
Service Port | 443 |
SSL Profile (Client) | clientssl |
SSL Profile (Server) | serverssl |
Source Address Translation | Auto Map |
Default Pool | wordpress_pool |
Click “Finish”.
You have now completed the BIG-IP configuration for the WordPress application. To verify proper functionality, browse to https://<public IP of your F5 BIG-IP> and ensure it displays your WordPress blog.
NOTE: As part of this task, you will see a certificate warning. You can ignore this as in this lab you did not generate the server certificates. In real life, you would ensure you have installed valid certificates.
Now check the statistics of your virtual server to verify traffic flow, by navigating to “Statistics” -> “Module Statistics” -> “Local Traffic” -> Under “Statistics Type”, select “Virtual Servers”.
F5 offers on-demand Layer7 Application Firewall (Web Application Firewall) protection through a simplified setup of just a few clicks. This WAF offering is integrated in Azure Security Center.
In this lab, you will complete the following steps:
- Setup WordPress in Azure
- Use Azure Security Center to deploy the pre-configured F5 WAF and secure access to WordPress
- Demonstrate F5 WAF functionality and finalize the WAF deployment
Configure a new Virtual Network in preparation for the WordPress deployment
In this step you will deploy a new Virtual Network within Azure.
To begin, log into the Microsoft Azure Portal – https://portal.azure.com
Click the green + sign at the top left corner of the screen, click on “Networking”, and click on “Virtual network”.
“”
Create a virtual network using the information provided in Table 2.1 below.
Table 2.1
Key | Value |
---|---|
Name | user<student number>_vnet |
Address space | 10.10.0.0/16 |
Subscription | <User Unique> |
Resource group | Create new |
Resource group name | wordpress |
Location | <Closest Azure DC> |
Address Range | 10.10.0.0/22 |
Click “Create”.
Deploy and configure WordPress within Azure
From the Microsoft Azure Portal, click the green + sign at the top left corner of the screen and start searching the marketplace by typing “bitnami wordpress” in the search field and hit enter.
Select “WordPress Certified by Bitnami”.
Click on “Create” at the bottom of the screen.
Use the information in Table 2.2 to complete the “Basics” configuration page during this deployment.
Table 2.2
Key | Value |
---|---|
Name | user<student number>wordpress |
VM disk type | SSD |
User name | f5bigipuser<student number> |
Authentication type | SSH public key |
SSH public key | From Lab 1 Step 1 |
Subscription | <User Unique> |
Resource Group | Existing: wordpress (created in Lab 2 Step 1) |
Location | <Closest Azure DC> |
Click “OK” at the bottom of the page.
Use the information in Table 2.3 to complete the “Size” configuration page during this deployment.
Table 2.3
Key | Value |
---|---|
Disk Type | HHD |
Size | A1 Basic |
Choose “A1 Basic”
Click “Select”.
NOTE: On the Settings page you’ll see a warning concerning the VM size selected. Change the disk type to HDD and set “Use managed disk” to “No”. Keep the other configurations unmodified.
Use the information in Table 2.4 to complete the “Settings” configuration page during this deployment.
Table 2.4
Key | Value |
---|---|
Storage Type | HHD |
Use managed disks | No |
Accept all other defaults and click “OK”.
Verify the summary.
Click “Create”.
Go to “Resource groups”, click on the resource group “wordpress” then select your WordPress “Public IP address”.
Take note of the WordPress public IP address. This will be used in subsequent steps.
Access your WordPress instance and launch a simple SQL Injection attack.
Using your web browser navigate to HTTP://<wordpress public IP address>.
Navigate to the “Search” box by either scrolling down the page using your browsers scroll bar or by click the X in the lower right corner of the screen to close the “Manage” link, then click the arrow in bottom right corner of the screen.
In the search box, enter the following string to launch the SQL Injection attack.
'or 1=1# |
---|
Hit enter. Perform this task several times to simulate an attack.
Although the WordPress application does not respond with any records there are in fact no safeguards against this SQL injection attack.
NOTE: 'or 1=1# is an example of a simple SQL Injection attack. A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.
(SQL Injection description source: https://www.owasp.org/index.php/SQL_Injection)
Step 2. Use Azure Security Center to deploy the pre-configured F5 WAF and secure access to WordPress
In this step you will follow Azure Security Center’s security recommendations and deploy the F5 pre-configured WAF in front of the newly created WordPress application.
In order to enable F5 in Azure Marketplace for your account, go to https://azuremarketplace.microsoft.com/en-us/marketplace/apps/f5-networks.f5-web-application-firewall
Click “GET IT NOW”.
Complete the sign in process using the email address used to set up your account.
Accept the EULA by clicking “Continue”.
Among other things, Azure Security Center (ASC) makes recommendations to optimize and secure your web applications. You will now follow the recommendation from ASC to deploy the F5 pre-configured Web Application Firewall (WAF) in front of your WordPress application.
Go back to the Microsoft Azure portal and navigate to Azure Security Center.
Click on “Security Center” -> “Welcome” -> and click “Launch Security Center”.
Notice that ASC has recommendations for your environment.
Click on “Recommendations”
Recommendations are created by the Azure Security Center to make your applications more secure.
One of the recommendations is to Add a web application firewall, let’s continue by selecting this record.
NOTE: If the name of your WordPress does not appear, please wait a few minutes until Azure Security Center can create the Recommendations.
Click on the name of the application to the right of the screen (“user<student number>wordpress-ip” in the screenshot below) and select it.
Then, make sure you click on “Create New”.
Select “F5 Networks”.
NOTE: There are two deployment methods available today for the pre-configured F5 WAF, “Automatically provisioned”, and “Semi-automatically provisioned”. For this lab you will be using the “Automatically provisioned” method.
Please make sure you select “Automatically provisioned”.
Click “Create”.
Use the information in Table 2.5 to complete the “VM Configuration” page during this deployment. Leave all other settings as default.
Table 2.5
Key | Value |
---|---|
Password | Demo123 |
Click “OK”.
Use the information in Table 2.6 to complete the “WAF Information” page during this deployment. Leave all other options as default.
Table 2.6
Key | Value |
---|---|
License token | <license provided by the proctor> |
Internal server port | HTTP (note two locations) |
Click “OK”
Click “Create”.
NOTE: Deployment time can take up to 30 minutes.
Click on the Resource Group that deployed the ASM (it will be named wordpress-asc….):
Click on “Public IP address”.
Take note of the F5 BIG-IP’s public IP address. This will be used in subsequent steps.
Using your web browser, go to the BIG-IP GUI at HTTPS://<Public IP address:8443> to see when the platform completes the deployment.
Login as admin and use the password you entered during the WAF deployment process.
PLEASE NOTE: the deployment takes a little while. If you observe it from the GUI, you will see a reboot. This automated background deployment (licensing and creating the pool and the virtual server) may take 10 minutes or longer. Please be patient and do not interrupt this process. Once the Virtual Server is created, the setup of BIG-IP ASM is complete). You can login to the BIG-IP GUI console, it will not interrupt the process. However, please do not make any changes. You can go to the Virtual Server section and observe if the virtual server and the pool have been created. Once they have been automatically created, the process is complete.
As part of the WAF deployment, a new VIP on the BIG-IP has been configured for the WordPress application that sits behind a NAT rule. Additionally, a base WAF policy has been confuted for the application.
To to test the WAF policy you will repeat the SQL injection attack against the WordPress application but this time you will access the WordPress application through the F5 BIG-IP VIP being protected by the WAF policy.
Using your web browser navigate to HTTP://<BIG-IP public IP address> where the public IP address is now the IP address used to access the BIG-IP.
Navigate to the “Search” box by either scrolling down the page using your browsers scroll bar or by click the X in the lower right corner of the screen to close the “Manage” link, then click the arrow in bottom right corner of the screen.
Hit enter. Perform this task several times to simulate an attack.
Notice that the F5 BIG-IP WAF policy is now protecting the WordPress application from this SQL injection attack.
Using your web browser, go to the BIG-IP GUI at HTTPS://<Public IP address:8443>. Go to “Security” -> “Event Logs” -> “Application” -> “Requests”.
Click on the line with the highest “Violation Rating” link to view full request information.
Click on “Attack signature detected”
Click on “View details”.
Note that ASM has detected the SQL injection attack.
Now that you have successfully tested the path to WordPress through the F5 BIG-IP you need to finalize the WAF deployment. You will notice that you can still access to the WordPress application through the original public IP address (HTTP://<wordpress public IP address>) as demonstrated in step 1 of this lab. Finalizing the WAF deployment will eliminate the ability to access the WordPress application directly. Access to the WordPress application will now only be available through the F5 BIG-IP.
Go back to the Microsoft Azure portal and navigate to Azure Security Center.
Click on “Security Center” -> “Overview” -> and click “Recommendations”.
Select “Finalize web application firewall setup”.
Click on the WordPress application.
In a production environment you would first want to update your DNS records to point to the new BIG-IP VIP.
Check “I updated my DNS record” and click “Restrict traffic”.
This process can take a few minutes to complete but once finalized you can verify access has been restricted and WordPress is no longer accessible through the original WordPress public IP.
Browsing to HTTP://<wordpress public IP address> will now result in a timeout.
In this lab you will be deploying an active / active pair of F5 BIG-IPs in Azure using the Azure Resource Manager (ARM) templates. ARM templates automate many of the deployment steps and ensure a validated topology and configuration of your F5 BIG-IP instances within Azure.
In this lab, you will complete the following steps:
- Deploy an HA pair of F5 BIG-IP in Azure using an ARM template
- License and configure the F5 BIG-IPs
- Deploy and configure a WordPress instance within Azure
- Configure an F5 BIG-IP Pool and VIP for the WordPress application
- Restrict access to WordPress through the F5 BIG-IP only
- Test HA within Azure
In this step you will be deploying the F5 BIG-IP via an ARM template
To begin go to https://github.com/F5Networks/f5-azure-arm-templates and take your time to review the README.md. F5 offers a wide variety of ARM templates for various deployment scenarios and licensing options. For this lab you will be using a demo template which can be located at https://raw.githubusercontent.com/gregcoward/f5demo/master/azuredeploy.json.
Using your web browser, go to https://raw.githubusercontent.com/gregcoward/f5demo/master/azuredeploy.json
An ARM template will open up in GitHub.
Select all text and copy to your clipboard.
From the Microsoft Azure Portal – https://portal.azure.com
Click the green + sign at the top left corner of the screen and start searching the marketplace by typing ‘template in the search field and hit “Enter”.
Select “Template deployment”.
Click “Create”.
Select the “Build your own template in the editor” option.
Remove the default code, paste the content of the ARM template and hit “Save”. This opens Microsoft Azure > Custom deployment.
Use the information provided in table 3.1 to complete the Custom deployment process. Leave all other settings as default.
Table 3.1
Key | Value |
---|---|
Subscription | <User Unique> |
Resource group | Create new |
Resource group name | bigipuser<student number>-aa |
Location | <Closest Azure DC> |
Admin Password | Demo123Demo123! |
Dns Name for Public IP | f5bigipuser<student number>aa |
Scroll down and check “I agree to the terms and conditions stated above”, then click on “Purchase”.
Go to resource groups, select f5bigipuser<student number>-aa and look for the resource type load balancer.
This load balancer is an Azure Load Balancer (ALB) which will be in front of the two BIG-IPs and used to support the setup of the cluster. Click on it for more details.
Let’s start collecting some interesting information. First, identify the different NAT rules that have been deployed. From the Resource Group, click on “Inbound NAT rules”.
Take note of the different service ports. These will be used in subsequent steps.
Now, take a look at the Backend pools. Expand “loadBalancerBackEnd” to view the IP addresses of the F5 BIG-IPs sitting behind the Azure ALB.
Take note of the IP addresses. These will be used in subsequent steps.
Next, look at the Load Balancing rules. Notice the rules for HTTP and HTTPS applications and the ports used on the backend. Azure Load Balancer uses NAT to direct traffic to the different service ports.
Take note of the port mappings. These will be used in subsequent steps.
You will now connect to the F5 BIG-IPs. To do so you first need to identify the BIG-IPs’ public IP by clicking on of the virtual machines under the f5bigipuser<student number>-aa Resource group.
NOTE: Both F5 BIG-IPs have the same public IP address; you can access each individual unit by using the service ports mentioned above.
Take note of the public IP address. This will be used in subsequent steps.
You now need to connect to the F5 BIG-IP CLI. in order to complete the following tasks:
- Install the F5 BIG-IP licenses
- Update the hostnames
- Update the azureuser password
- Modify the 1nicautoconfig db variable
- Configure self-ips
- Configure device trust
- Create a sync-failover device group
- Synchronize the F5 BIG-IPs
- Verify synchronization status
- Save the system configuration
- Reboot devices
Now, with the information gathered above, SSH to each F5 BIG-IP.
SSH Connectivity for Linux / Mac Users:
- From CLI
ssh azureuser@<F5 BIG-IP public IP> -p <service port> |
---|
Example:
SSH Connectivity for Windows Users:
- Use PuTTY
Repeat this process for the second F5 BIG-IP.
Install the F5 BIG-IP license
License your F5 BIG-IP using SOAPLicenseClient --basekey <license provided by the proctor>. Run the SOAPLicenseClient command on both devices using a unique license key for each unit.
SOAPLicenseClient --basekey <BIG-IP License> |
---|
Example:
Update the hostname
Currently, both F5 BIG-IP devices are configured with the same name. Update the hostnames to be unique. Use bigip0.azure.local for BIG-IP0 and bigip1.azure.local for BIG-IP1
tmsh modify sys global-settings hostname bigip0.azure.local |
---|
Example:
Update the azureuser password
Update the password for the azureuser account to "Demo123" on both devices.
tmsh modify auth user azureuser password "Demo123" |
---|
Example:
Modify the 1nicautoconfig db variable
Modify the sys db provisioning setting for 1nicautoconfig to disable on both devices.
tmsh modify sys db provision.1nicautoconfig value disable |
---|
Example:
NOTE: If the system status does not yet display as “Active”, wait until it does so before proceeding to the next step. You can run “tail –f /var/log/ltm” to check the progress.
**Save the system configuration **
Changes made in the CLI are only present in the running configuration until they are saved. Save the system configuration on both devices.
tmsh save sys config |
---|
Example:
Verify the hostname change was successful
tmsh list sys global-settings |
---|
Example:
HA configuration
Both device have the same device name (“bigip1”, you can check using tmsh list cm device on each BIG-IP).
tmsh list cm device | grep device |
---|
Example:
BIG-IP0
BIG-IP1
To fix this, use the tmsh mv cm device command. Run the following commands on the appropriate devices.
On device BIG-IP0:
tmsh mv cm device bigip1 bigip0.azure.local |
---|
On device BIG-IP1:
tmsh mv cm device bigip1 bigip1.azure.local |
---|
Re-run the list cm device command to verify the changes.
Update the ssl port to 443
The SSL port is currently configured as 8443. This will be updated to 443 on both devices. You can use the “tmsh list sys httpd ssl-port” to verify the changes.
tmsh modify sys httpd ssl-port 443 |
---|
Example:
Define Confg-sync IPs
Define your static self-ip which will be used for config-sync. The IP addresses below are those you have written down from the “Backend pools” configuration. Using the appropriate backend IPs, issue the following command on each device. You can use the “tmsh list cm device | grep configsync-ip” command to verify the changes.
tmsh modify cm device <bigip_name> configsync-ip <static_private_ip_address> |
---|
Example for BIG-IP0:
tmsh modify cm device bigip0.azure.local configsync-ip 10.10.1.100 |
---|
Example BIG-IP1:
tmsh modify cm device bigip1.azure.local configsync-ip 10.10.1.101 |
---|
Configure device trust
Establish device trust using one BIG-IP. Issue the following command on BIG-IP0.
tmsh modify cm trust-domain root ca-devices add { <peer_management_ip> } name <bigip_name> username <username> password <password> |
---|
Example on BIG-IP0:
tmsh modify cm trust-domain Root ca-devices add {10.10.1.101} name bigip1.azure.local username azureuser password Demo123 |
---|
Result:
You will see the command prompt on each unit change to: In Sync (Trust Domain Only)].
Create a sync-failover device group
Create a sync-failover device group with network failover disabled.
create cm device-group <device_group_name> devices add { <all-bigip-names-separated-by-space> } type sync-failover auto-sync enabled network-failover disabled |
---|
Example on BIG-IP0:
tmsh create cm device-group bigip-azure-sync-failover devices add {bigip0.azure.local bigip1.azure.local} type sync-failover auto-sync enabled network-failover disabled |
---|
Result:
You will see the command prompt on each unit change to: Not All Devices Synced].
Synchronize the F5 BIG-IPs
Sync one BIG-IP to the other.
tmsh run cm config-sync to-group <device_group_name> |
---|
Example on BIG-IP0:
tmsh run cm config-sync to-group bigip-azure-sync-failover |
---|
Result:
You will see the command prompt on each unit change to: Active:In Sync].
Check the status
Issue the “tmsh show cm sync-status” command on both units to view the current config sync status.
tmsh show cm sync-status |
---|
Example:
Save the system configuration
Several changes have been made since the last save. Preform a final sys config save prior to reboot.
tmsh save sys config |
---|
Reboot both BIG-IP (ssh then run “reboot”).
reboot |
---|
Example:
You just setup two BIG-IPs as a cluster. Remember that both instances are active and are not setup the traditional way, because of the network limitation in Azure. (no L2 connectivity, just as in AWS).
You can connect to the BIG-IPs’ management GUIs using:
https:<public IP>:<service port>. In our case, the service ports are 8443 and 8444.
Example:
From the Microsoft Azure Portal, click the green + sign at the top left corner of the screen and start searching the marketplace by typing “bitnami wordpress” in the search field and hit enter.
Select “WordPress Certified by Bitnami”.
Click on “Create” at the bottom of the screen.
Use the information in Table 3.2 to complete the “Basics” configuration page during this deployment.
Table 3.2
Key | Value |
---|---|
Name | user<student number>wordpress |
VM disk type | SSD |
User name | azureuser<student number> |
Authentication type | SSH public key |
SSH public key | From Lab 1 Step 1 |
Subscription | <User Unique> |
Resource Group | Existing |
Resource Group | bigipuser<student number>-aa |
Location | <Closest Azure DC> |
Click “OK” at the bottom of the page.
Use the information in Table 3.3 to complete the “Size” configuration page during this deployment.
Table 3.3
Key | Value |
---|---|
Disk Type | HHD |
Size | A1 Basic |
Choose “A1 Basic”
Click “Select”.
NOTE: On the Settings page you’ll see a warning concerning the VM size selected. Change the disk type to HDD and set “Use managed disk” to “No”. Keep the other configurations unmodified.
Use the information in Table 3.4 to complete the “Settings” configuration page during this deployment.
Table 3.4
Key | Value |
---|---|
Storage Type | HHD |
Use managed disks | No |
Accept all other defaults and click “OK”.
Verify the summary.
Click “Create”.
Go to “Resource groups”, click on the resource group “bigipuser<student number>-aa” then select the “Network interface” created for your WordPress application.
Take note of both the WordPress public and Private IP addresses. These will be used in subsequent steps.
Using your web browser navigate to HTTP://<wordpress public IP address>.
In this step you will create a pool and virtual server for the WordPress application.
Connect to the BIG-IP0 using https:<public IP>:8443
From the BIG-IP GUI, go to “Local traffic” -> “Pools” -> “Pool List” and click on the + sign.
Configure the pool using the information provided in Table 3.5 below leaving all other fields set to defaults.
Table 3.5
Key | Value |
---|---|
Name | wordpress_pool |
Health Montitor | http_head_f5 |
Node Name | wordpress |
Address | <your WordPress private IP address> |
Service Port | 80 |
Click “Finished”.
Configured correctly, the pool status will be green.
Check that the pool is synced to bigip1 (same public IP, port 8444).
The Azure Load Balancer NATs HTTPS traffic 80 -> 8081; this is why the F5 virtual server you’ll create below listens to 8081.
On F5 BIG-IP0 (port 8443), create a transparent virtual server.
Transparent virtual server is a special type of VS that listens on all IP addresses/ports and looks like 0.0.0.0/0
From the BIG-IP GUI, go to “Local Traffic” -> “Virtual Servers” -> “Virtual Server List” and click on the + sign.
Configure the Virtual Server using the information provided in Table 3.6 below leaving all other fields set to defaults.
Table 3.6
Key | Value |
---|---|
Name | vs_wordpress |
Destination Address | 0.0.0.0/0 |
Service Port | 8081 |
Source Address Translation | Auto Map |
Default Pool | wordpress_pool |
Click on “Finished”.
Check the virtual server is green.
Check that this virtual is synced on F5 BIG-IP1.
Go to http://<public IP>, you should see your WordPress blog.
Example:
You now need to modify the Network security group to remove direct inbound access to the WordPress application.
From the Microsoft Azure Portal, go to “Resource groups”, click on your resource group then select your WordPress Network security group.
Remove the HTTP and HTTPS inbound rules leaving SSH access, as you will only allow web access to the WordPress blog via the F5 BIG-IP.
To do this, click on the “…” link at the far right side of the rule to be deleted.
Click “Delete” and confirm the delete action when prompted by clicking “Yes”.
Confirm web access has been restricted to WordPress.
Open a private browser windows and verify that https://<wordpress public IP address> does NOT display the WordPress blog.
In this step you will perform a system failover and validate that the WordPress application remains available.
Open both BIG-IP GUI (use private browser windows to have both GUIs open at the same time. Because both BIG-IPs have the same IP, you cannot have two GUIs opened at the same time in one browser (it saves cookies).
On F5 BIG-IP0:
Go to “Device Management” -> “Devices”.
Select “bigip0.azure.local (Self)”.
Scroll to the bottom, Click “Force Offline”.
Observe that you can still access WordPress.
Try forcing both F5 BIG-IPs offline and access the WordPress site again.
Were you able to access WordPress?
“Release Offline” one of the BIG-IPs (for example on bigip1, go to “Device Management”, select “bigip1.azure.com (Self)”, scroll down and click “Release Offline”.
Can you access the site now?
Check that http://<public IP> is available.
Finally, go to https://github.com/F5Networks/f5-azure-arm-templates and find the ARM template which should have done all this ‘manual’ work for you.
Troubleshooting
[azureuser@bigip0:Active:In Sync] ~ # tmsh run cm sniff-updates
Listening for commit_id_update on -i internal:h port 6699 (^C to exit)
[10:30:53] bigip0.azure.local (v13.0.0) -> bigip-azure-sync-failover: UPDATE CID 75.0 (bigip0.azure.local) at 10:30:53 FORCE_SYNC
[10:30:53] 10.10.1.101:42506 -> bigip-azure-sync-failover: SYNC_REQ CID 1.0 (bigip0.azure.local) at 10:25:34
[10:30:53] bigip1.azure.local (v13.0.0) -> bigip-azure-sync-failover: UPDATE CID 75.0 (bigip0.azure.local) at 10:30:53 FORCE_SYNC
[10:32:27] bigip1.azure.local (v13.0.0) -> bigip-azure-sync-failover: UPDATE CID 31.0 (bigip1.azure.local) at 10:32:27 FORCE_SYNC
[10:32:27] 10.10.1.100:59354 -> bigip-azure-sync-failover: SYNC_REQ CID 75.0 (bigip0.azure.local) at 10:30:53
[10:32:27] bigip0.azure.local (v13.0.0) -> bigip-azure-sync-failover: UPDATE CID 31.0 (bigip1.azure.local) at 10:32:27 FORCE_SYNC