One dpinger gateway status offline
I have two gateways set on my pfense and both gateways are monitored with dpinger. One gateway is my ISP (cable modem with IP from dhcp) and the other one is a VPN connection.
The VPN gateway (monitoring 184.108.40.206 ) shows RTT - 122ms, 2ms - RTTsd, 0.0% Loss and Online - Status correctly as expected.
However my ISP gateway (monitoring 220.127.116.11 ) is shows RTT - 0ms, 0ms - RTTsd, 100.0% Loss and Offline - Status, it shows this regardless of monitor IP and even when the connection is working fine, this problem started when I upgraded from 2.2.6 to 2.3 alpha few weeks ago.
Only info I can find about dpinger is under System -> Gateways
send_interval 250ms loss_interval 1250ms time_period 30000ms report_interval 0ms alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 18.104.22.168 bind_addr ***.***.***.*** identifier "WAN_DHCP "
send_interval 250ms loss_interval 1250ms time_period 30000ms report_interval 0ms alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 22.214.171.124 bind_addr ***.***.***.*** identifier "WAN2_DHCP "
Is there something wrong in my setup or with dpinger?
brianc69 last edited by
Shouldn't the VPN be checking a PC at the other end instead of Google?
Is that VPN connection OpenVPN?
I'm not aware of any issues along those lines, but not sure I've done much with dpinger with dynamic gateways on OpenVPN assigned interfaces yet. It seems to be the working one though. That's the one I'd expect to not work if anything.
What do you get for the following commands:
route -n get 126.96.36.199
ps auwwx|grep dpinger
Yes it's OpenVPN connection.
route -n get 188.8.131.52
route to: 184.108.40.206 destination: 220.127.116.11 gateway: ISP Gateway IP fib: 0 interface: re0 flags: <up,gateway,host,done,static>recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0</up,gateway,host,done,static>
root 86472 0.0 0.2 15004 2304 - Ss 1:42PM 0:00.03 /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B **ISP_IP** -p /var/run/dpinger_WAN_DHCP_**ISP_IP**_18.104.22.168.pid -u /var/run/dpinger_WAN_DHCP_**ISP_IP**_22.214.171.124.sock -C /etc/rc.gateway_alarm -s 250 -l 1250 -t 30000 -A 1000 -D 500 -L 20 126.96.36.199 root 86631 0.0 0.2 15004 2280 - Ss 1:42PM 0:00.03 /usr/local/bin/dpinger -S -r 0 -i WAN2_DHCP -B **VPN_IP** -p /var/run/dpinger_WAN2_DHCP_**VPN_IP**_188.8.131.52.pid -u /var/run/dpinger_WAN2_DHCP_**VPN_IP**_184.108.40.206.sock -C /etc/rc.gateway_alarm -s 250 -l 1250 -t 30000 -A 1000 -D 500 -L 20 220.127.116.11
Hope this helps.
That all looks correct. Do a packet capture on WAN filtered on host 18.104.22.168, all else at defaults. Let it run for about 10 seconds and stop it. What does that show?
It is all like the following:
06:03:37.002800 IP MY-IP > 22.214.171.124: ICMP echo request, id 20936, seq 23535, length 8
With the following exception happening once during the 10sec period:
06:03:43.916388 IP MY-IP.43911 > 126.96.36.199.53: UDP, length 43 06:03:43.941188 IP 188.8.131.52.53 > MY-IP.43911: UDP, length 88
Huh, so apparently 184.108.40.206 replies to DNS from that WAN, but not ping. Or maybe something upstream of you is blocking it. If you go to Diag>Ping and choose source WAN and try to ping 220.127.116.11 do you get a reply? Do you get a reply pinging 18.104.22.168 from hosts on the LAN going out via that same WAN?
Ping works from Diag>Ping as expected and it also works perfectly from any of the hosts on the LAN.
Also tried changing the 22.214.171.124 to 126.96.36.199 which works on the VPN interface but I get the same problem.
Ok, put it back to 188.8.131.52, and repeat that same packet capture on WAN. Leave it running for about 10 seconds to catch the monitor pings, then go to Diag>Ping and ping from source WAN. Then stop the capture, download the pcap file and either attach it here, or can email it to me (cmb at pfsense dot org) with a link to this thread.
Just sent the .cap file as email, thank you.
Working with shopro and dennypage we tracked this down to this.
Denny has updated dpinger (to version 1.5).
I expect that Renato will update the code in pfSense soon. You should have a version of pfSense software v2.3 (still BETA) that has the fix within a few days.
This option's been added to the gateway advanced settings. System>Routing, edit your gateway, specify something > 0 in the "Data Payload" field. Confirmed that works, and should definitely fix your issue shopro given the troubleshooting we've been through to narrow down and verify the issue.
Working like a charm. Thank you! :)
Good to hear. Thanks Denny!
dennypage last edited by