Category: f5

Posted on

iRule Event Order for HTTP Requests and TCP Connections

iRule Event Order

There is an excellent article on DevCentral regarding iRule order but this focuses on TCP, the event order for an HTTP request is different as you can see below:

Event Order – HTTP Request

1. RULE_INIT
2. CLIENT_ACCEPTED
3. CLIENTSSL_HANDSHAKE
4. CLIENTSSL_CLIENTCERT
5. CLIENT_DATA
6. HTTP_REQUEST | CACHE_REQUEST
7. HTTP_CLASS_FAILED | HTTP_CLASS_SELECTED
8. STREAM_MATCHED
9. HTTP_REQUEST_DATA
10. CLIENT_DATA | HTTP_REQUEST_DATA
11. LB_SELECTED | LB_FAILED
12. STREAM_MATCHED
13. SERVER_CONNECTED (Here is where the backend server is reached)
14. SERVER_SSL_HANDSHAKE
15. HTTP_REQUEST_SEND
16. SERVER_DATA (CACHE_RESPONSE | HTTP_RESPONSE)
17. HTTP_RESPONSE_DATA

Event Order – TCP Connection

1. RULE_INIT
2. CLIENT_ACCEPTED
3. CLIENT_DATA
4. STREAM_MATCHED
5. LB_FAILED | LB_SELECTED
6. SERVER_CONNECTED
7. SERVER_DATA

No related posts.

Posted on

f5 Default Gateway Configuration

f5 Default Gateway

This article walks through how to configure an f5 default gateway for your internal (or external!) machines.

Often, SNAT automap, a SNAT address or SNAT pool is used to essentially “hide NAT” the incoming packet behind the BigIP which will mean that the server will reply directly back to it; this doesn’t work or isn’t wanted for some environments though.

If the packet is passed through the f5 and still contains its original (internet routable) client source IP then the back-end server will send its reply to the default gateway and if this *isn’t* the BigIP then we will have asymmetric routing which is never pleasant at the best of times. This is therefore an example scenario where using the f5 as a default gateway would be convenient.

This  is actually a “Forwarding (IP)” Virtual Server which will listen on all Self IPs but you can (and most certainly should) lock this down on a VLAN basis for security.

Part 1

  1. Name your virtual server, in this case “s_gateway”
  2. Specify a source address – this is optional but if you leave it blank it will default to 0.0.0.0/0 meaning it will accept connections from ALL IP addresses whether internal or external. As this is a MAJOR SECURITY RISK you should lock it down to the subnets you want to accept connections from, in this case we have used “10.5.5.0/24” – connections from all other address ranges will be silently dropped
  3. Destination – you can lock this down to a specific network but for a default gateway we want to allow everything so this is “0.0.0.0/0”
  4. Set ports to “*” to accept connections to any port.

Part 2

  1. Unless you only wat to allow TCP & UDP, drop the Protocol menu down and choose “All Protocols”
  2. Select the VLANs you want to enable this on (optional)
  3. Enable SNAT Automap – this essentially hides connections behind the BigIP -you could also use a SNAT pool or address

 

 

No related posts.

Posted on

f5 Master Key for RMA and Migration

f5 Master Key Backup and Restore

The f5 master key is used to encrypt and decrypt all that is secure on your f5 appliance including certificate keys, passphrases and UCS configuration files; this is obviously therefore an absolutely vital piece of information in certain situations.

If you have a synchronized cluster then this is not so much of an issue: when you add a new device to the cluster – be that a new member or an RMA replacement for a failed appliance – then the master key will be synchronized as well.

Situations where this can really impact your ability to get back up and running quickly is when you have a standalone appliance or you are transferring config from one machine to another:

Scenario:

  • Standalone appliance fails, monitoring systems go crazy and red lights start blinking everywhere – you call it in and you have a new machine on site in 4 hours (if you bought the right support contract!)
  • You plug it in and give it a management IP and access the GUI
  • Feeling smug because you’ve taken regular backups and stored them offline, you upload your latest UCS archive to restore the configuration
  • Config load fails as it is unable to decrypt the SSL keys passphrases, LDAP profiles passphrases, cookie encryption passphrases etc. etc.
  • You may see the following in the logs: Decryption of the field (field_name) for object (object_name) failed

Resolution:

  • Trawl through the config, edit out the passphrases and re-key most of it from scratch

OR

  • Change the master key to the one from the failed appliance, upload your UCS config and engage ultra-smug mode.

This is very easily done using the “f5 Master Key Utility” and should form part of your backup process for all your f5 appliances:

Backup the Master Key Using f5mku

  • Use the “-K” switch to display the master key and then copy the resulting key securely to an offline vault:
[root@f5] ~ # f5mku -K
7gcOKj3dhFjhr4mFy0AU1p==

Restore the Master Key Uing f5mku

  • Use the “-r” switch to restore the key to your new appliance:
[root@f5] ~ # f5mku -r 7gcOKj3dhFjhr4mFy0AU1p==
Rekeying Master Key...
[root@f5] ~ #
  • Job done! Now you can upload the UCS config archive without needing to worry about decryption failures.

 

Note: f5kmu Options

[root@f5] ~ # f5mku --h
f5mku: invalid option -- -

Usage: f5mku [d:?fhHr:t:uUvYZ]

Commands: (one of these must be specified)
-d bits generate a base64 encoded RSA key and output to stdout
-f fetch unit key
-Z dump debug information
-r key rekey with the specifed master key (b64 encoded)

Options:
-? -h this help
-t # Timeout value in seconds (1-500)
-u Unit test posture (no HAL)
-U Test unit key functionality.
-H Force I/O to HAL storage
-v set verbose mode
-Y Answer Yes to any queries

Log messages (including debug) go to authpriv and local6 facilities.

No related posts.