OpenSolaris

Printable Version Enter a New Search
Bug ID 6531894
Synopsis IPF blocks TCP SYN packets for connections in TIME_WAIT state -> some clients can't reconnect
State 10-Fix Delivered (Fix available in build)
Category:Subcategory network:ipfilter
Keywords rtiq_reviewed | spbc_s10u5_sustaining | sunalert-submit-availability
Responsible Engineer Alexandr Nedvedicky
Reported Against solaris_10
Duplicate Of
Introduced In solaris_nevada
Commit to Fix snv_67
Fixed In snv_67
Release Fixed solaris_nevada(snv_67) , solaris_10u5(s10u5_06) (Bug ID:2147530)
Related Bugs 6533896
Submit Date 7-March-2007
Last Update Date 16-January-2008
Description
Since 125014-02 ipf sometimes blocks internal pkts which should pass.
During this problem, 'ipfilter -T list' doesn't show a lack of resources.
The state table remains at max 3% occupied.
After a backout of 125014-02, the problem was resolved.
"ipf sometimes blocks internal pkts which should pass" Is inherently bad CR description. In fact it is the same statement as one would say ,,my car does not start sometimes''. It is impossible to figure out a cause from such short description since it coveres many possible causes. I'm going to change it to reflect a fix, which will be provided. New description "IPF blocks TCP SYN packets for connections in TIME_WAIT state -> some clients can't reconnect". I agree no one would figure out that statement
in time of filing that bug. IMHO it is not a good practice to keep such generic records, one must see it at glanc in synopsis what's going on.

The IPF state filter blocks SYN packets for given connection once it is established.
This state lasts until connection is properly closed or timeouts.  There are some clients, which improperly reuse source port in time wait state to reconnect to service again (Imagine web browser, which would use the same source port for every request). those clients are not able to reconnect through IPF, since IPF keeps connection state and drops all SYN packets for connection until it reaches CLOSED state.

The fix works as follows: once IPF sees a SYN packet for connection, which is not in ESTABLISHED state it moves connection state to internal Deleted state and drops the fist SYN packet. while client retransmits SYN packet again everything already works and new state table entry is created.
the IPF log will record SYN packets dropped due to out of window (OOW). so any time you see SYN packets blocked with reason OOW, you can be absolutely sure, you are experiencing this bug.
Work Around
advise customers not to use stateful rules, those with 'keep-state' keyword.
Comments
N/A