Hi all,

We're a UK based Untangle partner with around 20 devices in the field. Here in the UK, unless a client has a dedicated Ethernet/Leased Line circuit they tend to have VDSL.
Here, we have to authenticate VDSL connections via PPPoE using either a VDSL modem that used to be supplied by the national provider, or now via 3rd party VDSL modems as these national supplied modems are no longer available.

This works fine with Untangle for 1 connection, but when adding a second connection things go weird after a while. One client we have with a box running 2 x PPPoE VDSL connections to the same ISP suddenly gets random dropped packets - typically the 3rd ping in every 4, making VoIP impossible.
Rebooting the Untangle fixes the issue every time - until it suddenly flips out again at some undetermined future time.

It's worse if the connections are a VDSL primary (with PPPoE) and an ADSL secondary from a different provider (usually PPPoA in the UK - but we have to use a modem that can establish the connection in front of Untangle, so again this modem then wants Untangle to use PPPoE to send the credentials).
This just causes the primary line to drop completely.

The issue according to support (over 12 months ago now - maybe even 24) was that the PPPoE connections re-negotiate at the same time and this causes a race condition:
We have been reviewing this issue more in depth. And it would seem as though both of your PPPoE connections are negotiating for a new lease at the same time. And this is what is leading to your issue. As your network currently sits, it is a race condition on which provider is reaching the Untangle first. Whichever negotiation packet reaches the Untangle first will be PPP0, the second one to reach the Untangle becomes PPP1. There are no options or changes within Untangle that will change this. Because your single Untangle device is running both of those negotiations simultaneously, this behavior will continue.

You will want to offload the PPP auto-negotiations off of the Untangle, and onto the ISP provided PPP modems. Since these will negotiate separate from each other, it will stop this cross over behavior. But at this time, your PPP issue is purely a race condition on which interface responds quicker.
The problem is, we have no way to offload the PPP to the modem that I can see. The only option we have is to have the modem do the entire connection and then we're getting a double NAT scenario.

Can anyone suggest what else we can do?
We have a client about to pull the box for an alternative vendor if we can't sort the issue, and the issue doesn't exist with the same config set-up using other vendor hardware such as Sonicwall or Watchguard - we've tested it without issues.