Drop Doesn't

Hi Vince,

 

 

I was just testing the drop command with HTTP responses. What F5 came back with was that the command would prevent the response body from being sent to the client, but the HTTP headers which had already been parsed would be sent back to the client. I didn't test calling drop from HTTP_REQUEST, but I'd guess that a similar behavior would be expected where the HTTP headers would be sent to the server, but any body from the request would be dropped. That's just a guess though.

 

 

 

From C574762:

 

 

1. If I check a status code in HTTP_RESPONSE, see it's one I don't like, and call 'drop' or 'discard', does it just prevent the current payload from being sent to the client?

 

 

Calling "drop" or "discard" in the HTTP_RESPONSE event prevents LTM from accepting (ACKing) the TCP packet which contains the HTTP body (packet is processed); additionally, only the HTTP headers will be forwarded to the client and the client side of the connection will abort (RST).

 

 

 

 

In the tcpdumps on the server side (or on the server itself), do you see a connection attempt being made, or a connection attempt being made and HTTP headers being sent?

 

 

Maybe it would be better to close the clientside TCP connection using TCP::close rather than using drop? Could you try this and check the client and serverside behavior?

 

 

Thanks,

 

Aaron

Tried changing the drop to TCP::close, and asked the server guys what they saw - here's the response they sent back (with URLs and IPs redacted). Is it just not possible to keep *any* connection request from making it across to the inside servers?

 

---

 

I set the user agent to “torrent” in Modify headers tool and accessed http://x.tld as as a test url.

 

Below are the request and response as seen in wireshark.

 

Request to VIP:

 

GET /as HTTP/1.1

 

Host: x.x.x.x

 

User-Agent: torrent

 

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

 

Accept-Language: en-us,en;q=0.5

 

Accept-Encoding: gzip,deflate

 

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

 

Keep-Alive: 300

 

Connection: keep-alive

 

Response from VIP

 

HTTP/1.0 302 Found

 

Location: http://x.tld

 

Server: BigIP

 

Connection: Keep-Alive

 

Content-Length: 0

 

So even if the TCP connection is closed and there is no body, the header “Location” and status code 302 makes the browser do a request to

 

http://x.tld

 

The redirect statement is still getting executed.

Can you try this instead with added logging?

 
 when HTTP_REQUEST { 
  
    log local0. "[IP::client_addr]:[TCP::client_port]: New [HTTP::method] request to [HTTP::host][HTTP::uri] with UA [HTTP::header User-Agent]" 
    switch -glob [string tolower [HTTP::header "User-Agent"]] { 
       "*torrent*" - 
       "*azureus*" - 
       "*windows-media-player*" - 
       "*microsoft-webdav-miniredir*" { 
          log local0. "[IP::client_addr]:[TCP::client_port]: Matched UA check. Closing TCP connection." 
          TCP::close 
       } 
       default { 
          log local0. "[IP::client_addr]:[TCP::client_port]: UA didn't check, redirecting." 
          HTTP::redirect http://targetsite.tld 
       } 
    } 
 } 
 

If TCP::close doesn't work, can you try reject instead? This should trigger LTM to send a RST packet to the client.

Can you post anonymized copies of the logs from both TCP::close and reject?

Thanks,

Aaron

Log excerpt below - seems to be working exactly as expected, first allowing a connection, then failing several times as I tested various User-Agent strings from the rule with the Modify Headers add-on. then working again when I disabled all the User-Agent mods. The log entries look exactly the same, just noting "Closing TCP Connection" regardless of the method used, TCP::close, drop, or reject.

 

Oct 22 15:19:19 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:38440: New GET request to x.x.x.x/ with UA Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

 

Oct 22 15:19:19 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:38440: UA didn't check, redirecting.

 

Oct 22 15:19:54 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:38440: New GET request to x.x.x.x/ with UA Azureus

 

Oct 22 15:19:54 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:38440: Matched UA check. Closing TCP connection.

 

