reject

Description

Causes the connection to be rejected, returning a reset as appropriate for the protocol. Subsequent code in the current event in the current iRule or other iRules on the VS are still executed prior to the reset being sent.
If the VS is using FastHTTP, reject commands will not work, at least under 11.3.0.

Syntax

reject

reject

  • Causes the connection to be rejected, returning a reset as appropriate for the protocol. In the case of TCP, the client will receive a TCP segment with the RST bit set. In the case of UDP, an ICMP unreachable message will be generated.
  • The system connection table entry associated with the flow is also removed.
  • Subsequent code in the current event is still executed prior to the reset being sent. If there are other iRules with the same event, those event(s) will also be executed. See the second example below for details.

Examples

when CLIENT_ACCEPTED {
  if { [TCP::local_port] != 443 }{
    reject
  }
}

Example showing how code in a second iRule in the same event will still execute after reject is called
# Rule 1 on VS1
when HTTP_REQUEST priority 100 {
   # This event in this iRule runs first
   reject
   log local0. "Rejecting this request"
}
# Rule 2 on VS1
when HTTP_REQUEST priority 200 {
   # This event in this iRule runs second
   log local0. "This will still execute"
}

Example showing how code in a second iRule in the same event can be prevented from executing after reject is called
# Rule 1 on VS1
when HTTP_REQUEST priority 100 {
   # This event in this iRule runs first
   reject
   log local0. "rejected"

   # Disable future events in this or any other iRule on the virtual server
   event disable all

   # Exit this event of this iRule immediately
   return

   # This never gets executed
   log local0. "not hit"
}

# Rule 2 on VS1
when HTTP_REQUEST priority 200 {
   # This event in this iRule runs second but won't be executed
   log local0. "This will still execute"
}