https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162013-04-25T08:06:39ZpfSense bugtrackerpfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=113682013-04-25T08:06:39ZRenato Botelhorenato@netgate.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li><li><strong>Assignee</strong> set to <i>Renato Botelho</i></li></ul><p>I couldn't reproduce here. What exactly happens after reboot? Monitoring shows gateway as offline? Is it possible to share your config.xml (hiding sensitive parts) with me?</p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=113812013-04-26T07:02:58ZPascal Huesch
<ul></ul><p>It says: RTT: pending/~ Loss: pending/~ Status: unknown.</p>
<p>I've sent the XML to the mail-address in your profile.</p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=113832013-04-26T09:50:31ZRenato Botelhorenato@netgate.com
<ul></ul><p>Please send me the output of the following commands when monitor is broken:</p>
<ol>
<li>ifconfig ovpnc1</li>
<li>netstat -nrf inet</li>
<li>route get 8.8.8.8</li>
<li>cat /var/etc/apinger.conf</li>
</ol> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=113862013-04-29T03:41:14ZPascal Huesch
<ul></ul><p><strong>ifconfig</strong><br /><pre>
@ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet6 fe80::20c:29ff:fee3:15e8%ovpnc1 prefixlen 64 scopeid 0x8
inet 10.8.3.102 --> 10.8.3.101 netmask 0xffffffff
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
Opened by PID 78551
</pre></p>
<p><strong>netstat</strong><br /><pre>
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.10.0.1 UGS 0 582 em1
10.8.3.97/32 10.8.3.101 UGS 0 0 ovpnc1
10.8.3.101 link#8 UH 0 0 ovpnc1
10.8.3.102 link#8 UHS 0 0 lo0
10.10.0.0/16 link#2 U 0 196 em1
10.10.68.209 link#2 UHS 0 0 lo0
127.0.0.1 link#6 UH 0 0 lo0
192.168.1.0/24 link#1 U 1 4243 em0
192.168.1.1 link#1 UHS 0 0 lo0
</pre></p>
<p><strong>route</strong><br /><pre>
route to: google-public-dns-a.google.com
destination: default
mask: default
gateway: heaven.office.turtle-entertainment.de
interface: em1
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0
</pre></p>
<p><strong>/var/etc/apinger.conf</strong><br /><pre>
# pfSense apinger configuration file. Automatically Generated!
## User and group the pinger should run as
user "root"
group "wheel"
## Mailer to use (default: "/usr/lib/sendmail -t")
#mailer "/var/qmail/bin/qmail-inject"
## Location of the pid-file (default: "/var/run/apinger.pid")
pid_file "/var/run/apinger.pid"
## Format of timestamp (%s macro) (default: "%b %d %H:%M:%S")
#timestamp_format "%Y%m%d%H%M%S"
status {
## File where the status information should be written to
file "/var/run/apinger.status"
## Interval between file updates
## when 0 or not set, file is written only when SIGUSR1 is received
interval 5s
}
########################################
# RRDTool status gathering configuration
# Interval between RRD updates
rrd interval 60s;
## These parameters can be overridden in a specific alarm configuration
alarm default {
command on "/usr/local/sbin/pfSctl -c 'service reload dyndns %T' -c 'service reload ipsecdns' -c 'service reload openvpn %T' -c 'filter reload' "
command off "/usr/local/sbin/pfSctl -c 'service reload dyndnsall' -c 'service reload ipsecdns' -c 'service reload openvpn' -c 'filter reload' "
combine 10s
}
## "Down" alarm definition.
## This alarm will be fired when target doesn't respond for 30 seconds.
alarm down "down" {
time 10s
}
## "Delay" alarm definition.
## This alarm will be fired when responses are delayed more than 200ms
## it will be canceled, when the delay drops below 100ms
alarm delay "delay" {
delay_low 200ms
delay_high 500ms
}
## "Loss" alarm definition.
## This alarm will be fired when packet loss goes over 20%
## it will be canceled, when the loss drops below 10%
alarm loss "loss" {
percent_low 10
percent_high 20
}
target default {
## How often the probe should be sent
interval 1s
## How many replies should be used to compute average delay
## for controlling "delay" alarms
avg_delay_samples 10
## How many probes should be used to compute average loss
avg_loss_samples 50
## The delay (in samples) after which loss is computed
## without this delays larger than interval would be treated as loss
avg_loss_delay_samples 20
## Names of the alarms that may be generated for the target
alarms "down","delay","loss"
## Location of the RRD
#rrd file "/var/db/rrd/apinger-%t.rrd"
}
target "8.8.8.8" {
description "STRONG_VPNV4"
srcip "10.8.3.102"
alarms override "loss","delay","down";
rrd file "/var/db/rrd/STRONG_VPNV4-quality.rrd"
}
target "10.10.0.1" {
description "WAN_DHCP"
srcip "10.10.68.209"
alarms override "loss","delay","down";
rrd file "/var/db/rrd/WAN_DHCP-quality.rrd"
}
</pre></p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=113902013-04-29T14:22:43ZRenato Botelhorenato@netgate.com
<ul></ul><p>When monitor is failing, are you able to ping 8.8.8.8 with source set to 10.8.3.102?</p>
<ol>
<li>ping -S 10.8.3.102 8.8.8.8</li>
</ol> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=113912013-04-30T02:54:57ZPascal Huesch
<ul></ul><p>Yes. Ping goes through while the Gateway is shown as offline.</p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=113922013-04-30T03:00:05ZPascal Huesch
<ul></ul><p>I just noticed, that killing apinger and restarting it from the shell also brings the gateway back online.</p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=113962013-05-01T05:45:32ZRenato Botelhorenato@netgate.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>New</i></li></ul> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=114102013-05-02T13:51:49ZRenato Botelhorenato@netgate.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>Pascal Huesch wrote:</p>
<blockquote>
<p>I just noticed, that killing apinger and restarting it from the shell also brings the gateway back online.</p>
</blockquote>
<p>Interesting, did apinger leave any information on logs?</p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=114872013-05-13T03:48:43ZPascal Huesch
<ul></ul><p>Hi Renato, sorry for my late reply.</p>
<p>When I boot the machine the gateway log looks like this: (Monitoring down)</p>
<p><code>May 13 10:44:11 apinger: ALARM: VPNV4(8.8.8.8) *** down ***<br />May 13 10:44:01 apinger: Starting Alarm Pinger, apinger(14374)<br />May 13 10:44:00 apinger: Exiting on signal 15.<br />May 13 10:43:56 apinger: bind socket: Can't assign requested address<br />May 13 10:43:56 apinger: Starting Alarm Pinger, apinger(15720)<br />May 13 10:43:55 apinger: Exiting on signal 15.<br />May 13 10:43:48 apinger: Starting Alarm Pinger, apinger(28362)<br />May 13 10:43:47 apinger: Exiting on signal 15.<br />May 13 10:43:46 apinger: Starting Alarm Pinger, apinger(20424)</code></p>
<p>After restarting apinger from console: (Monitoring working)</p>
<p><code>May 13 10:46:16 apinger: Starting Alarm Pinger, apinger(64396)<br />May 13 10:46:13 apinger: Exiting on signal 15.</code></p>
<p>I also noticed some logs regarding the VPN interface in the general log.</p>
<p><code>May 13 10:44:21 check_reload_status: Reloading filter<br />May 13 10:44:21 check_reload_status: Restarting OpenVPN tunnels/interfaces<br />May 13 10:44:21 check_reload_status: Restarting ipsec tunnels<br />May 13 10:44:21 check_reload_status: updating dyndns VPNV4<br />May 13 10:44:11 php: : Restarting/Starting all packages.<br />May 13 10:44:08 check_reload_status: Reloading filter<br />May 13 10:44:08 check_reload_status: Starting packages<br />May 13 10:44:08 php: : pfSense package system has detected an ip change 10.8.3.102 -> 10.8.3.102 ... Restarting packages.<br />May 13 10:44:06 php: : Creating rrd update script<br />May 13 10:44:03 php: : pfSense package system has detected an ip change 10.8.3.102 -> 10.8.3.102 ... Restarting packages.<br />May 13 10:44:01 php: : Creating rrd update script<br />May 13 10:44:00 php: : Removing static route for monitor 8.8.8.8 and adding a new route through 10.8.3.101<br />May 13 10:44:00 php: : rc.newwanip: on (IP address: 10.8.3.102) (interface: opt1) (real interface: ovpnc1).<br />May 13 10:44:00 php: : rc.newwanip: Informational is starting ovpnc1.<br />May 13 10:44:00 php: : Restarting/Starting all packages.<br />May 13 10:43:58 check_reload_status: rc.newwanip starting ovpnc1<br />May 13 10:43:58 kernel: ovpnc1: link state changed to UP</code></p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=114882013-05-13T05:21:06ZPhillip Davisphil@jankaritech.com
<ul></ul><p>I made a few fixes to the logic of when and which OpenVPN instances are restarted after a linkup/linkdown event. The last of these commits was <a class="external" href="https://github.com/pfsense/pfsense/commit/ddae03adaa76750dc678e62a73de22ccee98757d">https://github.com/pfsense/pfsense/commit/ddae03adaa76750dc678e62a73de22ccee98757d</a><br />It did not directly address messages like "apinger: Exiting on signal 15.", so your problem might still be there. But it would be useful to confirm that you still have the problem on a 2.1 build from 8 May 2013 or later. (I would like to understand and sort out what your problem really is, as I am also interested in ensuring that OpenVPN links come back up in all conditions.)</p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=114892013-05-13T06:04:43ZPascal Huesch
<ul></ul><p>Hi Phillip,</p>
<p>I've updated my installation to: 2.1-BETA1 (amd64) built on Mon May 13 00:54:29 EDT 2013</p>
<p>It is still the same behavior.</p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=115072013-05-16T08:40:21ZRenato Botelhorenato@netgate.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>New</i></li></ul> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=117662013-06-26T06:47:59ZRenato Botelhorenato@netgate.com
<ul></ul><p>I was reading the whole story again since I was not able to reproduce the issue, and I have a suspect. Could you please show me the config.xml (removing sensitive data)?</p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=118562013-07-05T11:20:27ZErmal Luçieri@pfsense.org
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>This should behave better with tomorrow snapshot due to a fix done in gateway monitoring.<br />Can you confirm this is the case?</p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=123402013-09-03T08:34:33ZChris Buechlercbuechler@gmail.com
<ul></ul><p>I can replicate this, but I think fixing <a class="issue tracker-1 status-3 priority-5 priority-high4 closed" title="Bug: Gateway failure not properly detected in certain cases using a monitor IP outside of the WAN's su... (Resolved)" href="https://redmine.pfsense.org/issues/3179">#3179</a> will fix this as well. Will leave to feedback to test again after 3179 is fixed.</p> pfSense - Bug #2951: OpenVPN and alternative monitoring IP in 2.1https://redmine.pfsense.org/issues/2951?journal_id=123742013-09-04T08:23:29ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>confirmed fixed</p>