Multi WAN Failover with 2x PPPoE and same IP address



  • Hello all,

    We have probably quite a unique situation with our pfSense box and our 2x WAN links and the way we have failover delivered to us by our ISP, but wondering if anyone would know how I can get this to work properly in our situtation? I'll start by giving everyone some background information…

    • We currently have a VDSL/FTTC primary circuit, which is connected to a modem, the Ethernet port of this then connects to our pfSense box and uses PPPoE via credentials #1.

    • We also have a secondary ADSL2+ circuit, which is also connected to a modem, then to pfSense via Ethernet/PPPoE as above, but with credential set #2.

    Our primary or secondary work absolutely fine when connected individually and used as such. However trying to set up auto fail-over between the two has never worked.

    The way our ISP has set this up their end is as follows:

    • 2x Sets of PPPoE credentials - one for primary and one for secondary as above. These use different carriers and wholesale suppliers so if one goes down we have resiliency in that respect and so on.

    • 1x Static IP that is assigned whenever EITHER of the PPPoE sessions is established (shared between the two logins if you like) This is done so that our IP address stays the same no matter which circuit we are running on (useful for firewall rules/port forwarding etc).

    If the Primary PPPoE session establishes it gets given IP address 10.10.10.1 (example address), but then if the primary is manually disconnected and the secondary is plugged in it also gets assigned the IP 10.10.10.1, and in the process terminates the session from the primary.

    This is the bit that seems to be causing us an issue with the way pfSense handles WAN failover. pfSense seems to want to fire up both PPPoE sessions at the same time when we have both the primary and secondary connected, and then determine via it's own means which connection to route traffic down. Of course this causes an issue because both logins are assigned the same IP and are fighting over which should be handling the traffic.

    Does anyone have any suggestions as to how we can get this to work?

    My thought is that if the secondary PPPoE session wasn't initiated until the primary circuit went down/failed to authenticate, then all pfSense would need to do is bring the secondary session up and terminate the first. Then try to establish the primary PPPoE again, until successful, at which point it knows the primary authenticated sucessfully, it would then forcibly bring the secondary down until required.

    I suppose what this needs is a monitoring option for the Multi-Wan that monitors the PPPoE session state, rather than a remote IP.

    Before we made the move to pfSense, we had Draytek equipment which handled this failover absolutely perfectly, however we would prefer to stay with pfSense due to the more advanced features offered. I hope this all makes sense as I know what I'm trying to explain is quite complicated. Any questions do let me know.

    Thanks in advance for any help!

    Ben


  • Galactic Empire

    Have you tried setting dial on demand on the backup and create a gateway groups?

    I wonder if that would cause the backup to only come online if the primary failed.

    Interfaces -> PPPs -> Edit -> Advanced Configuration

    System -> Routing -> Gateway Groups

    https://doc.pfsense.org/index.php/Gateway_Settings

    Never done it and I could be talking out my hat.



  • Hi Nog,

    Thanks for your quick reply!

    I should have mentioned, we have got these setup as a gateway group currently, with our primary having tier 1 set and secondary set to tier 2.

    I'm pretty sure we tried activating dial on demand when we first tried ages ago, but I will give it another go this weekend when I can test and will let you know.

    Thanks



  • Hi Nog,

    Tried all the above and no better I'm afraid!

    If anyone has any further suggestions please do let me know

    Thanks!


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy