[ale] http behind pppoe ?

Keith R. Watson keith.watson at gtri.gatech.edu
Fri Jan 24 14:39:28 EST 2003


At 12:38 PM 1/24/2003 -0500, James CE Johnson wrote:

>I'm unfortunate enough to live behind the bastardization that is PPPoE
>rather than having a nice, static IP. Since the switch (from the nice,
>static IP to the bastardization that is PPPoE) I've noticed that web
>requests to my server seem to have "issues". To be specific, it seems that
>in some cases the browser isn't getting the entire page sent by the
>server.
>
>Other protocols (eg -- ssh) seem to exhibit similar behavior but since the
>bulk of my traffic is http that's where I see it most.
>
>I have absolutely no idea why this is happening but I'm hoping someone out
>there in ALE-land has already been down this dark and disturbing road and
>will be kind enough to lend me a hand.
>
>Thanks,
>J


James,

When we first started using Cable/DSL routers such Linksys with ISP's that 
use PPPOE, we encountered problems. I spent a day resolving the issue. Here 
is a copy of the report.

keith


VPN Connection to Georgia Tech Over Residential ADSL Test

Keith R. Watson
keith.watson at gtri.gatech.edu

4/25/2001

Test machines:

    Windows NT 4.0 (AIST Build v3.01)
    Windows 98 SE (Standard KRW home build)


Test Network:

    Earthlink residential ADSL using PPPOE
    ZyXEL Prestige 642M ATM to Ethernet bridge (DSL modem)
    Linksys BEFSR41 NAT Router with BIOS v1.37 (PPPOE provided by BEFSR41)
    10 Port 10Mb Ethernet Hub

    (Also did a series of tests using WinPoET v2.0
     on both machines. The results were the same as
     using the BEFSR41)


Software:

    WinPoET v2.0
    Secure Remote v4.1


Test Scenario:

    1. Establish VPN connection to the Georgia Tech Checkpoint Firewall
    2. Mount an SMB share
    3. Copy a large file from the SMB share (>1K)
    4. Establish Telnet session to casbah.gatech.edu
    5. Connect to https://webwise.gtri.gatech.edu/


Tests (results were the same for both workstations):

    MTU = 1500 (this is the default for ethernet

       1. Established VPN
       2. SMB mount succeeded.
       3. File copy <1K succeeded, >1K failed
       4. Telnet succeeded
       5. https failed


    MTU = 576

       1. Established VPN
       2. SMB mount succeeded
       3. File copiy <1K succeeded, >1K succeeded
       4. Telnet succeeded
       5. https succeeded


    MTU = 1464

       1. Established VPN
       2. SMB mount succeeded
       3. File copy <1K succeeded, >1K failed
       4. Telnet succeeded
       5. https failed


    MTU = 1400

       1. Established VPN
       2. SMB mount succeeded
       3. File copy <1K succeeded, >1K succeeded
       4. Telnet succeeded
       5. https succeeded


    MTU = 1440

       1. Established VPN
       2. SMB mount succeeded
       3. File copy <1K succeeded, >1K succeeded
       4. Telnet succeeded
       5. https failed


    MTU = 1420

       1. Established VPN
       2. SMB mount succeeded
       3. File copy <1K succeeded, >1K succeeded
       4. Telnet succeeded
       5. https succeeded


    MTU = 1430

       1. Established VPN
       2. SMB mount succeeded
       3. File copy <1K succeeded, >1K succeeded
       4. Telnet succeeded
       5. https succeeded


    MTU = 1435

       1. Established VPN
       2. SMB mount succeeded
       3. File copy <1K succeeded, >1K succeeded
       4. Telnet succeeded
       5. https succeeded


    MTU = 1438

       1. Established VPN
       2. SMB mount succeeded
       3. File copy <1K succeeded, >1K succeeded
       4. Telnet succeeded
       5. https succeeded


    MTU = 1439

       1. Established VPN
       2. SMB mount succeeded
       3. File copy <1K succeeded, >1K succeeded
       4. Telnet succeeded
       5. https failed


Conclusions:

    A larger header is required for HTTPS over a VPN.
    When the MTU is set to 1500 the packets are fragmented
    whenever the data size to be transmitted is >1K.

       header size + data size > 1500 bytes


    Setting MTU to 1438 prevents the packets
    from fragmenting by limiting the amount of data in
    the packet.

       header size + data size = 1500 bytes


    Since not all possible scenarios were tested
    an MTU value of less than 1438 should be used
    to provide a safety margin. However, as MTU
    decreases more packets are needed to send the
    same amount of data. Therefore a safe compromise
    would be to set MTU to 1400.

-------------

Keith R. Watson                        GTRI/ITD
Systems Support Specialist III         Georgia Tech Research Institute
keith.watson at gtri.gatech.edu           Atlanta, GA  30332-0816
404-894-0836

_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale






More information about the Ale mailing list