Forum Discussion
PGI_28560
Nimbostratus
NimbostratusDrop Traffic based on HTTP Header
This is my first entry into the world in iRules, however I don't have much programming expierence, so I just wanted to run this by the community.
I am looking to make an iRule based on if a certain header exists. For example, if the header "t-shirt" exists, send the connection to the "pants" pool. If the header does not exist, drop the connection.
when HTTP_REQUEST {
if { [HTTP::header exists t-shirt] } {
pool pants
} else {
discard
}
}
Above is what I came up with, so I am not sure if that looks right. It seemed too easy.
Thanks for any help with this matter!
Brian_69413Looks fine.
iRules are awesome!
hooleylistCirrostratus
As Brian said, that iRule looks fine. If you want to tell the client to remove the connection from its connection table and not leave the browser hanging, you could send a TCP reset instead using reject (instead of discard).
Aaron
PGI_28560Wow! Thanks for the quick response! I like the idea of actually stopping the connection with the reject, thanks for the suggestion.
Just to confirm....
when HTTP_REQUEST {
if { [HTTP::header exists t-shirt] } {
pool pants
} else {
reject
}
}
Sorry to ask such a simple question!
Michael_YatesHi PGI,
Yes, that looks totally correct.
The "reject" command causes the connection to be rejected, returning a reset as appropriate for the protocol.- drop, discard, and reject all result in a TCP reset when executed from within the HTTP_REQUEST event. Because the TCP 3-way handshake has to occur in order to exchange HTTP traffic, it isn't possible to just drop (ignore) the initial SYN. I played with it a bit today and couldn't find a way to just drop a connection other than using a packet filter.
-George - hooleylistI don't think drop or discard should cause TMM to send a TCP reset immediately--just remove the connection table entry. TMM should send a reset in response to the next packet the client or server sends on the connection. That next packet could be a long ways out. So intermediate hosts in the chain between the client and TMM might have the connection open unnecessarily long. Also, if you use drop, the client will generally timeout after an idle timeout rather than knowing immediately that the connection is invalid. The only time I think it makes sense to drop a packet is if you're trying to avoid telling a malicious client that their connection is invalid. And like you say George, if you've already had TMM accept the TCP connection, a malicious client already knows the service is answering.
tl;dr: just use reject if you're blocking an HTTP request or TCP connection on an LTM VS with a TCP profile.
Aaron 
Robert_47833Altostratus
if you have a fallback host in your VIP,"reject'" will take the client to fallback host page- hooleylistThat's interesting to hear. I wonder if you could disable the fallback host functionality using HTTP::fallback. It doesn't look like it from the wiki page, but you could open a case with F5 Support to find out more (or request an enhancement if it's not possible).
Aaron