Forum Discussion
ipman_1988_5418
Nimbostratus
NimbostratusGeoLocation iRule Client_Accepted missing some traffic
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
ipman_1988_5418Again this irule is applied to a forwarding (IP) virtual server
source: 0.0.0.0
destination: 0.0.0.0profile fastL4
All ports/protocols
All vlans
What_Lies_Bene1Cirrostratus
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
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_Bene1Thanks 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
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.
Did you already try to change the event into CLIENT_DATA?
Is there a 2nd iRule associated with the virtual server?- ipman_1988_5418
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?
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
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
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.
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
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.
