Home » Kerio User Forums » Kerio Control » Transport layer (TCP,UDP,ICMP) segment size limit
There is, in effect, a default limit on transport layer segment size imposed by Kerio WinRoute and Kerio Control. I use the less common term "transport layer segment size" because this limit affects more than just TCP MSS. It also limits UDP. "Payload" might be a better term because this limit is also imposed on ICMP payload size in the internet layer. In fact, the easiest way to prove this to yourself is by using ping with the -l (length) argument, to control the segment size.
This will produce replies.
Ping -l 8150 firewallIP
This will not.
Ping -l 8151 firewallIP
I you have the ability to generate arbitrary UDP packets you will see that the limit on payload is a little different. UDP containing 8158 bytes will pass. UDP containing 8159 bytes will not.
I should now mention that there is other discussion of this limit on the Forum, along with the usual misinformation. But, these other discussions are largely in relation to performance. And, that is not the concern I describe in my post. If you want to read these other posts, the easiest way to find them is to enter the following in Google.
The confounding aspect of this byte limit is that larger packets are silently discarded by the firewall. There is no log entry telling you that this has occurred. As you can imagine, when we encountered this limit there was a difficult period in which it was not clear whether the network application operating through this firewall was at fault, or, whether it was the firewall itself. In the end we used a sniffer at two location - one operating on the firewall PC and the other operating on a PC in the attached LAN (via hub). Then, by diff'ing the traces we were finally able to see that UDP packets above a certain size were being silently discarded by the firewall.
Yes, by the way, a sniffer operating on the firewall PC will see only what the firewall actually allows 'in'. It will not see everything that arrives at the network interface. (Just something good to know when troubleshooting.)
If you do any similar testing, be aware that - for large transport layer segments - what is actually on the wire are a series of IP fragments, since IP will fragment any transport layer segment that cannot fit into Ethernet's 1500 byte frame size. Ideally, your sniffer needs to be capable of reassembling these fragments, to make your job of testing much easier (for example, Wireshark).
Knowing that packets were being silently discarded was only half the job. Finding a firewall setting which would allow us to control this limit was also difficult. There is nothing in the Kerio admin interface to control this. Likewise, a careful search through the mostly-undocumented settings in the Winroute.cfg file revealed nothing.
Thankfully there is a 5-year-old post on this Forum by a Kerio Technical Support Manager (Joshua Thomas) which gave us the missing clue. It mentions a Windows Registry setting at HKLM\SYSTEM\CurrentControlSet\Services\WRDRV\BufferSize. As the name WRDRV implies, this is a parameter controlling a driver which WinRoute installs.
As this driver has evolved to fit the Windows Driver Model the same parameter is now associated with an upper-level filter driver called kwfupper. The Registry path to the same setting is now HKLM\SYSTEM\CurrentControlSet\Services\kwfupper\Parameters\M axBufferSize.
As Josh says in his post, you can change it to whatever value you like. In IP, the maximum offset for an IP fragment is 65,512 bytes. So, don't go beyond that. I simply doubled the limit from 8192 to 16,384. That was sufficient for all the UDP segments generated by our particular network application to pass. I have not tested the firewall with higher limits. It may not literally accept 65,512. You may have to go a bit lower if you want the max. Setting it higher than necessary may be a performance issue - and, perhaps that is why Kerio set it low to begin with.
Yes, by the way, according to the following article the IP fragment offset is restricted to 8189 (65,512 bytes), not 8192 (65,536 bytes), in case anyone wants to nit-pick.
I would like to add that I have used and recommended WinRoute Pro for a full decade now, ever since version 4.1 build 15, before it was sold to Kerio by its original owner, Tiny Software. I have passed a huge variety of traffic through various installations of this firewall without running into the limit described above. But recently, we were nearly forced to abandon a new rollout of several installations because of this difficult issue, which at first seemed to have no solution.
I cannot understand a business model which allows a situation like this to exist undocumented. I am attempting to document it here because I believe in this product.
[Updated on: Fri, 03 September 2010 20:01]
Kerio discussion forums are intended for open communication between forum
members and may contain information and material posted by members which may
be useful in learning about Kerio products. The discussion forums are not
intended to provide technical support for any specific product. Any
information implied or expressed in the discussion forums is that of the
posting member. Kerio is in no way responsible for the information posted in
the forums, or its accuracy. Kerio employees may participate in the
discussions, but their postings do not represent an offical position of the
company on any issues raised or discussed. Kerio reserves the right to
monitor and maintain the forums to promote free and accurate exchange of
Current Time: Fri Sep 22 04:38:47 CEST 2017
Total time taken to generate the page: 0.00384 seconds