Category: f5

Categories
f5

Config-sync over Management Interface in f5

Config-sync over management interface – while not a best practice – can be a handy thing to have, whether that is because of a lack of interfaces, switch capacity or other reason.

This has cropped up for me in a refresh / migration project where interfaces were changed out for fibre and didn’t come up immediately. This allowed us to sync the machines and configure failover before attending to the interface issue ..

Best practices for f5 High Availability configuration can be found here.

The management interface will not show up by default under the config-sync tab:

Only traffic interfaces available by default.

this has to be enabled using the following commands:

tmsh modify sys db configsync.allowmanagement value enable
tmsh save sys config
Enter commands on the CLI

Refresh the page and we can now choose to run the management interface:

Management interface now available
Categories
f5

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

Categories
f5

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

 

 

Exit mobile version