Multi WAN testbeds #1821
Comments
|
As gateway switching uses apinger to do a ping check I can right a python script to do a ping check to replace apinger if anyone is interested in that and gets agreed to?
I would need someone to wire it in to opnsense though as I do not know PHP.
…________________________________
From: Michael <notifications@github.com>
Sent: Wednesday, September 13, 2017 9:51:20 AM
To: opnsense/core
Cc: Subscribed
Subject: [opnsense/core] Multi WAN testbeds (#1821)
I did some testing with Multi WAN in combination with (hopefully not too soon) deprecated "Enable gateway switching". My intention is to test if services enabled at WAN side are reachable (WebGUI and just ping wan address)
Scenario: LAN, WAN1 (Static IP, default route), WAN2 (dhcp, receives default gw, but not set to default)
Test1:
No gateways in FW rules.
No gateway groups
GW switching active
Result1:
Failover works
Both WANs reachable
________________________________
Test2:
No gateways in FW rules.
No gateway groups
GW switching NOT active
Result2:
Failover doesn't work
Both WANs not reachable
Sidenote2:
Enabling gw switching afterwards doesn't fix this situation without reboot. Reenabling WAN makes default gw available again but in UI it's marked as pening. Only restart of apinger fix this (just cosmetic, perhaps some syscall missing here)
________________________________
Test3:
No gateways in FW rules.
GWGROUP, WAN1 Tier1, WAN2 Tier2
GW switching active
Result3:
Failover works
Both WANs reachable
Sidenode3: This time reenabling WAN1 didn't end with apinger status pending
________________________________
Test4:
FW Rule LAN to ANY set to GWGROUP.
GWGROUP, WAN1 Tier1, WAN2 Tier2
GW switching active
Result4:
Same as Result3
________________________________
Test5:
FW Rule LAN to ANY set to GWGROUP.
GWGROUP, WAN1 Tier1, WAN2 Tier2
GW switching NOT active
Result5:
Both WANs not reachable
Failover for LAN rule works
I'm not sure if this results helps in any way, but I hope it let's gateway switching live a bit longer, since as a MSP we have the requirement to reach our managed firewalls via both/all WANs. I think this also relates to services like OpenVPN to make them redundantly available.
Perhaps other people also want to contribute their experiences.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#1821>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADddQkwSIKlDftrFzTRoxRgMJvKPT_ejks5sh5eHgaJpZM4PVx3m>.
|
|
For the archive: Result: default gateway route lost, not reproduceable when status for both OK. Will wait until this happens again. Restarting apinger doesn't help. /usr/local/etc/rc.reload_interfaces will fix it. |
|
My config is: As mentioned in the forum, can trigger loss of default route on WAN by release/renew on WAN2 (OPT1). |
|
@NOYB have you tried the settings posted in the forums ( https://forum.opnsense.org/index.php?topic=6643.0 ) |
|
Not yet. |
|
As just discussed with @mimugmail on IRC, there are some different issues with pppoe and multiwan setups. Because we don't have a pppoe setup here at our office it's difficult to track them down, and we really should refactor (at least some of) the ancient ppp interface code (one of the topics we skipped until now). The plan is to work together in Q1 2018 and refactor the underlaying code, @mimugmail can provide us with the needed equipment. When decently structured, we can see if issues still remain and what they are exactly. @fichtner I have assigned myself to do the work, but if you want it back, just let me know. |
|
@AdSchellevis sounds good to me, will be happy to offer review :) One thing that seems to make PPPoE stumble on IPv6 seems to be dyndns, we're tracking this via: #1403 which is likely solved by 9f535ba I'm about to merge this code into 18.1, it looks sane enough, reduces the risk of races and reload stability by deferring all plugin hooks... a second opinion from you is very much welcome. |
|
Just for my reference to catch most constellations: https://forum.opnsense.org/index.php?topic=6817.0 |
|
For me OPT1 interface DHCP renewal causing the default route on WAN interface to be removed. Can manually trigger it at will by doing release/renew on the OPT1 interface. |
|
https://forum.opnsense.org/index.php?topic=7199.0 Not sure if it matches ... but when you follow the forums, dhcp and/or pppoe makes more and more problems. I'm back at work on March, perhaps we can start troubleshooting then? I have two machines connected via static and I can plug in pppoe directly or lte via dhcp. |
|
@mimugmail let's try to do that, the coming weeks I'm quite busy, so ping me when you're back. |
|
Here's an interesting one... pfsense/pfsense@d35dfaaec Tracking via #2164 |
|
I've committed another related cleanup and removed the deprecation note for default gateway switching. Please test the development version on 18.1.3... it'll likely give us better behaviour and increased logging during switching routes. |
In order for default gateway switching to work we need to call routing first, then set up gateways, lastly invoke filter reload which currently chains the gateway swtich code. While here, remove deprecation notes.
|
there is also an additional patch here for default gateway switching 07785e2 (not yet on master) |
In order for default gateway switching to work we need to call routing first, then set up gateways, lastly invoke filter reload which currently chains the gateway swtich code. While here, remove deprecation notes. (cherry picked from commit b30cbe1)
|
Seems @fichtner fixed the pppoe stuff today with cbad1bfe020 .. stable pppoe failovers 👍 Next week we'll face double DHCP setup like @NOYB runs it .. |
|
I'm closing this now since all kinds of combinations are working fine! Most important: I tested all possible combinations of DHCP, PPPOE and static WAN ... BUT .. only v4! Not sure how it works with v6 but I'm optimistic. Thanks @fichtner and @AdSchellevis for your help :) |
I did some testing with Multi WAN in combination with (hopefully not too soon) deprecated "Enable gateway switching". My intention is to test if services enabled at WAN side are reachable (WebGUI and just ping wan address)
Scenario: LAN, WAN1 (Static IP, default route), WAN2 (dhcp, receives default gw, but not set to default)
Test1:
No gateways in FW rules.
No gateway groups
GW switching active
Result1:
Failover works
Both WANs reachable
Test2:
No gateways in FW rules.
No gateway groups
GW switching NOT active
Result2:
Failover doesn't work
Both WANs not reachable
Sidenote2:
Enabling gw switching afterwards doesn't fix this situation without reboot. Reenabling WAN makes default gw available again but in UI it's marked as pening. Only restart of apinger fix this (just cosmetic, perhaps some syscall missing here)
Test3:
No gateways in FW rules.
GWGROUP, WAN1 Tier1, WAN2 Tier2
GW switching active
Result3:
Failover works
Both WANs reachable
Sidenode3: This time reenabling WAN1 didn't end with apinger status pending
Test4:
FW Rule LAN to ANY set to GWGROUP.
GWGROUP, WAN1 Tier1, WAN2 Tier2
GW switching active
Result4:
Same as Result3
Test5:
FW Rule LAN to ANY set to GWGROUP.
GWGROUP, WAN1 Tier1, WAN2 Tier2
GW switching NOT active
Result5:
Both WANs not reachable
Failover for LAN rule works
I'm not sure if this results helps in any way, but I hope it let's gateway switching live a bit longer, since as a MSP we have the requirement to reach our managed firewalls via both/all WANs. I think this also relates to services like OpenVPN to make them redundantly available.
Perhaps other people also want to contribute their experiences.
The text was updated successfully, but these errors were encountered: