I have an iRule that fires on client_accepted applied to a virtual forwarder (0.0.0.0) that basically forwards all tcp and udp traffic (not destined to our GTM DNS virtual). The iRule does a whereis geolocation lookup against a blockedcountry data-group list and drops traffic that matches the list. For the most part it is working. However I'm still seeing some packets getting through from these blocked countries. Are there certain scenarios in which packets would still get through? Sending syn packets with invalid flags? Or a certain number of identical packets? TIA

It's hard to tell without seeing the iRule and perhaps also the DG - can you post them (suitably redacted of course). The F5 is fairly strict around invalid protocol options and protocol sanitisation (more so since AFM was introduced, even if you don't run it you still benefit from changes in TMOS that support it) so I don't think it's an issue with flags or identical packets.

Hey thanks for the quick response. Here's the irule and data groups (abbreviated). when CLIENT_ACCEPTED { if { [class match [IP::client_addr] equals allowedip]} { } elseif { [class match [IP::client_addr] equals blockedsrcaddress]} { drop } elseif { [class match [whereis [IP::client_addr] country] equals blockedcountries]} { drop } elseif { [class match [IP::local_addr] equals blockeddstaddress]} { drop } else { } } ltm data-group internal allowedip { records { 12.129.. { data FrontBridge_9 } 12.129.. { data FrontBridge_3 } ltm data-group internal blockedcountries { records { AR { data Argentina } AT { data Austria } BG { ltm data-group internal blockeddstaddress { records { 87.255.51.. { data Netherlands_Virus_Communications } ltm data-group internal blockedsrcaddress { records { 198.20.. { data Shodan_CIDR } } type ip }

Thanks. So it's only the 'elseif { [class match [whereis [IP::client_addr] country] equals blockedcountries' part you have an issue with yes? How many entries in the DG? Also, how do you know they are getting through?

Yes it's the blockedcountries item. I have about 33 items in that data group list and I know they get through because I see the drops on my firewall. Like I said most items are getting dropped. But I can see for instance some China addresses getting through but systems in the same class c get dropped. Probably 98% get dropped. I haven't looked at the logs enough to know what percentage really but it's not much getting through.

OK, so how does your firewall identify the country of origin? If they are not sharing the same source data I'd not expect there to be a match.

GeoLocation iRule Client_Accepted missing some traffic

27 Replies

ipman_1988_5418
Nimbostratus
Sep 26, 2013
Again this irule is applied to a forwarding (IP) virtual server

source: 0.0.0.0

destination: 0.0.0.0

profile fastL4

All ports/protocols

All vlans
- What_Lies_Bene1
  Cirrostratus
  Sep 26, 2013
  I'm rather stumped. It's an odd one as this is a forwarding VS. The CLIENT_ACCEPTED event for TCP for instance fires after the three way handshake according to the iRules wiki. That's not going to occur with a forwarding VS. The whereis command also isn't listed as a valid command on the wiki page for CLIENT_ACCEPTED. CLIENT_ACCEPTED isn't listed as a valid event on the whereis page but only one GTM event is listed. Shame it's unclear and the documentation isn't up to date. It's probably a bug but anyway, what does your FastL4 profile look like? Also, is it just UDP that gets through or TCP too? Also, could you try 'reject' instead of 'drop'?
ipman_1988_5418
Nimbostratus
Sep 26, 2013
I've seen tcp and udp get through. Also, every packet I've seen get through thus far has been dropped by my firewall. So for tcp traffic it's just dropping the syn packet. It never completes a three way handshake so I'm not sure why it would drop anything if it requires the three way handshake to complete.

I'm using the default fastL4 profile. It has 300 second idle timeout, 5 second handshake timeout and 5 second tcp close timeout. I believe everything is default on that.
- What_Lies_Bene1
  Cirrostratus
  Sep 26, 2013
  Thanks and what TMOS version are you running? This might be relevant: http://support.f5.com/kb/en-us/solutions/public/8000/300/sol8332.html. Can you confirm in the FastL4 profile that Loose Initiation and Close are not enabled please?
ipman_1988_5418
Nimbostratus
Sep 26, 2013
Ver 11.3 HF6

Loose Initiation and Close are NOT enabled.

Doesn't look like the solution applies to this version. I don't even see that PVA option under the fastL4 profile.
StephanManthey
MVP
Sep 26, 2013
Did you already try to change the event into CLIENT_DATA?

Is there a 2nd iRule associated with the virtual server?
ipman_1988_5418
Nimbostratus
Sep 26, 2013
I haven't tried anything with client_data. Since my firewall is dropping all of these packets as soon as the first syn comes in (that slips by the ltm) I'm not sure the F5 will ever see any client data from these. Perhaps the udp packet would cause client_data to fire?

CLIENT_DATA

An iRule event triggered (for TCP) each time new data is received from the client while the connection is in the "collect" state. For UDP, this event is triggered for each received UDP segment.

Guess I could add a client data event after the client_accepted. Should I put that in a different irule?
StephanManthey
MVP
Sep 26, 2013
The CLIENT_DATA should be fired at least with the first incoming UDP packet.

And as you are using a L4 virtual server the TCP 3-way handshake won´t happen at the virtual server. Instead the SYN should be passed through immediately, imho.

Of course I´m wondering, why the iRule fires at all for TCP. Please just change the event for the current iRule. No additional iRule required.
ipman_1988_5418
Nimbostratus
Sep 27, 2013
It is behaving the same way. Most packets are blocked but some are getting through. I even applied two of the same irules to this virtual, one with client_accepted and one with client_data. My logging indicated they both were firing and still some items were getting through from countries listed in the data-group list. IDK
What_Lies_Bene1
Cirrostratus
Sep 27, 2013
Are you able to call F5 support? I'd suggest that's a wise next step, sounds like a bug to me. My only though currently is for you to disable CMP for the VS in question and see if the problem still occurs but that may not be possible if you have a high level of traffic.
StephanManthey
MVP
Sep 27, 2013
I agree with W.L.B.. It´s time to involve F5 support now. Make sure to provide some dumps, qkview and steps to repro.

In the meantime I`ve tested a bit including "event disable all" and "return". Another thing I would do is to separate wildcard virtual server. So create a specific one for TCP, UDP and perhaps all protocols in case you want to handle i.e. ICMP, ESP and so on.
ipman_1988_5418
Nimbostratus
Sep 27, 2013
Yeah that's where I'm headed next. I appreciate the responses here. I'll be sure to come back and post a follow up if I find out the root cause.

Forum Discussion

GeoLocation iRule Client_Accepted missing some traffic

27 Replies

Recent Discussions

Converting config to DO

iRule resulting in too many redirects

Wildcard SSL Certificate Deployment on F5 LTM

URL

Big-IP Next 20.2.0-2.375.1+0.0.43 iRule count problem

Related Content

Edge to Pulse: IP Geolocation Database Migration

BIG-IP Geolocation Updates – Part 1

BIG-IP Geolocation Updates – Part 2

BIG-IP Geolocation Updates – Part 3

BIG-IP Geolocation Updates – Part 7