Share via


SSTP VPN connection is slower than PPTP?

Question

Friday, October 16, 2009 12:24 AM

I setup an R2 2008 server with RRAS that has one NIC directly connected to the Internet and the other to the LAN.  I did this as I would like to setup DirectAccess as well.  The VPN works great when connected using PPTP.  When using SSTP the connection becomes very slow.  The PPTP connection is 5x faster than SSTP.  I can access network resources over SSTP, it does work.  I was just wondering if it is supposed to be slower than PPTP.  I've looked through as many logs as possible and there doesn't appear to be anything wrong.  Is this normal? 

All replies (6)

Friday, October 16, 2009 9:09 AM

Hello,

 

Thank you for your post here.

 

As far as I know, SSTP Performance is almost as same as PPTP VPN with the exception of the connect time. A SSTP connection attempt will take more time than PPTP VPN connection.

 

For a better understand of your concern, could you please answer the following questions:

1. What is "slow" in SSTP VPN connection? Do you mean the connection or the communication speed over SSTP connection?

 

2. If you have a concern about the communication speed over SSTP connection, could you please double check whether the "slow" speed is protocol related? In the other word, does the SSTP always be slow if you test it with other protocol such as FTP and etc.

 

3. If you have the concern about the connection attempt speed of SSTP connection, I believe that it should be expected that SSTP connection will take more time than PPTP because SSTP counts on certificate for authentication and certificate needs to be verified whether it is revoked (CRL) before the TLS is nogociated.

 

If you have any questions or concerns, please do not hesitate to let me know

 

 

 


Tuesday, October 27, 2009 6:47 PM

I'd like to second this.  Last week I implemented PPTP, SSTP, and IKEv2 on 2008R2.  PPTP and IKEv2 work well.  SSTP not only takes a long time to connect, but the the performance is so slow as to be unusable.  I didn't actually check to see if the problem was bandwidth or latency, but the keyboard latency on RDP is several seconds.

The actual implemenation is a single-NIC 2008R2 running as a VM under a 2008x64 virtual host.  All traffic is sent through our central firewall and then routed into the VPN.  Traffic comes back onto the LAN through the same NIC.

For reference, I also have OpenVPN running on this same box/NIC/firewall, and it suffers none of the performance problems of SSTP.

One other thing, I realize that SSTP authentication should take a little longer, but it seems to take a VERY long time.  Normal SSL websites show very little slowdown due to authentication.  IKEv2 takes 1-3 seconds to authenticate.  SSTP takes 5-15 seconds.

At this point, SSTP seems unusable.


Monday, February 1, 2010 9:29 PM | 1 vote

What anti-virus program are you running?

I've seen this exact problem and it turns out that ESET NOD32 is definitely the culprit. We have one client using this and this is the procedure he went through to resolve the problem:

1)  Protocol filtering -> SSL and change filtering mode to "Always scan SSL protocol."
2)  Web access protection -> HTTP,HTTPS change HTTPS filtering mode to "Do not use HTTPS protocol checking."

Please try these steps and report back your findings.


Wednesday, July 28, 2010 6:38 PM

What anti-virus program are you running?

I've seen this exact problem and it turns out that ESET NOD32 is definitely the culprit. We have one client using this and this is the procedure he went through to resolve the problem:

1)  Protocol filtering -> SSL and change filtering mode to "Always scan SSL protocol."
2)  Web access protection -> HTTP,HTTPS change HTTPS filtering mode to "Do not use HTTPS protocol checking."

Please try these steps and report back your findings.

This really sped things up for me. Folder browsing is not as fast as unencrypted FTP, but it's not much slower and fully encrypted. NOD32 is great, but they really need to work on a few things, like breaking pop3 connectivity and of course now this ssl issue.


Thursday, July 29, 2010 12:12 AM

I setup an R2 2008 server with RRAS that has one NIC directly connected to the Internet and the other to the LAN.  I did this as I would like to setup DirectAccess as well.  The VPN works great when connected using PPTP.  When using SSTP the connection becomes very slow.  The PPTP connection is 5x faster than SSTP.  I can access network resources over SSTP, it does work.  I was just wondering if it is supposed to be slower than PPTP.  I've looked through as many logs as possible and there doesn't appear to be anything wrong.  Is this normal? 

Have you inspected the Processor utilization on the RRAS server?

Typically you're dealing with more than a single password or "sychronous" key with PPTP or L2TP rather than using SSL which uses Asychronous keys to encrypt the message. Because of this additional calculation needed for SSL and level of encrypted messages, you have overhead of data transfers between the client system and the host system. The extra delay you're experience is due to SSL negotiations.

Remember the CIA triad, when you add confidentiality, it tips the ballast for availability. More secure will always be more slow. SSTP has it's pros and cons... pick one that works for you. Alternative options are options like Two-Factor authentication which allows you to use PINs, Tokens, additional to usernames and passwords to authenticate to a radius and token generating server.

Here's a test:

Connect with 2 clients using L2TP or PPTP or 1 of each protocol. Check your processor and network loads. Run at least 30-60 seconds of processor monitoring from the start of the authentication to the disconnect. You should test with a transfer of a single test document to a server and disconnect from the VPN.

Delete the files off the server so you don't get any type of processor delay for "overwrite" prompts.

THEN --

Connect with 2 clients using SSTP. Run the same analysis, transfer the same files again. Viewing processor and network loads. Compare the two on a timeline.

Steve Kline - MCITP
This posting is "as is" without warranties and confers no rights.


Thursday, July 29, 2010 3:18 AM

It was Nod32 scanning the stream.  Problem solved.