Page 1 of 2 12 LastLast
Results 1 to 10 of 12
  1. #1
    Newbie
    Join Date
    Jun 2020
    Posts
    4

    Default Bypass rule breaks HTTPS connections

    Hi,

    I've just switched my UT from using an external router (connected via the external interface in static IP mode, with router handling actual PPPoE negotation etc) to using an external modem (connected via external interface in PPPoE mode). The external interface has NAT ticked.

    There is one internal interface (172.16.0.0/24) that does not have NAT ticked.

    The external interface successfully negotiates the PPPoE connection, and the connectivity, ping, DNS etc tests inside UT all work successfully. I can also ping and nslookup etc on a client machine on the internal network to the Internet successfully.

    I can access HTTP webpages on client machines, and all my port forwards to my internal services work perfectly.

    However - I have enabled bypass on source addresses 172.16.0.2-172.16.0.254 to enable the use of QoS (I am not a paying subscriber at this time so cannot use Bandwidth Control). But when bypass is enabled, I am not able to connect to any HTTPS websites.

    If I disable bypass and allow the traffic to flow through the stack, all connections work perfectly, but obviously I am unable to use QoS (and I don't want anything flowing through the stack adding latency).

    I did not have this issue when using the external interface in static mode with an external router.

    Is this a limitation of UT, or a bug? Or am I being stupid?

    Thanks in advance!

  2. #2
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,606

    Default

    This smells of something that burned me once. With minimal bandwidth at home, and a relaxed environment, everything seemed to work fine.

    Then Netflix started to fail with its initial bandwidth discovery testing -- when the traffic was bypassed for QoS like you.
    Which meant less latency, and hammering the External Interface harder.

    It was an Ethernet patch cable that did not have the conductors for a Gigabit NIC to negotiate.

    Replace the Patch cable to the modem with one known to be rated for Gigabit, inspect it visually for eight wires, and don't crimp your own.

  3. #3
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,606
    Last edited by Jim.Alles; 06-08-2020 at 05:40 PM. Reason: except after c

  4. #4
    Newbie
    Join Date
    Jun 2020
    Posts
    4

    Default

    Hi Jim,

    Sadly everything does not work fine, even at minimal bandwidth. There’s only one client on the network - works fine with bypass disabled, but not when enabled.

    The NIC and layer 1 have no trouble coping when the external interface is communicating with a router, just not when set up in PPPoE!

  5. #5
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,606

    Default

    That is part of the point.
    You have changed hardware, and may now have (2) Gigabit interfaces that can't negotiate that connection. Then things get squirrelly, and it becomes all about the signal timing.

    The other thing that can affect PPPoE is the MTU, that setting is at: #config/network/advanced/network_cards
    Last edited by Jim.Alles; 06-08-2020 at 05:43 PM.

  6. #6
    Newbie
    Join Date
    Jun 2020
    Posts
    4

    Default

    The PPPoE connection correctly assigns MTU, but no effort is made by any element to enforce MSS size, so larger sized packets are being dropped or lost or something.

    I have 'fixed' this by crontabbing the follow iptables rule, as there is no function (as there is in pfSense et al) to define MSS clamping on the PPPoE connection natively in UT.

    Code:
    iptables -t mangle -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
    I would gladly move over to pfSense and not have to deal with this bodgery, but the bufferbloat remedy UT provides actually works, which keeps me here...
    Last edited by lesyork; 06-09-2020 at 11:09 AM.
    Jim.Alles and craiga_uk like this.

  7. #7
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,606

    Default

    Thanks for researching and documenting this.

    It might be useful to open a support ticket, so the issue can be documented w/ Untangle internally!

  8. #8
    Untangler jcoffin's Avatar
    Join Date
    Aug 2008
    Location
    Sunnyvale, CA
    Posts
    9,201

    Default

    Feel free to document this in Jira (jira.untangle.com). Jira tickets are more likely to get into the product.
    Attention: Support and help on the Untangle Forums is provided by
    volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  9. #9
    Untangler
    Join Date
    Oct 2014
    Posts
    38

    Default

    Well discovered Les - I've got the same issue and it felt like an MTU problem, but I don't know the back-end well enough to get under the hood to tweak/fix.

    @jcoffin - we've got a ticket open on this (with, to be honest, a not terribly satisfactory response for a product we're pushing to lots of clients with PPPoE connections... )
    Ticket #177283

    Ted,

    I got one of my most-senior colleagues to take a look at this and there's an answer, but it's not a great one.

    Apparently we've seen issues with certain Canadian and European ISPs' PPPoE internet connections. Those connections sometimes require some kind of setting we don't specifically support. However, something in one of our applications apparently emulates that setting (or its desired behavior) well enough that we've seen this once in a great while. Most unfortunately, there isn't a solution; there's nothing you can change in the NGFW itself that will alter that behavior.

    (Worse still, this comes up so infrequently that even the colleague I mentioned, who's been with Untangle since before it was even called 'Untangle', doesn't remember what the setting is.)
    Thank you,
    Græme Ravenscroft
    Could you possibly look at getting a fix into the timeline?

    I'm pretty sure this particular has just got worse with the latest release as we're getting more problems than we used to with bypassed devices, and 60% of our deployed devices have a PPPoE connection on the WAN side....

    Thanks!

  10. #10
    Untangler
    Join Date
    Oct 2014
    Posts
    38

    Default

    FYI John there is an ancient bug in JIRA on this issue;
    https://jira.untangle.com/browse/NGFW-11224

    And also looks to be distantly related to this:
    https://jira.untangle.com/browse/NGFW-4701
    Jim.Alles likes this.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2