An earnest appeal - please do fix APINGER in 2.2
-
I don't think this is related to the main issue described here, but I have observed a similar behavior under high network load and while using the traffic shaper, because the ping probes are put on the default queue instead of the one specified by the floating rule on WAN that is supposed to handle the situation. Probably this happens because apinger starts before the firewall itself, since killing the related states makes them go into the correct queue immediately
-
Issue still exsits in recent bulids in my testing enviroments.
-
…and frequently results in tunnels (IPsec or openVPN) going down for no obvious reasons, except for apinger freakin' out.
I increased the times for apinger alarm significantly, that helps at least a little...
-
I dont have these problems at all running 40+ pfsenses….
I use traceroute to monitor the wanted IP upstream to decide if the GW is down.
All are stable currently running 0% packetloss..... No change from 2.0.X
I dont like the idea of monitoring other external hosts not in your upstream environment. That way you dont get a real picture of your GW status.
-
I dont have these problems at all running 40+ pfsenses….
What's your config for WAN interfaces? I see allot of people write that have problems but doesn't put configs to help troubleshoot the problem.
Some times i have the problem in my multi-wan interface (PPPoE only config user and pass and a ppp (LTE) WAN only config default number). Don't see the problem when i disconnect my ppp.
-
More or less the same for all 40+….
-
I use traceroute to monitor the wanted IP upstream to decide if the GW is down.
All are stable currently running 0% packetloss….. No change from 2.0.X
I dont like the idea of monitoring other external hosts not in your upstream environment. That way you dont get a real picture of your GW status.
Could you please tell us how to use traceroute to monitor the wanted IP upstream to decide if the GW is down?
Multi-wan with static IPs and different gateways within each wan subnets are stable at least in my tests, but I use pppoe connections and we get the same gateway IP allmost all the times, so we have to set at least one monitor IP outside the wan subnet, and this line with outside monitor ip allways gets offline as the apinger reported, but the connection functional as normal.
If there is another to monitor the gatwway, that really helps.
-
http://ping.eu/traceroute/
Use the first one thats not in your WAN subnet.
-
http://ping.eu/traceroute/
Use the first one thats not in your WAN subnet.
It's not within pfsense, and not done automaticly either?
-
I understand why you are confused…
I use traceroute to monitor the wanted IP upstream to decide if the GW is down.
I use traceroute to locate the IP to monitor and then use the built in GW monitor tool in PFSense.
Works fine here.
-
I understand why you are confused…
I use traceroute to monitor the wanted IP upstream to decide if the GW is down.
I use traceroute to locate the IP to monitor and then use the built in GW monitor tool in PFSense.
Works fine here.
OK, I did that several months ago, and with no use.
The next hop routers are always outside my wan subnet:(Thanks anyway.
-
I've been running into quite a few problems with apinger in the 2.1 series with a simple single wan configuration.
https://redmine.pfsense.org/issues/3692
I was thinking that I would try to debug it and went looking for the source code to apinger but wasn't able to find it in the 2.1.5 main or packages. Can someone send me a pointer to it?
Thanks
-
I've been running into quite a few problems with apinger in the 2.1 series with a simple single wan configuration.
https://redmine.pfsense.org/issues/3692
I was thinking that I would try to debug it and went looking for the source code to apinger but wasn't able to find it in the 2.1.5 main or packages. Can someone send me a pointer to it?
Thanks
The source code is in the pfsense-tools repo. You must complete a couple of electronic documents in order to access it. Access is controlled via SSH public keys. It is based off the FreeBSD port here: http://www.freshports.org/net/apinger/
Information on what is required to get access is posted in a Sticky Thread at the top of the Development sub-forum here: https://forum.pfsense.org/index.php?topic=76132.0.
Bill
-
The source code is in the pfsense-tools repo. You must complete a couple of electronic documents in order to access it. Access is controlled via SSH public keys. It is based off the FreeBSD port here: http://www.freshports.org/net/apinger/
Information on what is required to get access is posted in a Sticky Thread at the top of the Development sub-forum here: https://forum.pfsense.org/index.php?topic=76132.0.
Thanks. I downloaded what I thought was the packages distribution from
https://github.com/pfsense/pfsense-packages/releases/tag/RELENG_2_1_5
but apinger wasn't in there. Is there a different repo?
-
the packages repo is only for optional addons. (stuff that is not included in a base-install from CD)
i believe bmeeks said in which repo you can find apinger, and how to access it
-
the packages repo is only for optional addons. (stuff that is not included in a base-install from CD)
i believe bmeeks said in which repo you can find apinger, and how to access it
Correct. It's in the pfsense-tools repo which is NOT hosted on Github directly. It's hosted on a server operated by the pfSense team and you must follow the instructions in the link I posted above to gain access to the repo.
Bill
-
I pushed a fix.
Please try with next snapshots and see if you still get the same issues.
-
@ermal:
I pushed a fix.
Please try with next snapshots and see if you still get the same issues.
Still broken for me. :( See attachment. Let me know if there is anything else I can provide.
-
Any update on the matter ?
My box just went dark after apinger decided that the wan is not up and then remained stuck with a cpu load of 99% denying to be restarted.
-
APINGER does't cope well with my WAN flapping whenever this happens my HENET ipv6 gateway starts reporting loss forever even though the ipv6 tunnel is backup and stable!
