F5

F5 iRule — Syslog Dynamic DPort Translator

An interesting question came up the other day, we have multiple endpoints sending syslogs into a F5 VIP fronting a syslog collector…all on port 514. Our logging team wanted to change the port from 514 to different ports depending on the originating endpoint. Without changing each endpoints configuration to the desired new port, we thought maybe we could do this with an iRule.

 

when CLIENT_ACCEPTED {
  #Grab CLLIENT IP
  set clientIP [IP::client_addr] 
  
  #set default syslog port
  set destSyslogPort 514
  
  #check IP against DataGroup
  if {[class match $clientIP equals DG_SplunkPorts] } {
    #get corrisponding port fro DG_SplunkPorts
    set destSyslogPort [class lookup $clientIP DG_SplunkPorts]
   
  } else {
    #set as default 514
    set destSyslogPort 514
  }
}
when LB_SELECTED {
        LB::reselect node [LB::server addr] $destSyslogPort 
}

First we grab the $clientIP, as we will need this to lookup the corresponding value in the DataGroup. We also need to set the variable $destSyslogPortto 514 by default in case the $clientIPis not found…Next we use a class match statement to search for the value, if any, using the $clientIPWith the found port value, or the default, we then need to modify the LB selection process.

At this point the F5 has already chosen a backend server to load balance to, so we need to intercept this with the ‘when LB_SELECTED‘ event.  Within this event we tell the F5 to ‘reselect’ the chosen backend node t, in this case [LB::server addr] which is same node already selected, cleverly retaining the same backend node selected.  Lastly we set the destination port with $destSyslogPort.

DG_SplunkPorts “The Data Group Used”

F5 iRule — Syslog Cloning iRule with HSL or Sideband

HSL_syslog_cloning

First lets create two(2) pools with a single node in each. These will be used in our iRule to clone the UDP datagram to both.

pool_SyslogServer001

pool_SyslogServer001

Now that we created the two(2) pools with single nodes in each, we can craft the irule to utilize HighSpeedLogging(HSL) in an iRule and tie it alltogether.

when CLIENT_ACCEPTED {
    set syslog_pool1 [HSL::open -proto UDP -pool pool_SyslogServer001] 
    set syslog_pool2 [HSL::open -proto UDP -pool pool_SyslogServer002] 
}
when CLIENT_DATA {
  HSL::send $syslog_pool1 [UDP::payload]
  HSL::send $syslog_pool2 [UDP::payload] 

}
Pros Cons
  • Each HSL send destination requires a unique pool with one node in it.
  • Cannot change source address (has to be self IP F5 LTM)

SIDEBAND_syslog_cloning

Now a different approach is to use iRule sideband method. Sideband was introduced in TMOS-LTMv11.0.0 so it will be needed for the SIDEBAND method to be available for use. It pretty much opens a TCP or UDP connection when the iRule get triggered.

when CLIENT_ACCEPTED {

  # grab UDP payload
  set data [UDP::payload]
  
  # create connection objects to both servers
  set conn_id1 [connect -protocol UDP -myaddr 1.1.1.1 -timeout 100 -idle 30 10.10.10.1:514]
  set conn_id2 [connect -protocol UDP -myaddr 1.1.1.1 -timeout 100 -idle 30 10.10.10.2:514]
  
  # send sideband request to server1
  send -timeout 1000 $conn_id1 $data
  close $conn_id1
  # send sideband request to server1
  send -timeout 1000 $conn_id2 $data
  close $conn_id2
}
Pros Cons
  • More control, we can change things like source address and timeouts
  • No pools needed, can craft connection object directly in iRule

 

References:

F5 iRule — No Pool Members Available Vanity Page

I wrote a iRule post located here, where I describe the essentials behind how beneficial iRules can be and the many use cases they have. I stumbled across a situation the other day for a client. This client had an F5 VIP load balancing 2 web servers of theirs. Now if those web servers for some reason are not available due to their healthcheck monitor failing, the users of that web site will receive a white page as the F5 will not proxy the traffic because there are no available pool members. I thought what if this was a big site, should users be left in the dark about a web site they use frequently when it’s not available? Then the idea of having the F5 LTM bounce back a well-formed splash page. This splash page would inform the user that the web site temporarily down, and if they believe this result is in error to contact their helpdesk.

