CPUG

The Check Point User Group

A Resource For The Check Point Community.  Fast.  Useful.  Independent.

1. CCSA/CCSE One-Week Dual-Certification Training Course with CPUG in San Francisco!
    Courses Starting 12/8, (2009) 1/19, 2/9, 3/9, 4/6, 5/4, 6/8, 7/6, 8/3.
2. Join Us On LinkedIn - We now have a CPUG group.


Go Back   CPUG: The Check Point User Group > Check Point Firewall-1/VPN-1 And Related Products > SmartDefense
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 2006-12-11
Member
 
Join Date: 2006-06-06
Posts: 72
Rep Power: 3
lowfell has an average reputation (10+)
Default IP Fragment settings

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?
Reply With Quote
  #2 (permalink)  
Old 2006-12-11
Senior Member
 
Join Date: 2006-07-28
Location: New Zealand
Posts: 857
Rep Power: 3
northlandboy has an average reputation (10+)
Default Re: IP Fragment settings

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.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


All times are GMT -7. The time now is 11:06.


Powered by vBulletin® Version 3.7.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.2.0