GeoLocation iRule Client_Accepted missing some traffic

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 }

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.

The firewall is dropping because of it's drop any any rule. Has nothing to do with geolocation. I just use that as a way of seeing what is getting past the F5. The firewall is the next hop in. I simply applied a filter to the firewall log with several class A ranges from countries I know should be blocked at the F5 and I see traffic getting past the LTM. So I'm just trying to figure out why. Perhaps the client_accepted event isn't firing?

So, perhaps your subnets are not matched by the F5, that's still a big issue here. Perhaps add this to your iRule in an appropriate place to log this, creating a DG with what you believe are the class A's you shouldn't see. Perhaps you and the F5database disagree, how recent is it anyway?;

elseif { if class match [IP::client_addr] equals 'some_data_group' } {
 log local0. "Allowed apparent blocked IP from this place: [whereis [IP::client_addr] country]"
}

How about verifying the passing IPs versus the GeoIP db?

 geoip_update_data geoip-data-ISP-1.0.1-20130905.67.0.i686.rpm
 geoip_update_data geoip-data-Org-1.0.1-20130905.67.0.i686.rpm
 geoip_update_data geoip-data-Region2-1.0.1-20130905.67.0.i686.rpm
 geoip_update_data geoip-data-v6-1.0.1-20130905.67.0.i686.rpm

Now run a lookup from CLI:

 geoip_lookup 80.1.1.1
opening database in ./F5GeoIP.dat
size of geoip database = 69751866, version = GEO-148 20130905 Build 1 Copyright (c) F5 Networks Inc All Rights Reserved
geoip_seek = 00c05b4d
geoip record ip = 80.1.1.1
country_code = GB
country_name = United Kingdom
region_name = Manchester

I guess I should have clarified some things.

I'm not using Class A networks in my data groups. I'm using country codes and it's working. I was using Class A networks as a filter in my firewall logs just to see what was slipping by my irule.

My Geo database is from June this year (geoip-data-v6-1.0.1-20130606.63.0.i686.rpm) and I have confirmed that the IP addresses getting past the iRule match for countries that should be blocked based on the data-group list. ie, a CN China address got through 37.247.36.83 I confirmed this by using the geoip_lookup tool. I can update the database but that's not the issue here obviously.

I do have logging available in this irule. I simply removed all of the logging code to simplify the posting. Specifically I log (when enabled)

log local0. "[whereis [IP::client_addr] country] [IP::client_addr] to DST ADDR [IP::local_addr] DST Port [TCP::local_port] SRC Port [TCP::remote_port] matched against blockedoverseas"

That's correct and I may try your suggestion. So it's simply, return ?

I went and looked it up.

return and event "event_name" disable

Well, I just got this entry in my firewall. It's resolving to an Argentina address which is the first country in my block list.

The packet that came through was udp port 1434 ms-sql source port 3176

size of geoip database = 60519510, version = GEO-148 20130606 Build 1 Copyright (c) F5 Networks Inc All Rights Reserved

I added return to each elseif section right after the drop statement.

I still have a feeling that there's something in the connection table that prevents the client_accepted event to fire for some reason IDK