This situation can be remedied with a couple of lines in an iRule.

when HTTP_REQUEST {
    #check if no members available
    if { [active_members [LB::server pool]] == 0 } {
       #create data variables with HTML content to send to client
       set httphost [string tolower [HTTP::host]]
       set data "<h2>$httphost</h2><h3>NOTICE: Site Unavailable.</h3>If you believe you are receiving this message in error, contact your site administrator."
       #send the HTML string
       HTTP::respond 200 content $data
    }
    #unset variables
    unset $httphost
    unset $data
}

Continue reading…

F5 BIGIP and HAProxy — Masking 2-Way “Mutual” SSL Authentication

Hello folks,

So a recent post I published talked about 1-Way vs 2-way SSL Authentication in some decent detail. We learned that 2-Way “Mutual” SSL Authentication can be used to enforce both parties attempting to communicate securely to provide authenticity. In other words, prove to each other that they are who they say they are. This can be very powerful from a security standpoint, but is it practical? The answer is, yes and no. The constraint comes from the aspect of administration (actually create certificates for each client) and manageability (keep accounting and maintaining actively lists of trusts) with the trade-off of proper authenticity. For example at first administering and managing 10 client certificates may be okay, but then imaging 100, or even a 1,000! So in this post I wanted to approach the idea of utilizing some tools we can use to offload some of this administration and management while maintaining Mutual Authentication with another entity. The idea revolves around one major assumption, users of a particular service (In this case a web-server) reside on a privately controlled and trusted network

My idea is if we have a group of clients residing on an internal privately addressed network, we can use either an F5 LTM or HAProxy to proxy our users’s connections destined for a service that is enforcing 2-Way SSL “Mutual” Authentication. The F5 LTM or HAProxy would perform the 2-Way SSL Mutual Authentication on behalf of each connecting user, eliminating the technical need to generate certificates for each client, while maintaining an element of mutual trust to the end service.

The basic idea is: (notice only our F5 LTM/HAproxy and the web-server perform 2-Way “Mutual” Authentication)

Continue reading…

F5 BIGIP — iRule Server Selection based on Client Source Address and Port

A interesting request came up today regarding a Web Service we provide to multiple clients, all of whom have peering points connecting their IP network to ours using private address. The request was to have certain clients hit a particular Web box in a Server Pool, while others hitting the other. At the same time only for certain ports. Some of our web applications use a variety of ports because of the proprietary application running. Ports include, all TCP, 80, 443, 5555, 6050.  So I set off to create an iRule to handle this and have it log to show how everything is being mapped, start to finish for each connection.

A Service little info:

  • Client PAT = 10.99.29.10
  • PrimaryWebCluster = 10.43.1.6
  • Web01 = 10.43.4.231
  • Web02 = 10.43.4.232
  • Ports = 80, 443, 5555, 6050

iRule: irule_SrvSelection_byClientSrcAndPort

when CLIENT_ACCEPTED {    
     if { [TCP::local_port] == 80 } {  
        if { [IP::addr [IP::client_addr] equals 10.99.29.10] } {        
        pool pool_ct_primarywebcluster_80 member 10.43.4.231 80
        log local0. "[IP::client_addr] is Web01"            
        } else {        
         pool pool_ct_primarywebcluster_80 member 10.43.4.232 80    
        log local0. "[IP::client_addr] is Web02"          
        }
    }
    if { [TCP::local_port] == 443 } {
        if { [IP::addr [IP::client_addr] equals 10.99.29.10] } {        
        pool pool_ct_primarywebcluster_443 member 10.43.4.231 443
        log local0. "[IP::client_addr] is Web01"            
        } else {        
         pool pool_ct_primarywebcluster_443 member 10.43.4.232 443
        log local0. "[IP::client_addr] is Web02"  
        }
    }
if { [TCP::local_port] == 5555 } {
        if { [IP::addr [IP::client_addr] equals 10.99.29.10] } {        
        pool pool_ct_primarywebcluster_5022 member 10.43.4.231 5022
        log local0. "[IP::client_addr] is Web01"   
        } else {        
         pool pool_ct_primarywebcluster_5022 member 10.43.4.232 5022
        log local0. "[IP::client_addr] is Web02"  
        }
    }
}

