I would also recommend you read Sam's blog post, it should help you understand what is going on.
There's also a historical component to this which may (or may not) be of interest to you.
I've been working with the Sidewinder product since version 5 (1999/2000), though I did have one encounter on site with a customer who was running version 4.
Throughout this time, Sidewinder has been a proxy-based solution with the Firewall being actively involved (as I put it) in handling connections as they pass from one side to another. Occasionally, if the firewall's involvement was too much for the connection (or if you needed to pass non-TCP/UDP protocols) you could configure IP Filter (Packet Filter) rules. Doing do would allow the traffic to pass, but would mean that you were no longer benefitting from the Firewall's ability to inspect and discard incorrectly formed packets.
When v7 came along, the separate proxy rules/filter rules GUI model was amalgamated into a single ruleset GUI and it was the definition of the service which would determine if the rule was going to be proxy based or use a packet filter. There was then a slider bar in the rule screen which, if you had selected a proxy-based service object, would allow you to throttle-back the inspection level to the point where it would operate as a packet filter. If you were using a proxy-based rule, you could apply an application defence to apply specific protocl-level controls to the rule.
When v8 came along this was changed again and the "is it a proxy, or is it a packet filter?" functionality was moved completely into the
into the Application Defense area. The mandatory "Generic" defense is now the place where the decision is taken regarding whether the rule is proxy-based or filter-based, and Sam's blog should tell you all you need to know.
To make life a little easier, McAfee have applied a "default group" setting which allows rules to be created quickly and easily without you needing to think too much about what else is going on. But, depending on whether you are running a brand new v8 appliance or if you are running an appliance which has been upgraded from v7 this setting is actually completely different.
In a fresh v8 installation the <Default Group> entry uses the "connection settings" generic defense, which (unless I'm mistaken) means that all rules on an appliance which has not been upgraded from v7 are in fact packet filters by default - except for those exceptions mentioned in Sam's article.
You were using minimal proxy for your rule and this uses a generic defense which means that the firewall is acting as a transparent proxy (and is therefore 'doing stuff' with the packets as they pass between interfaces). This was clearly enough interference for your Skype connections to fail. But, you then changed the application defense setting to "<Default Group>" and because this has a generic defense that processes the traffic using a much less intrusive packet filtering method, your connections then worked.
If, however, the appliance has been upgraded from v7 to v8 McAfee's mandate was to keep the behaviour of the upgraded Firewall in place. This means that if you look at the default application defense group in an upgraded system the generic defense specified is "minimal proxy" and not "connection settings". So when new rules are added to a system which has been upgraded from v7 to v8 (and if the app defense settings have not be changed) they all behave as proxies.
It is entirely possible that Sam may be able to explain this far more eloquently than I've just tried to...
If the traffic is not going through the proxy on the firewall we don’t do application protocol level inspection. Skype traffic looks similar to SSL but does not confirm to the SSL/TLS standards. If the skype traffic is using SSL/TLS port i.e port 443 firewall proxy treats this as a protocol violation since the traffic doesn't confirm to SSL/TLS standards and denies the traffic.
There is also a KB article KB61791 on this