PHP shell has "gatewaystatus" but why does it report all gateways as "Status=none"?



  • It looks like this:

    pfSense shell: require_once("gwlb.inc");
    pfSense shell: global $argv;
    pfSense shell: echo return_gateways_status_text(true);
    pfSense shell: exec
    Name        Monitor                        Source                             Delay     StdDev   Loss  Status
    VPN         245.108.129.226                10.152.211.22                      27.475ms  5.478ms    2%    none
    WAN1        121.42.124.1                      121.42.124.149                  10.005ms  3.409ms  0.0%    none
    WAN2        1.1.1.1                           192.168.100.101                 40.697ms  5.786ms  0.0%    none
    

    Main GUI, however, shows a lot more reasonable real "Online"/"Offline" status based on "Monitor IP" responses.

    Is there some way to make "gatewaystatus" show correct status or is it a bug?


  • Netgate Administrator

    It reports the status tracked by gwlb.inc which is concerned only with loadbalance/failover. Status 'none' is everything is OK there. As opposed to latency, high-latency, loss, down etc.
    It probably would be possible to change how that is displayed there but it would require far mode mode that is present currently. It's not a bug, that's the expected behavior.

    Pull requests welcome. 😉

    Steve



  • Thanks for your reply. But is there a way to pull the gateway status related to being Offline/Online?

    What I am really after is to be able to get a message (e.g. to launch a script) which will modify the rules when one of the WAN gateways goes up and/or down.

    Alternatively, an ability a apply a rule depending on a specific gateway being up or down would solve my problem (reducing traffic on an expensive failover WAN to only monitoring its liveness).


  • Netgate Administrator

    So you want to move traffic back to the main WAN when it comes back up? That's a fairly common request.



  • I run 2.4.4-RELEASE-p3 with two WANs (with failover):

    • an unlimited cable connection (cheap "main-WAN" which is up >99% of the time)
    • a MiFi to a local mobile tower ("WAN-via-MiFi" which is expensive) - it is only used when main-WAN is down.

    The problem I am facing is that unbound sends DNS traffic to all active gateways (including WAN-via-MiFi) even when main-WAN is online. DNSSEC traffic (if enabled) is quite voluminous so my failover WAN-via-MiFi becomes too expensive - as it uses a pay-as-you-go SIM all packets contribute to the cost even though this traffic is completely unnecessary while main-WAN is operational.

    I was hoping to find a way to detect when the main-WAN gateway goes online and insert a rule (e.g. via PHP shell) which would only allow ICMP over WAN-via-MiFi and, subsequently, when main-WAN goes down - remove that rule. According to my analysis of the packet captures this should ensure that only packets to "Monitor IP" go out via WAN-via-MiFi (and the frequency of these is easy to control via UI).

    How can this be done? Or maybe you have some other ideas how to prevent unnecessary DNS traffic over non-default gateway?


  • Netgate Administrator

    You can set the outgoing interface in Unbound. By default it uses all interfaces as you say but you can set it to localhost.
    If you do that it will use the system routing to determine which gateway to use and if you have the default gateway set to your failover group that should give you the behaviour you're looking for.
    Just be sure you have outbound NAT rules for localhost. You would be default in auto mode but you may have changed that.

    Steve



  • @stephenw10 I will give it a try. But please help me understand what you mean by "have outbound NAT rules for localhost".

    I have "manual outbound NAT" enabled and outbound NAT rules require "protocol", "interface", "source" and "destination". Should I simply set "protocol=any", "source=127.0.0.1", "destination=any" and repeat this twice for each WAN? Anything else?


  • Netgate Administrator

    Exactly like that. When you switched from auto it would have added them as manual rules but you usually don't need them so you might have removed them.

    Steve



  • @stephenw10, your advice was brilliant - I had a chance to thoroughly check it and everything works as it should.

    Unbound, when it is configured to operate via localhost outbound gateway indeed uses only the one chosen by the system (i.e. dictated by the failover rules). This allowed me to completely eliminate unwanted unbound DNS traffic via an expensive SIM-based failover link. I then dialled down the frequency of "Monitor IP" pings via SIM-based link to minimise the ongoing cost too. Very pleased with the result - exactly what I wanted to achieve.

    It's great that users are able to get useful advices in the Netgate forum. Many thanks to all the experts for their time and help!


  • Netgate Administrator

    Great to hear. I have a similar setup although my 3G/4G connection is for emergencies only. By tweaking the gateway monitor settings I can remain under 200MB a month which on Three in the UK is free.

    Steve



  • @stephenw10
    I use 1p-Mobile which overall should be cheaper (I presume your "3" SIM is a monthly contract) - minimal cost for 1p-Mobile is £10 every 120 days which is £2.5/month. Everything unused rolls over forever and I currently have ~£30 accumulated there. When my Virgin cable connection would go down 1p-Mobile traffic will cost 1p/1MB so I should be able to cover outages >3GB. If/when this runs out I can try tethering pfSense to my mobile phone (pfSense has "Vonets" ethernet-to-Wifi adapter) and then I'll have additional ~30GB - this won't be automatic failover though.


  • Netgate Administrator

    The Three Data Reward SIM is PAYG but you get 200MB per month free so it effectively costs me nothing until I need to use it when I then have to add credit. It's more expensive at that point especially if I have to use it quite a lot and much less convenient, requires manual intervention. But... hard to argue with free. 😉

    Steve


Log in to reply