OPNsense Forum
Archive => 19.1 Legacy Series => Topic started by: dof on February 02, 2019, 02:07:33 pm
-
Hi,
I move to the 19.1 version and I have a problem with the dpinger / multiwan
when I ping from my first WAN1 interface to 8.8.8.8 for example, no problem but when I put 8.8.8.8 in monitor IP for the WAN1 interface, dpinger say :
dpinger: COAXGW 8.8.8.8 : Alarm latency 0us stddev 0us loss 100%
somebody share the same problem ?
I tried to remove all gateway + group and recreate but it's not working
issue with dpinger ?
-
when I check in memory / process I can see, for the one which is not working :
/usr/local/bin/dpinger -f -S -r 0 -i COAXGW -B 192.168.xxx.254 -p /var/run/dpinger_COAXGW.pid -u /var/run/dpinger_COAXGW.sock -C{
and for the one which is ok :
/usr/local/bin/dpinger -f -S -r 0 -i FIBERGW -B 192.168.xxx.254 -p /var/run/dpinger_FIBERGW.pid -u /var/run/dpinger_FIBERGW.sock
perhaps a little workaround ?
-
From the lobby->Services. Stop the dpinger instances.
Now restart just the instance that is giving you the problem, does it then work?
-
hi
try to restart the 2 services (1 per WAN interface) in System: Diagnostics: Services
no effect :(
-
No, if you start just one does that work?
When you start just one of the slinger instances, is it always the same one that does not work?
-
just 1 not working.
this is always the same one which is down.
-
Which suggests its a case of looking at the gateway entry itself.
Goto System:Gateways:Single and check the differences between the working and not working instances.
-
hi
same setup for both. (and it worked before upgrade)
when I try to ping from the FW, it's ping without problem 8.8.8.8 (so it's ok for the interface)
one thing, when I put the local IP GW of the router (ISP Box) it's working ... but it's a stupid workaround because I ping the box ... not internet connectivity
a little diagram :
WAN1<>BOX1 (192.168.XX.1)<>FW(192.168.XX.254)
WAN2<>BOX2 (192.168.YY.1)<>FW(192.168.YY.254)
-
Were you using dpinger before or apinger?
-
I dont remember...
-
Is the router set in WAN failover mode?
If so try disconnecting the interface that is working and see if dpinger then works. It might be a routing thing.
-
FWIW, I don't see anything wrong with "-C" argument, it is static so "-C{" can never happen and it is always given, not only when it works /doesn't work:
https://github.com/opnsense/core/blob/361fe644edec958e77e9f4548323bc7bbdae287f/src/etc/inc/gwlb.inc#L205
Cheers,
Franco
-
hello,
unfortunately it's not working....
any other idea ?
-
Do you have the same monitor IP on multiple interfaces ?
-
Had the same issue, with 17.8, but it was a missconfiguration of my network. Doesn't seems to be at yours.
Hint from german forum was:
System: Settings: General
DNS Server
WAN 1: 8.8.8.8
WAN 2: 8.8.8.8
Monitor IP
WAN 1: 1.1.1.1
WAN 2: 9.9.9.9
Check System: Routes: Status if the routes if they are correct.
When it was not working at my installation I found the icmp packages being blocked by the firewall.
-
> WAN 1: 8.8.8.8
> WAN 2: 8.8.8.8
Set WAN 2 to 8.8.4.4, this won't work otherwise.
Cheers,
Franco
-
Hi franco,
While it's perfectly reasonable/logical to have different Monitor IPs, why would it matter if using the same DNS server(s) on both gateways ?
-
Each DNS server will set a /32 host route through the specified gateway. You cannot have two routes through two gateways for the same destination. It will fail to resolve DNS when on WAN2.
-
Thanks franco, didn't knew the routes were actually set. Everything makes sense now.
-
It’s also described here in step 3:
https://docs.opnsense.org/manual/how-tos/multiwan.html
-
Does it work in your scenario? We have the same issue with dpinger but on a single gateway. No matter what monitoring IP we enter after some time dpinger reports package loss and then the gateway goes offline.
-
Just to feedback for someone having the same issue:
In our case the problem was caused by our ISP Unitymedia in Germany. After a certain period of time they activate some Anti-DoS rule and block our pings (according to their technical support this only happens if you use their DNS servers for name resolution and Google's or Cloudflare's DNS servers for monitoring due to the way that their IP is resolved). Our solution was to increase the probe interval to 15 sec and the time period to 120 sec and to eliminate their DNS servers from our setup.