| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| I have had an issue where Remote Access users come in via Secureclient. occasionly they lose their RDP connection to the whicheverr box, but the tunnel stays up. This could be an issue with the SmartDefense IP fragments setting which has been set to Maximum number of incomplete packets allowed = 200 Discard incomplete packets after 1 second DOES ANYONE KNOW WHAT THE RECOMMENDED SETTINGS FOR THIS ARE & WHIC ONE SHOULD i ADJUST? |
| |||
| Check Point would say that the recommended settings are what the defaults are. Remember how Check Point deals with fragments - it needs to collect those fragments in memory, and reassemble the packets, so it can inspect them, before passing them out again, as it received them (i.e. fragmented). So those settings say that if it receives fragments, it will store 200 (I think per connection) and store them for a maximum of 1 second. If it doesn't receive any more fragments after 1 second, it discards all fragments it had stored. On a modern high speed network, that's usually OK. However I've had problems with this in the past, in particular with slow, high latency links - e.g. GPRS. The interesting thing is that they changed the defaults at around R54. It used to be a minute that the module would keep fragments for before discarding them. The error message still refers to fragments not received within a 60s timeout (might be fixed at NGX though, haven't tested it). Then they dropped it right down, which can cause the sorts of problems you're seeing. I increased the timeout to 10s, and that dealt with problem I had. It's a tradeoff between dropping legitimate traffic, and having a higher risk of an attacker filling up those buffers with fragments. Your call. If it was my network, I would increase the timeout to 10s. You may still wish to pursue the MTU path though - fragments are, afterall, an indication that source is sending packets with a larger MTU than is allowed by the VPN tunnel. You could advise users to reduce their MTU. Possibly a better solution though, is to make sure that you allow ICMP path discovery to your firewall, to help clients try and work it out automatically. |
![]() |
| Thread Tools | |
| Display Modes | |
| |