if { [TCP::local_port] == 6050 } {
        if { [IP::addr [IP::client_addr] equals 10.99.29.10] } {        
        pool pool_ct_primarywebcluster_5022 member 10.43.4.231 5022
        log local0. "[IP::client_addr] is Web01"   
        } else {        
         pool pool_ct_primarywebcluster_5022 member 10.43.4.232 5022
        log local0. "[IP::client_addr] is Web02"  
        }
    }
}
when SERVER_CONNECTED {
  log local0. "Connection from [IP::client_addr]:[TCP::client_port]. \
    Mapped to F5 Floating IP [serverside {IP::local_addr}]:[serverside {TCP::local_port}] \
    -->> [IP::server_addr]:[serverside {TCP::remote_port}]"
}

 

And to check, SSH into the Primary F5 in the pair and type bash to give you shell access. (BIGIP v11.5+),

tailf /var/log/ltm
tmm3[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02
tmm3[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : Connection from 10.99.29.10:22524. to VIP 10.43.1.6  -->> 10.43.4.232:443
tmm3[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02
tmm3[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : Connection from 10.99.29.10:10972. to VIP 10.43.1.6  -->> 10.43.4.232:443
tmm[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02
tmm[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : Connection from 10.99.29.10:53187. to VIP 10.43.1.6  -->> 10.43.4.232:443
tmm2[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02
tmm2[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : Connection from 10.99.29.10:15709. to VIP 10.43.1.6  -->> 10.43.4.232:443
tmm3[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02
tmm3[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : Connection from 10.99.29.10:62364. to VIP 10.43.1.6  -->> 10.43.4.232:443
tmm3[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02
tmm3[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : Connection from 10.99.29.10:62496. to VIP 10.43.1.6  -->> 10.43.4.232:443
tmm[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02
tmm[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : Connection from 10.99.29.10:42691. to VIP 10.43.1.6  -->> 10.43.4.232:443
tmm1[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02
tmm1[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : Connection from 10.99.29.10:28510. to VIP 10.43.1.6  -->> 10.43.4.232:443
tmm3[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02
tmm3[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : Connection from 10.99.29.10:40464. to VIP 10.43.1.6  -->> 10.43.4.232:443
tmm1[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02
tmm1[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : Connection from 10.99.29.10:4082. to VIP 10.43.1.6  -->> 10.43.4.232:443
tmm[14225]: Rule /Common/irule_SrvSelection_byClientSrcAndPort : 10.99.29.10 is Web02

Nice!!

F5 BIGIP — Configuring the F5 AOM (Always On Management) interface

The F5’s AOM (Always On Management) interface module is one of the fundamental administrative features offered by BIGIP appliances. If you are familiar with System or Blade management devices, it is the similar to ILO (Integrated Lights Out), with a few extra features. One of the features that I like about the AOM is its integrated menu that can be called up in the console at anytime by pressing ( This is helpful in situations where a bad image or upgrade has corrupted the base OS, making it difficult to reboot the appliance via the CLI.

SSH to the F5 Appliance and get onto the AOM adapter:

SSH to your F5 Appliance using an username with TMSH access and gain bash access by running…

user@(ltm01)(cfg-sync In Sync)(Active)(/Common)(tmos)# run /util bash

Under bash, SSH to the AOM adapter

[user@ltm01:Active:IN Sync] ~ # ssh aom

You are now connected to the AOM adapter. Now we need to configure the adapter:

root@ltm01:~# netconfig
AOM Linux Management Network Configuration
Use DHCP for ipv4?                      no
Host name(optional):                    ltm01-aom
IPv4 or IPv6 address (required):        10.0.0.2
Network mask (required):                255.255.255.0
Broadcast IP address (optional:
Default gatewahy IP address (optional): 10.0.0.1
Nameserver IP address (optional):

NOTICE: We needed to connect to the AOM adapter via ssh aom because no IP was set. Now you can SSH directly to the IP we just assigned the AOM module!!
Continue reading…

F5 BIGIP — iRule Block URI for external Client’s only

So, I had a cool question asked to me today regarding an F5 VIP used by a web application.
“Can we block a certain URI from external client’s but allow internal client’s to visit it?”

Of course there is!! Now there are probably a billion different ways to do this, but this is what I came up with.

First the condition, we want only 10.0.0.0/8 hosts to be able to access this restricted URI. Anyone else should be dropped. I say dropped and not denied, because that way if a user tries to navigate to the URI that shouldn’t it just timesout, and doesn’t give them any more information then they need. Second, I want to log blocks, so I can see it working and get an idea of how many times it gets hit. Lastly we need to know the Virtual server to apply the iRule to.

Here is the finished iRule, hope it helps!

when RULE_INIT {
	set static::drop_notallowed 0

}

when CLIENT_ACCEPTED {
	if {not [IP::addr [IP::client_addr] equals 10.0.0.0/8]} {
                log local0. "[IP::client_addr] does not match 10.0.0.0/8 AND access URI = /restricted-URI/"
		set static::drop_notallowed 1
	}
}

when HTTP_REQUEST {
	if { [string tolower [HTTP::uri]] starts_with "/restricted-URI" }{
		if {$static::drop_notallowed==1}{
			drop
		}
	}

}

Continue reading…

F5 BIGIP — Alternative using HAProxy and keepalived — Part 2

Okay we’re back!! Welcome to Part#2. If you’ve read my last post in this high availability and load balancing series(Part#1) you understand the need for HAProxy to complete our setup. If you recall, I am looking for a alternative solution to BIGIP F5 LTMs products. These products provide both high-availability fail-over via a Floating IP between LTMs, and the Load Balancing of requests to service endpoints. In the previous post, we managed to tackle the former part and provide High Availability, but not the Load Balancing part.

To complete this alternative we now add HAProxy into our setup.
Continue reading…

F5 BIGIP — Alternative using HAProxy and keepalived — Part 1

I come from a strong BIG IP F5 background and wanted to explorer alternatives to their LTM product line. BIG IP F5 LTMs are their Highly Availability and Load-Balancing network products, see here. They are primarily used as a means to mitigate infrastructure failover across server clusters. How this is done is by use of a floating IP address that is shared between two independent devices, in this case LTMs. One LTM is always active and responds to request for this Floating IP from client devices. In the event of a device failure, the secondary LTM will sense this via a variety of means and take over as the Active LTM. This essentially is how the High-Availability or failover is maintained at an infrastructure connectivity perspective. The second piece to these devices is their load-balancing functionality. Load-balancing has many forms, for this case, we are talking about network service load balancing (pretty much layer 4 and above. This allows more intelligence into the distribution of request to a server farm or cluster.

Now as I stated previously, I was looking into alternative solutions and I came across a GNU free software called keepalived which seemed to do exactly what I needed. Remember their are two pieces I wanted to fullfill as an alternative solution to LTM; it has to be able to maintain Network failover (seamlessly) and provide load-balancing for serivce endpoints. Also, surprisingly, much of the configuration statements in the keepalived.conf look very simlar to F5 LTM bigip.conf file.
Continue reading…

F5 BIGIP — Determine the Healthcheck Source Address

I was discussing some F5 LTM Healthcheck Monitor capabilities with a colleague of mine at work the other day, when he brought up a great question.

What does an F5 LTM use for a source IP address when connecting to pool members for the healthcheck monitor service? Especially on a Multi-Network setup.

To answer this question we have to consider the typical LTM cluster set up . Usually set up in pairs of two(2), one acting as an Active unit and the other as Standby unit. Each unit has it’s own Self IP for each “network leg” it is attached to.  The Active and Standby unit also share a “Floating IP address”, which is used for the backend traffic to pool members. But back to the question, let’s use the following example:

Continue reading…