Server downlink is 30-40 Mbit/s, uplink is 20 Mbit/s, ethernet to optical concentrator. Client has ADSL downlink 5 Mbit/s, uplink 400 Kbit/s, and is behind a NAT router that is used to establish a PPPoE connection over the ADSL line. I have a working IPSec rule between Win2003ent-SP2 server and XP-SP3 client. I did some benchmark: large file download over HTTP port 80 (client downloads from server): ~ With IPSec rule disabled, download speed is about 380 KBytes/s for 1 TCP session and about 480 Kbytes/s for 6 simultaneous sessions (FlashGET). ~ With IPSec rule ENABLED, download speed is 100 KBytes/s for both 1 and 6 TCP simultaneous sessions (FlashGET). Sometimes it gets as low as 30 KBytes/s. I sent some large ICMP packets (1450 bytes) to measure the delay: Minimum = 46ms, Maximum = 51ms, Average = 48ms and this is the default size ping (32 bytes): Minimum = 22ms, Maximum = 27ms, Average = 24ms Note 1: I do need IPSec, because the actual ports that will go over IPSec are those used for File and Printer Sharing. Most ISPs are blocking these ports, so I am using IPSec to workaround that restriction. Note 2: If I establish a VPN link to the server with IPSec enabled on RRAS, the HTTP download speed is about 100 KBytes/s for both 1 and 6 TCP sessions. Still not good enough. IPSec rule configuration: ~ Authentication Mothod: preshared key ~ Tunnel Setting: This rule does not specify an IPSec tunnel ~ Connection Type: All network connections ~ Filter list: to server IP:TCP port 80 ~ Filter action: Negotiate security: Data integrity and encryption (ESP); SHA1+3DES. Question: ------------------------------------------ What can I do to speed the IPSec connection? Thank You for any help! George Valkov
Thank You Anthony! The problem magically disappeared... Well after a long call to the ISP... Most people at BTC.bg are truly lame so their network is troublesome (I've seen how two of the team are sitting doing nothing while the third is doing all the job), fortunately there are a few good professionals ;-) Or it could simply be that their network is less overloaded at 2 AM. I'll test it again and see if it is still stable tomorrow. Good Night! By the way DES + MD5 truly improves the situation when talking about speeds like 100 Mbits/s on the LAN effectively reducing the CPU load. George Valkov | You could try DES + MD5 | Anthony | http://www.airdesk.com | | | | | | > Server downlink is 30-40 Mbit/s, uplink is 20 Mbit/s, ethernet to optical | > concentrator. | > Client has ADSL downlink 5 Mbit/s, uplink 400 Kbit/s, and is behind a NAT | > router that is used to establish a PPPoE connection over the ADSL line. | > | > I have a working IPSec rule between Win2003ent-SP2 server and XP-SP3 | > client. | > | > I did some benchmark: large file download over HTTP port 80 (client | > downloads from server): | > ~ With IPSec rule disabled, download speed is about 380 KBytes/s for 1 TCP | > session and about 480 Kbytes/s for 6 simultaneous sessions (FlashGET). | > ~ With IPSec rule ENABLED, download speed is 100 KBytes/s for both 1 and 6 | > TCP simultaneous sessions (FlashGET). Sometimes it gets as low as 30 | > KBytes/s. | > | > I sent some large ICMP packets (1450 bytes) to measure the delay: | > Minimum = 46ms, Maximum = 51ms, Average = 48ms | > | > and this is the default size ping (32 bytes): | > Minimum = 22ms, Maximum = 27ms, Average = 24ms | > | > | > Note 1: | > I do need IPSec, because the actual ports that will go over IPSec are | > those | > used for File and Printer Sharing. Most ISPs are blocking these ports, so | > I | > am using IPSec to workaround that restriction. | > | > Note 2: | > If I establish a VPN link to the server with IPSec enabled on RRAS, the | > HTTP | > download speed is about 100 KBytes/s for both 1 and 6 TCP sessions. Still | > not good enough. | > | > IPSec rule configuration: | > ~ Authentication Mothod: preshared key | > ~ Tunnel Setting: This rule does not specify an IPSec tunnel | > ~ Connection Type: All network connections | > ~ Filter list: to server IP:TCP port 80 | > ~ Filter action: Negotiate security: Data integrity and encryption (ESP); | > SHA1+3DES. | > | > | > | > Question: | > ------------------------------------------ | > What can I do to speed the IPSec connection? | > | > | > Thank You for any help! | > George Valkov | > | >
Hello Anthony, I apologize for the delay! the power network went down for the entire day after a storm. It seems that the link over ESP runs at normal speed during the night, but is several times slower than the standard TCP connections during the day. The support team from my ISP were puzzled on that too (I had a talk to them on the phone a few times). One person from the support said that the 9% packet loss (ICMP) is normal for ADSL, and that ADSL is only meant for browsing. The loss is also present at night time, but I've not compared percentage. On the packet capture however it looks really bad (that's captured on the VPN interface between client and server): http://www.mediafire.com/file/zuywzojyjmm/2009-08-06-btc-retransmition.cap Use Wireshark to view the capture file: http://www.wireshark.org/ And it doesn't matter what signing or cryptography algorithms I select, because the client and the server are not overloaded by the additional processing, but have plenty of free CPU cycles. Either way I had the same bad performance for ESP traffic, while the TCP traffic was fast and the speed was stable for it. (I used to enable and disable the IPSec rule to switch between TCP 80 traffic and the same traffic packed and sent over ESP protocol, so that I can compare the speed of file download over HTTP). Perhaps I should call the other ISP that offers 20 Mbit/s uplink on the server and ask if they have some restrictions for ESP traffic. But something makes me think that the packet loss and weather conditions somehow affect the ADSL line quality. I think might be near it's error rate limit. George Valkov | George, | What did the ISP change? | Anthony, | http://www.airdesk.com | | | | > Thank You Anthony! | > | > The problem magically disappeared... Well after a long call to the ISP... | > Most people at BTC.bg are truly lame so their network is troublesome (I've | > seen how two of the team are sitting doing nothing while the third is | > doing | > all the job), fortunately there are a few good professionals ;-) Or it | > could | > simply be that their network is less overloaded at 2 AM. I'll test it | > again | > and see if it is still stable tomorrow. Good Night! | > | > By the way DES + MD5 truly improves the situation when talking about | > speeds | > like 100 Mbits/s on the LAN effectively reducing the CPU load. | > | > George Valkov | > | > | > | > | You could try DES + MD5 | > | Anthony | > | http://www.airdesk.com | > | | > | | > | | > | | > | | > | > Server downlink is 30-40 Mbit/s, uplink is 20 Mbit/s, ethernet to | > optical | > | > concentrator. | > | > Client has ADSL downlink 5 Mbit/s, uplink 400 Kbit/s, and is behind a | > NAT | > | > router that is used to establish a PPPoE connection over the ADSL | > line. | > | > | > | > I have a working IPSec rule between Win2003ent-SP2 server and XP-SP3 | > | > client. | > | > | > | > I did some benchmark: large file download over HTTP port 80 (client | > | > downloads from server): | > | > ~ With IPSec rule disabled, download speed is about 380 KBytes/s for 1 | > TCP | > | > session and about 480 Kbytes/s for 6 simultaneous sessions (FlashGET). | > | > ~ With IPSec rule ENABLED, download speed is 100 KBytes/s for both 1 | > and | > 6 | > | > TCP simultaneous sessions (FlashGET). Sometimes it gets as low as 30 | > | > KBytes/s. | > | > | > | > I sent some large ICMP packets (1450 bytes) to measure the delay: | > | > Minimum = 46ms, Maximum = 51ms, Average = 48ms | > | > | > | > and this is the default size ping (32 bytes): | > | > Minimum = 22ms, Maximum = 27ms, Average = 24ms | > | > | > | > | > | > Note 1: | > | > I do need IPSec, because the actual ports that will go over IPSec are | > | > those | > | > used for File and Printer Sharing. Most ISPs are blocking these ports, | > so | > | > I | > | > am using IPSec to workaround that restriction. | > | > | > | > Note 2: | > | > If I establish a VPN link to the server with IPSec enabled on RRAS, | > the | > | > HTTP | > | > download speed is about 100 KBytes/s for both 1 and 6 TCP sessions. | > Still | > | > not good enough. | > | > | > | > IPSec rule configuration: | > | > ~ Authentication Mothod: preshared key | > | > ~ Tunnel Setting: This rule does not specify an IPSec tunnel | > | > ~ Connection Type: All network connections | > | > ~ Filter list: to server IP:TCP port 80 | > | > ~ Filter action: Negotiate security: Data integrity and encryption | > (ESP); | > | > SHA1+3DES. | > | > | > | > | > | > | > | > Question: | > | > ------------------------------------------ | > | > What can I do to speed the IPSec connection? | > | > | > | > | > | > Thank You for any help! | > | > George Valkov | > | > | > | > | > | >
It could be a bad layer 2 connected to your location. ADSL uses existing copper, and if the phone lines are marginal, so will any service coming across them. If I remember correctly, we were discussing the limitations with your ISP (in Hungary?) a while back. This may possibly be related. -- Ace This posting is provided "AS-IS" with no warranties or guarantees and confers no rights. Please reply back to the newsgroup or forum to benefit from collaboration among responding engineers, and to help others benefit from your resolution. Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging Microsoft Certified Trainer For urgent issues, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.
| | > Hello Anthony, I apologize for the delay! the power network went down for | > the entire day after a storm. | > | > It seems that the link over ESP runs at normal speed during the night, but | > is several times slower than the standard TCP connections during the day. | > The support team from my ISP were puzzled on that too (I had a talk to | > them | > on the phone a few times). | > | > One person from the support said that the 9% packet loss (ICMP) is normal | > for ADSL, and that ADSL is only meant for browsing. The loss is also | > present | > at night time, but I've not compared percentage. | > | > On the packet capture however it looks really bad (that's captured on the | > VPN interface between client and server): | > http://www.mediafire.com/file/zuywzojyjmm/2009-08-06-btc-retransmition.cap | > | > Use Wireshark to view the capture file: | > http://www.wireshark.org/ | > | > And it doesn't matter what signing or cryptography algorithms I select, | > because the client and the server are not overloaded by the additional | > processing, but have plenty of free CPU cycles. Either way I had the same | > bad performance for ESP traffic, while the TCP traffic was fast and the | > speed was stable for it. (I used to enable and disable the IPSec rule to | > switch between TCP 80 traffic and the same traffic packed and sent over | > ESP | > protocol, so that I can compare the speed of file download over HTTP). | > | > Perhaps I should call the other ISP that offers 20 Mbit/s uplink on the | > server and ask if they have some restrictions for ESP traffic. But | > something | > makes me think that the packet loss and weather conditions somehow affect | > the ADSL line quality. I think might be near it's error rate limit. | > | > | > George Valkov I had a talk to Megalan - the ISP on the server, they have no restrictions on ESP. And speedtest.net indicates 26 Mbit/s up; 60 Mbit/s down They only block the ports for File and Printer Sharing to prevent viruses from spreading among their clients. Which is why I started using either ESP or L2TP IPSec VPN (basicly ESP again) as a workaround, that way actually is much better over the insecure Internet, than the direct TCP traffic. | It could be a bad layer 2 connected to your location. ADSL uses existing | copper, and if the phone lines are marginal, so will any service coming | across them. If I remember correctly, we were discussing the limitations | with your ISP (in Hungary?) a while back. This may possibly be related. I agree, it most probably is bad L2. The last 0.5 kilometers of the phone lines are only 2-3 years old, but the location is pretty far: may be about 5-6 km. The link is operating near the end of it's speed limmit and is not very stable. That's what the ADSL modem indicates: http://www.mediafire.com/file/cdmuzzimmn2/2009-08-07-infodsl2.htm By the way, another company started offering all-in-one Cable+Internet+Phone services, the optical cable is about 100 m away... Only I'll have to wait until the current contract expires ;-) In Bulgaria George Valkov
Ah, Bulgaria! My apologies. I think fiber is worth the wait. In the meantime, hang in there with your current limitations. Ace
| | > | > | > | | > | > Hello Anthony, I apologize for the delay! the power network went down | > for | > | > the entire day after a storm. | > | > | > | > It seems that the link over ESP runs at normal speed during the night, | > but | > | > is several times slower than the standard TCP connections during the | > day. | > | > The support team from my ISP were puzzled on that too (I had a talk to | > | > them | > | > on the phone a few times). | > | > | > | > One person from the support said that the 9% packet loss (ICMP) is | > normal | > | > for ADSL, and that ADSL is only meant for browsing. The loss is also | > | > present | > | > at night time, but I've not compared percentage. | > | > | > | > On the packet capture however it looks really bad (that's captured on | > the | > | > VPN interface between client and server): | > | > | > http://www.mediafire.com/file/zuywzojyjmm/2009-08-06-btc-retransmition.cap | > | > | > | > Use Wireshark to view the capture file: | > | > http://www.wireshark.org/ | > | > | > | > And it doesn't matter what signing or cryptography algorithms I | > select, | > | > because the client and the server are not overloaded by the additional | > | > processing, but have plenty of free CPU cycles. Either way I had the | > same | > | > bad performance for ESP traffic, while the TCP traffic was fast and | > the | > | > speed was stable for it. (I used to enable and disable the IPSec rule | > to | > | > switch between TCP 80 traffic and the same traffic packed and sent | > over | > | > ESP | > | > protocol, so that I can compare the speed of file download over HTTP). | > | > | > | > Perhaps I should call the other ISP that offers 20 Mbit/s uplink on | > the | > | > server and ask if they have some restrictions for ESP traffic. But | > | > something | > | > makes me think that the packet loss and weather conditions somehow | > affect | > | > the ADSL line quality. I think might be near it's error rate limit. | > | > | > | > | > | > George Valkov | > | > I had a talk to Megalan - the ISP on the server, they have no restrictions | > on ESP. And speedtest.net indicates 26 Mbit/s up; 60 Mbit/s down | > They only block the ports for File and Printer Sharing to prevent viruses | > from spreading among their clients. Which is why I started using either | > ESP | > or L2TP IPSec VPN (basicly ESP again) as a workaround, that way actually | > is | > much better over the insecure Internet, than the direct TCP traffic. | > | > | > | It could be a bad layer 2 connected to your location. ADSL uses existing | > | copper, and if the phone lines are marginal, so will any service coming | > | across them. If I remember correctly, we were discussing the limitations | > | with your ISP (in Hungary?) a while back. This may possibly be related. | > | > I agree, it most probably is bad L2. The last 0.5 kilometers of the phone | > lines are only 2-3 years old, but the location is pretty far: may be about | > 5-6 km. The link is operating near the end of it's speed limmit and is not | > very stable. That's what the ADSL modem indicates: | > http://www.mediafire.com/file/cdmuzzimmn2/2009-08-07-infodsl2.htm | > | > By the way, another company started offering all-in-one | > Cable+Internet+Phone | > services, the optical cable is about 100 m away... Only I'll have to wait | > until the current contract expires ;-) | > | > In Bulgaria | > | > | > George Valkov | > | > | | | Ah, Bulgaria! My apologies. No problem! | I think fiber is worth the wait. In the meantime, hang in there with your | current limitations. | | Ace Yes, btw the my server in Sofia is using 100M ethernet that goes directly to fiber, with 1 ms delay in the entire city ...it's not bad for a home server. The only time I noticed a slight delay, was when after a week uptime, Skype decided to become a super node and went crazy: netstat -bn indicated more than 500 TCP connections (despite what's written in it's documentation). So I disabled the super-node ability. Thank You for Your replay! Have a nice day, Ace! George Valkov
| | > | > Yes, btw the my server in Sofia is using 100M ethernet that goes directly | > to | > fiber, with 1 ms delay in the entire city ...it's not bad for a home | > server. | > | > The only time I noticed a slight delay, was when after a week uptime, | > Skype | > decided to become a super node and went crazy: netstat -bn indicated more | > than 500 TCP connections (despite what's written in it's documentation). | > So | > I disabled the super-node ability. | > | > Thank You for Your replay! | > Have a nice day, Ace! | > | > | > George Valkov | > | | That's a nice speed. I think then, the issue causing the slow-down is Skype? | | Ace| I just mentioned that issue I once had with Skype to underline that it's not that easy to overload the connection of the server. It happened several months ago, and is not related to the current slow down - which probably is due to long ADSL line on the client side. George Valkov
| | > | > I just mentioned that issue I once had with Skype to underline that it's | > not | > that easy to overload the connection of the server. It happened several | > months ago, and is not related to the current slow down - which probably | > is | > due to long ADSL line on the client side. | > | > | > George Valkov | | Oh, ok. Well, I hope the fiber option comes out for you sooner than later! | | Ace Thank You, Ace! George Valkov
