IPSec is very slow over ADSL connection

Discussion in 'Server Networking' started by George Valkov, Aug 3, 2009.

  1. 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, Aug 3, 2009
    #1
    1. Advertisements

  2. Anthony [MVP], Aug 3, 2009
    #2
    1. Advertisements

  3. 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
    | >
    | >
     
    George Valkov, Aug 4, 2009
    #3
  4. Anthony [MVP], Aug 4, 2009
    #4
  5. 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
    | > | >
    | > | >
    | >
    | >
     
    George Valkov, Aug 6, 2009
    #5
  6. 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], Aug 7, 2009
    #6
  7. | | > 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
     
    George Valkov, Aug 7, 2009
    #7

  8. 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], Aug 7, 2009
    #8
  9. | | >
    | > | > | | > | > 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
     
    George Valkov, Aug 8, 2009
    #9
  10. That's a nice speed. I think then, the issue causing the slow-down is Skype?

    Ace
     
    Ace Fekay [MCT], Aug 8, 2009
    #10
  11. | | >
    | > 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
     
    George Valkov, Aug 8, 2009
    #11
  12. Oh, ok. Well, I hope the fiber option comes out for you sooner than later!

    Ace
     
    Ace Fekay [MCT], Aug 8, 2009
    #12
  13. | | >
    | > 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
     
    George Valkov, Aug 9, 2009
    #13
  14. You are welcome!

    Ace
     
    Ace Fekay [MCT], Aug 9, 2009
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.