Forum Discussion
steelplate_8766
May 25, 2010Nimbostratus
sNAT to Windows server and port collision
Hi,
I have an F5 doing sNAT, and the problem I face is that the windows server keeps the port in time_wait (currently default 240 seconds windows 2003 server). The F5 will attempt to reuse the client port within that interval and as it causes a port collision, the syn's don't even get ack's.
Windows is doing a full tcp port close (fin,ack with ack response in both directions), so the f5 deems it ok to reuse the port.
My understanding is that the f5 shouldn't try to reuse this port for 2MSL , but where can I find the default MSL for the F5, as I should make windows TCPTimedWaitDelay =< the f5 2MSL ?
I tried setting the f5 to always change client port, as this should have caused the f5 to use a new port that wasn't in use, but instead it makes the problem worse, I see the f5 use try to reuse the changed client port in < 1 second, again I assume this is because the f5 sees a full close.
How have other users dealt with this problem as it must have effected many other users.
14 Replies
Sort By
- Do you have a OneConnect Profile applied to the Virutal Server that you are having this problem with?
- You should be able to modify this behavior with a custom TCP profile. See this post from Deb for more info on OneConnect and the TCP profile options (and a few related solutions):
- Sorry for delay, have turned on alerts so I see replies now :-)
- I've had this port collision issue as well on a application we load balance that involves very short lived connections.
- tcp_close timer shouldn't make any difference in my case anyway
- I have been reading RFC 1337 , TIME-WAIT Assassination Hazards, and running some direct to windows server tests (no f5) can see port reuse successful within the time_wait period, due to MS implementing this feature.
- Are you translating or preserving client source ports?
- we are preserve ports (NOT strict).
- Disable the preserving of ports... I suspect strict vs non-strict is simply a matter of is it open or not already. And ignores 2xMSL completely...
- I tried setting the f5 to always change client port, as this should have caused the f5 to use a new port that wasn't in use, but instead it makes the problem worse, I see the f5 use try to reuse the changed client port in < 1 second, again I assume this is because the f5 sees a full close.
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects