IPSec is very slow over ADSL connection

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

You could try DES + MD5
Anthony
http://www.airdesk.com




"George Valkov" <> wrote in message
news:...
> 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


"Anthony [MVP]" <> wrote in message
news:955B749F-A44E-4EEE-A8E5-...
| You could try DES + MD5
| Anthony
| http://www.airdesk.com
|
|
|
|
| "George Valkov" <> wrote in message
| news:...
| > 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
| >
| >

George,
What did the ISP change?
Anthony,
http://www.airdesk.com


"George Valkov" <> wrote in message
news:...
> 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
>
>
> "Anthony [MVP]" <> wrote in message
> news:955B749F-A44E-4EEE-A8E5-...
> | You could try DES + MD5
> | Anthony
> | http://www.airdesk.com
> |
> |
> |
> |
> | "George Valkov" <> wrote in message
> | news:...
> | > 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/zuywzo...ransmition.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



"Anthony [MVP]" <> wrote in message
news:E8FA4052-0F53-45BD-9019-...
| George,
| What did the ISP change?
| Anthony,
| http://www.airdesk.com
|
|
| "George Valkov" <> wrote in message
| news:...
| > 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
| >
| >
| > "Anthony [MVP]" <> wrote in message
| > news:955B749F-A44E-4EEE-A8E5-...
| > | You could try DES + MD5
| > | Anthony
| > | http://www.airdesk.com
| > |
| > |
| > |
| > |
| > | "George Valkov" <> wrote in message
| > | news:...
| > | > 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
| > | >
| > | >
| >
| >

"George Valkov" <> wrote in message
news:...
> 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/zuywzo...ransmition.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

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.

"Ace Fekay [MCT]" <> wrote in message
news:%...
| "George Valkov" <> wrote in message
| news:...
| > 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/zuywzo...ransmition.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/cdmuzz...7-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

"George Valkov" <> wrote in message
news:...
>
> "Ace Fekay [MCT]" <> wrote in message
> news:%...
> | "George Valkov" <> wrote in message
> | news:...
> | > 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/zuywzo...ransmition.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/cdmuzz...7-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

"Ace Fekay [MCT]" <> wrote in message
news:...
| "George Valkov" <> wrote in message
| news:...
| >
| > "Ace Fekay [MCT]" <> wrote in message
| > news:%...
| > | "George Valkov" <> wrote in message
| > | news:...
| > | > 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/zuywzo...ransmition.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/cdmuzz...7-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

"George Valkov" <> wrote in message
news:%...
>
> 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