Unable to use Windows for half minute after each login

So I was part of a software development team that worked on a network security product of a startup company. Before allowing access to the network, the secured product would do some sort of network access control by asking the user for access credentials--some sort of captive portal. The issue observed was that when user accesses network using Windows as client side access platform, the network equipment to which this client was connected would prevent further access to the PC for at least half a minute. For example, if one starts a Web browser, that would freeze the graphical user interface shell of Windows for about 30 seconds. Would not interact with the user until the browser opens after half a minute. This would be repeated for any program that attempts to access network. This problem would persist until user is authenticated for network access. For the same thing, an ordinary non-secured equipment would not even let the user feel its presence in the network--meaning no delays in letting access to any network resources, or the user's own PC.

Before releasing the product, it was being used internally within the development labs. There were more than hundred software development engineers and testers as users connected to the network through this security product. Apparently no one complained about or tried to find out why this half a minute delay and just moved on to accept it as a 'fact of life'...

I could not take it any more; more so as one of the members in the development team of the product. I started my analysis by thinking about what happens between the Windows GUI shell coming up and the user invoking a program that attempts to access network. I knew network traffic from Windows is quite chatty thanks to SMB and NBNS. Using common sense, I suggested to let the network equipment to explicitly send connection reject message for all network access attempts from the network interface of an unauthenticated user. Earlier the equipment was configured to simply discard such traffic. The common sense paid off! Until authenticated for network access control, the user would not have access to network--the desired behavior but that would not prevent a user from interacting further with their OS shell.

When unauthenticated traffic was silently dropped, the chatty protocols from user's client PC would keep retrying until their preconfigured time out occurs, which in this case was half a minute. Issue resolved without a single line change in software source code. Phew! Needless to say I was quite happy that day.