20 Lines or Less #73: VIPs, SMTP Blocking and Responses

What could you do with your code in 20 Lines or Less? That's the question I like to ask for the DevCentral community, and every time I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

This week in what I believe to be 20LoL #73 (Lost track…but we’ll go with it) we've got a few more prime examples of iRules doing what iRules do best: solving problems. Whether you're trying to do some fancy footwork when it comes to traffic routing to multiple VIPs, or dealing with some SMTP requests you'd rather not have to, you'll find something handy in this week's 20 Lines or Less. Many thanks to the fine contributors of said examples, both F5ers and otherwise.

VIP redirect to another VIP

https://devcentral.f5.com/s/questions/vip-redirect-to-another-vip

A question that comes in fairly often is how to bounce traffic from one location to another. A very specific version of that question is "How do I get traffic from one of my VIPs to another?". This has been addressed in the Q&A section more than once, but I wanted to put it here in the 20LoL as well, as it seems to be a common theme. As Kevin Stewart nicely put, there are basically two ways to do this. First is with a simple redirect. This is done either via the HTTP::redirect command or by responding with a 301. This will tell the client to seek the resource they're requesting from a different host, all you have to do is supply the address of the VIP you want to bounce them to. The other, more direct fashion is to use the VIP targeting VIP function within LTM to make the destination an internal VIP. This looks a bit different, and behaves a bit different, but the client will never see the redirect, which can be handy at times. I've included Kevin's examples of each option here:

when HTTP_REQUEST {
    if { ...some condition... } {
        HTTP::redirect "https://somewhere.else.com"
    }
}

when HTTP_REQUEST {
    if { ...some condition... } {
        HTTP::respond 301 Location "https://somewhere.else.com"
    }
}

when HTTP_REQUEST {
    if { ...some condition... } {
        virtual internal-vs
    }
}

Block SMTP connections based on EHLO

https://devcentral.f5.com/s/questions/need-help-blocking-smtp-connections-based-off-ehlo-name

Pesky SMTP attackers getting you down? Coming from multiple different IP addresses? Looking for a way to stop them based on their connection strings? Well look no further, Cory's got your back. He shows us a simple way to check the EHLO info in an SMTP handshake to block unwanted bad guys from doing…bad guy things. Simple and clever and useful, very 20LoL-ish. Check it out.

when CLIENT_ACCEPTED {
 TCP::respond "220\r\n"
 TCP::collect
 }

when CLIENT_DATA {
 set clientpayload [string tolower[TCP::payload]]
 if { $clientpayload contains "ehlo abcd-pc" } {
  reject
 }
}

No HTTP Response Fired?

https://devcentral.f5.com/s/questions/when-is-http_response-not-fired

This one is less a trick in code, but a lesson in understanding how iRules play with other modules loaded on the LTM. A user was having some troubles with APM multi-domain and an iRule they wanted to use that fired on HTTP_RESPONSE. As Kevin so clearly explains, "The HTTP_RESPONSE is triggered for egress HTTP traffic through the box. The logon VIP in an APM multi-domain configuration doesn't trigger the HTTP_RESPONSE event because it handles all responses locally. Your best bet here, unfortunately, is to layer the APM logon VIP behind an LTM VIP that can see the HTTP response traffic from the APM VIP. You'd use a very simple iRule on the LTM VIP". And here is said iRule, for all those that might run into a similar situation.

when HTTP_REQUEST {
    virtual [name of APM VIP]
}
when HTTP_RESPONSE {
    HTTP::header insert Strict-Transport-Security "max-age=31708800"
}