Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been challenged to "improve Skype performance" for calls within my organisation.

Having read the Skype IT Administrators Guide I am wondering whether we might have a performance issue where the Skype Clients in a call are all on our WAN.

The call is initiated by a Skype Client at our head office, and terminated on a Skype Client in a remote office connected via IPSEC VPN.

Where this happens, I assume the trafficfrom Client A (encrypted by Skype) goes to our ASA 5510, where it is furtehr encrypted, sent to the remote ASA 5505 decrypted, then passed to Client B which decrypts the Skype encryption.

Would the call quality benefit if the traffic didn't go over the VPN, but instead only relied on Skype's encryption? I imagine I could achieve this by setting up a SOCKS5 proxy in our HQ DMZ for Skype traffic.

Then the traffic goes from Client A to Proxy, over the Skype relay network, then arrives at Cisco ASA 5505 as any other internet traffic, and then to Client B.

Is there likely to be any performance benefit in doing this? If so, is there a way to do it that doesn't require a proxy?

Has anyone else tackled this?

share|improve this question

IPSEC VPNs will definitely degrade performance, both because of the encryption processing, and the reliance on TCP. If you have the licenses to support it, you could try SSL VPN between the two ASAs, which with TLS, could improve performance some (UDP).

I'm not familiar with Skype traffic or SOCKS5 proxies, but I'm not sure why that step would be necessary, as you say that Skype is already encrypting the traffic. To improve performance, you'd want to eliminate hops & processing. Find out what ports Skype relies on and create a rule to allow them through the ASAs without being caught by your IPSEC VPN policy. Likely this may involve some unNATs as well.

share|improve this answer
+1 for IPSEC info and SSL suggestion (although we haven't got the licenses) - unfortunately Skype doesn't use ports consistently or make it easy to identify its traffic - it was designed to get around firewalls. – dunxd Jul 12 '12 at 11:06

Not sure if your understanding of how Skype works is correct.

Skype calls aren't initiated and terminated between users in the same way as a normal TCP conversation would take place.

Each Skype client registers its location with Skype's central servers. When one user calls another user, the initiating client asks where the target client is, and the initiating client then starts streaming UDP (or relayed UDP, or sometimes even TCP) to the terminating client.

However, because all of this has to involve an independent public Skype host, all of this communication will happen over the public internet, rather than over your VPN.

To get Skype to flow over a VPN is very difficult, because once Skype can find a way to the Internet, it will always flow that way, regardless of whether you configure it to use a proxy.

You would need to source route Skype traffic on your network device so that it is blocked from accessing the Internet, and then proxy it to a server on the other side of your VPN, and vice versa, which clearly is a whole lotta pain.

Bottom line is that Skype probably is never going to use your VPN.

Most likely you performance issue is cause by Skype not being able to punch a whole in your firewall to do pure UDP, and reverts to Relayed UDP or TCP.

One quick win is to allow all UDP in and out of your firewall, but that still doesn't guarantee pure UDP. That will depend on how congested your Port Address Translation is.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.