Oct 22 15:19:54 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:39202: New GET request to x.x.x.x/ with UA Azureus

 

Oct 22 15:19:54 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:39202: Matched UA check. Closing TCP connection.

 

Oct 22 15:19:54 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:39207: New GET request to x.x.x.x/favicon.ico with UA Azureus

 

Oct 22 15:19:54 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:39207: Matched UA check. Closing TCP connection.

 

Oct 22 15:19:57 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:39235: New GET request to x.x.x.x/favicon.ico with UA Azureus

 

Oct 22 15:19:57 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:39235: Matched UA check. Closing TCP connection.

 

Oct 22 15:21:09 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:39925: New GET request to x.x.x.x/ with UA Windows-Media-Player

 

Oct 22 15:21:09 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:39925: Matched UA check. Closing TCP connection.

 

Oct 22 15:21:29 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:40201: New GET request to x.x.x.x/ with UA Torrent

 

Oct 22 15:21:29 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:40201: Matched UA check. Closing TCP connection.

 

Oct 22 15:21:36 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:40254: New GET request to x.x.x.x/ with UA Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

 

Oct 22 15:21:36 tmm tmm[1121]: Rule filter.useragent : x.x.x.x:40254: UA didn't check, redirecting.

Those logs show that the iRule appears to be working. On the TCP connection from client port 38440, the client makes a request with a legal UA and is redirected. On the same TCP connection, the UA changes to Azuerus and the connection is closed. Did the server get an HTTP request from the "Azureus" client? Did the "Azureus" client get a response or just a TCP close?

The rest of the logs seem to indicate that any restricted UA request is closed successfully.

If it's not working, you could add more debug logging to show the server connection and request being sent:

 
 when HTTP_REQUEST { 
  
    log local0. "[IP::client_addr]:[TCP::client_port]: New [HTTP::method] request to [HTTP::host][HTTP::uri] with UA [HTTP::header User-Agent]" 
    switch -glob [string tolower [HTTP::header "User-Agent"]] { 
       "*torrent*" - 
       "*azureus*" - 
       "*windows-media-player*" - 
       "*microsoft-webdav-miniredir*" { 
          log local0. "[IP::client_addr]:[TCP::client_port]: Matched UA check. Closing TCP connection." 
          TCP::close 
       } 
       default { 
          log local0. "[IP::client_addr]:[TCP::client_port]: UA check didn't match, redirecting." 
          HTTP::redirect http://targetsite.tld 
       } 
    } 
 } 
 when SERVER_CONNECTED { 
  
    log local0. "[IP::client_addr]:[TCP::client_port]: connection to [IP::server_addr]:[TCP::server_port]" 
 } 
 when HTTP_REQUEST_SEND { 
    clientside { 
       log local0. "[IP::client_addr]:[TCP::client_port]: UA [HTTP::header User-Agent], request to [HTTP::uri]" 
    } 
 } 
 

Thanks,

Aaron

Added the extra sections, but they don't seem to be writing anything to the log, even when the Firefox UA is unmodified and a successful connection to the redirect page is made.

Can you clarify what you see from the client perspective and in tcpdumps on the client and serversides when using the above rule with TCP::close? From the logs you posted, it looks like it is working successfully.

 

 

Thanks,

 

Aaron

I'm working on getting captures from the server side, but here's one I just did from my workstation - even though the client browser just shows "connection reset", the trace does show that redirect is being sent back to the client, and a subsequent connection between the client and the redirect target.

Thanks for posting the client trace. Can you post the LTM logs from the same test?

 

 

Aaron

Oddly, using the exact same iRule with log statements that I had been using in our Test LTM environment, the F5 logs from our Prod hardware (which is what I was hitting when I produced that packet capture) show nothing at all for this traffic. In Prod we have a VIP set up in the "Local Traffic" area of our GTM with the iRule attached, which bounces traffic to a partner and then back through a WIP set up on the same device.