This document describes an implementation where only certain users are allowed to use Consumer Skype. Other articles are available which can control Consumer Skype access by client IP address;however, if user-based access control to Consumer Skype is required, you can use SOCKS to do so (post-SGOS 5.5.x versions no longer allow this directly through Visual Policy Manager). SOCKS simplifies the process and is also more reliable, although some manual configuration of Consumer Skype client is also needed, so the process is not completely transparent to the end user. This document also presents caveats and security considerations.

Note that the following implementation is just an example; you might need to tailor the process to suit your exact business needs.

Configure the Firewall / Packet Filtering

Consumer Skype tries multiple methods to connect to the Internet. In most secure environments, the organization’s firewall is configured to block all outbound traffic except for the traffic that comes from the proxy. At a very basic level, your firewall should be configured as follows:

permit ip host 10.91.25.10 any

deny ip any any

where 10.91.25.10 is the IP address of the proxy. This configuration allows only the proxy to communicate externally and prevents Skype from bypassing the proxy.

Proxy Configuration

Note: This document assumes that a working authentication realm is configured on the proxy. In this scenario, an IWA realm using BCAAA has been previously configured.

1. In the Management Console, select Configuration > Services > Proxy Services. By default, a service named “SOCKS” is already present, but set to bypass. Set this to Intercept. If no SOCKS service is present, create a service using the SOCKS proxy as follows:

Enabling Detect Protocol allows you more granular control later, but if you enable this, also enable the TCP tunnel requests when a protocol error is detected option (Configuration > Proxy Settings > General).  Consumer Skype uses non-standard traffic that must be tunneled in any case.

2. Open the VPM and create a new SOCKS Authentication Layer. Create a rule similar to the following: 

The “SOCKSAuthenticate” is a “SOCKS Authenticate…” option, using the previously created IWA realm.

3. Ensure that if a Web Access layer is present, there should be no rules denying known Skype IP addresses, or any rules that can interfere with Consumer Skype connectivity (for example, denying skype.com).

Configure Consumer Skype Client

At the time of writing, Consumer Skype natively supports SOCKS proxies. To enable this functionality in Skype, select Tools > Advanced > Connection.

Select the SOCKS5 option and enter the appropriate information including the user credentials, as follows:

Consumer Skype should now be able to connect, but if no username and password is provided, connectivity is denied.

Security Considerations

• SOCKS passes user authentication in clear text. Appropriate considerations must be taken. For example, if the network between client and proxy is not trusted, do not use this method. Use IPSec VPNs and other safeguards.

• Enabling SOCKS proxy does give the opportunity for tech-savvy users to use the SOCKS proxy to tunnel other traffic, such as SSH, telnet, or web traffic. The ProxySG is able to limit what can pass through the SOCKS proxy via the Web Access Layer. For example, best practices in security prefer the principle of least privilege. Skype makes this difficult due to its P2P nature; it connects to many different IPs using many different port numbers. However, at the very least, it is possible to block misuse of SOCKS to tunnel SSH or telnet or other undesirable traffic. To do so, create a Web Access Layer and create a rule as follows:

The source and destination object can be modified as appropriate. In the previous example, the destination object is port 23 (telnet), and service has a client protocol of all SOCKS:

This denies connections to telnet servers through SOCKS. 
If protocol detect is enabled, any web access rules you define pertaining to content filtering should still work (though most browsers do not support SOCKS with authentication).