ZS 3.9.0 – PPPoE / Netbalancer is broken

Home Page Forums Network Management ZeroShell ZS 3.9.0 – PPPoE / Netbalancer is broken

This topic contains 13 replies, has 4 voices, and was last updated by  Jean-Marc Maestri 5 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #64042

    Jean-Marc Maestri
    Participant

    Hello everybody

    This post is linked to my previous one, with difficulties to access some websites after upgrading to ZS 3.9.0

    There is a problem with PPPoE across NetBalancer using ZS 3.9.0.
    I have 2 DSL link using the netbalancer :

    1st link is a direct DHCP bridge to the provider #1
    2nd link is a PPPoE link to the provider #2

    When I said I had problem with ZS 3.9.0 to access many https websites, but not all, in fact it’s linked to netbalancer load balancing.

    With ZS 3.9.0, each time I try to access an https website using the PPPoE link, it fails, but using the direct DHCP link, it’s OK. it’s easy to check by enabling/disabling netbalancer members.

    Again, with ZS 3.8.2, all is OK with https websites from any loadbalanced links.
    So I guess there is a real problem in ZS 3.9.0 with PPPoE and/or Netbalancer.

    So for now I will stay back on ZS 3.8.2 waiting for some corrections 😉

    Thanks

    #64050

    fulvio
    Keymaster

    Are you sure that Net Balancer breaks only https connections?
    Are not encrypted http connections working?
    It would be very strange.
    Regards
    Fulvio

    #64052

    Jean-Marc Maestri
    Participant

    Hello Fulvio.

    Yes I confirm, just checked again and I was unable to answer on that forum using pppoe, and now I can post that mesage after forced the netbalancer to use the non pppoe member.

    After migration from 3.8.2 to 3.9.0, the ppoe is up, connected, I can connect with it excepted for encrypted https. I still can use HTTP FTP, FTPES also works well. POP and SMTP seems to be OK also.

    I confirm that only HTTPS websites seems to beimpacted, not HTTP. Using IE; Firefox and Chrome.
    Within Firefox, i can see a little message while resheshing the page that hang during TLS negotiation with the remote https website. Maye be some restriction on TLS support on the new kernel ?

    Thanks

    #64055

    Tiger
    Participant

    I after updating from 3.8.0 to 3.9.0 I do not see any new kernels. only the usual 4.14.29 32 bit the 64 one always 4.14.29 if I try to install it from unload error and does not start. I also tried to force repository update via the check button but nothing. what kernel do you have with 3.9.0?

    #64062

    fulvio
    Keymaster

    Could you try to ping with a packet size greater then 1500 bytes?
    I suspect can be a MTU issue.

    Regards
    Fulvio

    #64063

    fulvio
    Keymaster

    Tiger the repository will be available soon.
    Regards
    Fulvio

    #64068

    Jean-Marc Maestri
    Participant

    Hello.
    Il will do the test as soon as I’ll be back near the router, for mow i’m in remote access and cannot shutdown it.

    I’m not agree with the maximum packet size of 1500 for the PING test over WAN to be valid :

    With “standard” (non pppoe) WAN, MTU = 1500, but due to IP Header and ICMP Header the maximum ping size should be 1472.

    With PPPoE WAN, the MTU is already reduced to 1492 due to PPPoE service bytes, plus IP/ICMP Header, the maximum packet size should not be more then 1464 bytes.

    Currently running (remote) on ZS 3.8.2 (with no https problem), I just verified the max value for the ping size on http://www.google.com :
    – 1472 OK / 1473 KO on the DSL Netbalancer member without PPPoE
    – 1464 OK / 1465 KO on the DSL Netbalancer member using PPPoE

    As soon as i’ll be back near the router, I’ll switch to ZS 3.9.0 and try the same ping with the same values.

    Regards.

    #64085

    Jean-Marc Maestri
    Participant

    Hello Fluvio.

    Back close to the router to make checks you asked.
    Two tests follows, both done with forced PPPoE gateway member on netbalancer :

    First ping test with ZS 3.8.2, and then access with firefox to your website (as an example of https site), using firefox, and OK.

    Second ping test with ZS 3.9.0, and then the same access to your website with firefox, now KO.

    Please note again that as soon as I use ZS 3.9.0, browsers hangs on websites requiring TLS negotiation (as your). No problem with same browser, on same website using ZS 3.8.2.

    ————————————————————————————————
    Zeroshell 3.8.2
    Gateway forced in netbalancer to PPPoE uplink.

    C:\WINDOWS\system32>ping -l 1464 http://www.google.com

    Envoi d’une requĂȘte ‘ping’ sur http://www.google.com [209.85.202.99] avec 1464 octets de donnĂ©es :
    Réponse de 209.85.202.99 : octets=64 (envoyés 1464) temps=64 ms TTL=44
    Réponse de 209.85.202.99 : octets=64 (envoyés 1464) temps=64 ms TTL=44
    Réponse de 209.85.202.99 : octets=64 (envoyés 1464) temps=65 ms TTL=44
    Réponse de 209.85.202.99 : octets=64 (envoyés 1464) temps=64 ms TTL=44

    Statistiques Ping pour 209.85.202.99:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
    Durée approximative des boucles en millisecondes :
    Minimum = 64ms, Maximum = 65ms, Moyenne = 64ms

    C:\WINDOWS\system32>ping -l 1465 http://www.google.com

    Envoi d’une requĂȘte ‘ping’ sur http://www.google.com [209.85.202.99] avec 1465 octets de donnĂ©es :
    DĂ©lai d’attente de la demande dĂ©passĂ©.
    DĂ©lai d’attente de la demande dĂ©passĂ©.
    DĂ©lai d’attente de la demande dĂ©passĂ©.
    DĂ©lai d’attente de la demande dĂ©passĂ©.

    Statistiques Ping pour 209.85.202.99:
    Paquets : envoyés = 4, reçus = 0, perdus = 1 (perte 100%),

    Trying now to access zeroshell website by the active PPPoE gateway : OK

    Zeroshell Linux Router
    Routing and Bridging Firewall Solutions

    ————————————————————————————————
    Zeroshell 3.9.0
    Gateway forced in netbalancer to PPPoE uplink.

    C:\WINDOWS\system32>ping -l 1464 http://www.google.com

    Envoi d’une requĂȘte ‘ping’ sur http://www.google.com [209.85.202.104] avec 1464 octets de donnĂ©es :
    Réponse de 209.85.202.104 : octets=64 (envoyés 1464) temps=64 ms TTL=44
    Réponse de 209.85.202.104 : octets=64 (envoyés 1464) temps=63 ms TTL=44
    Réponse de 209.85.202.104 : octets=64 (envoyés 1464) temps=64 ms TTL=44
    Réponse de 209.85.202.104 : octets=64 (envoyés 1464) temps=63 ms TTL=44

    Statistiques Ping pour 209.85.202.104:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
    Durée approximative des boucles en millisecondes :
    Minimum = 63ms, Maximum = 64ms, Moyenne = 63ms

    C:\WINDOWS\system32>ping -l 1465 http://www.google.com

    Envoi d’une requĂȘte ‘ping’ sur http://www.google.com [209.85.202.104] avec 1465 octets de donnĂ©es :
    DĂ©lai d’attente de la demande dĂ©passĂ©.
    DĂ©lai d’attente de la demande dĂ©passĂ©.
    DĂ©lai d’attente de la demande dĂ©passĂ©.
    DĂ©lai d’attente de la demande dĂ©passĂ©.

    Statistiques Ping pour 209.85.202.104:
    Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),

    Trying now to access zeroshell website by the active PPPoE gateway : KO

    Please wait establishing TLS connection
    Le dĂ©lai d’attente est dĂ©passĂ©
    Le serveur Ă  l’adresse zeroshell.org met trop de temps Ă  rĂ©pondre.

    Le site est peut-ĂȘtre temporairement indisponible ou surchargĂ©. RĂ©essayez plus tard ;
    Si vous n’arrivez Ă  naviguer sur aucun site, vĂ©rifiez la connexion au rĂ©seau de votre ordinateur ;
    Si votre ordinateur ou votre réseau est protégé par un pare-feu ou un proxy, assurez-vous que Firefox est autorisé à accéder au Web.
    ————————————————————————————————

    #64114

    Jean-Marc Maestri
    Participant

    Hello Fulvio.

    Any method to change the default MTU size for PPPoE with ZS, including after disconnection/reconnection cycle by the netbalancer monitor ? Seems you are right and need to be reduced from 1492 to 1476 or 1480 with ZS 3.9 in order to not break most of SSL websites. Anyway looks like a big regression of the kernel.

    Thanks

    #64127

    Alex
    Participant

    are you changing on the ppp interfaces? (thats default 1492) I don’t see an improvement ..

    #64128

    Jean-Marc Maestri
    Participant

    Don’t sure to understand your question, but yes, I want to try to reduce the MTU size of the PPPoE interface to check if TLS negotiation goes far with a smaller value then the default, but I dont know how to do that persistently as the 1492 MTU value seems to be “wired” somewhere in zeroshell, and that value seems to be set every time the PPPoE connection is established or re-established after a link drop by the netbalancer monitor.

    #64129

    Alex
    Participant

    yes, but have you tried from shell to just put in:

    ip link set dev ppp1 mtu 1476

    I tried lowering there, but dont see any change in performance.

    Check your interface with
    ip link list

    #64130

    Alex
    Participant

    anyway, I removed pppoe patch and 64 bit kernel on 3.8.2 and my speed issues went away.

    #64132

    Jean-Marc Maestri
    Participant

    This in not the same problem I have. No speed problem here with PPPoE, just the fact that I cannot access anymore most of HTTPS websites through PPPoE (and only through PPPoE) using the standard ZS 3.9.0 ISO distribution, while the access with ZS 3.8.2 is still perfect…

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.