*SOLVED* OpenVPN TAP interface does not come back after server edit

ahull

Hello fellow pfSensers. I'm a long time pfSense user (1.x days) and forum lurker. I'm hoping that I can receive some helpful advice on an odd issue.

I have 4 2.1 devices out there (all using OpenVPN TAP servers for my remote administrative access) and 1 is exhibiting the following issue:

The easiest way to reproduce is to edit the OpenVPN server and hit the save button. In normal operation, this will restart the related processes, and in the process bounce the interface that I have assigned to ovpns1. In a normal situation, the interface will be down for 15 seconds or less then come back up and all is well again.

On one of my pfSense devices, this does not happen. The ovpns1 interface stays down and will not come back up unless I manually edit the interface and click "save." After doing so, the interface comes back up and all is well again.

Here are syslog snips of functional and nonfunctional events:

Normal:

Dec 12 21:40:05	php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (opt2).
Dec 12 21:40:01	check_reload_status: Configuring interface opt2
Dec 12 21:40:01	php: rc.newwanip: rc.newwanip: Failed to update opt2 IP, restarting...
Dec 12 21:40:01	php: rc.newwanip: rc.newwanip: on (IP address: ) (interface: opt2) (real interface: ovpns1).
Dec 12 21:40:01	php: rc.newwanip: rc.newwanip: Informational is starting ovpns1.
Dec 12 21:39:53	check_reload_status: Syncing firewall
Dec 12 21:39:51	check_reload_status: rc.newwanip starting ovpns1
Dec 12 21:39:51	kernel: ovpns1: link state changed to UP
Dec 12 21:39:50	check_reload_status: Reloading filter
Dec 12 21:39:50	kernel: ovpns1: link state changed to DOWN

And here is from the device that does not work:

Dec 12 21:46:49	php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (opt2).
Dec 12 21:46:49	php: rc.newwanip: Interface does not have an IP address, nothing to do.
Dec 12 21:46:49	php: rc.newwanip: rc.newwanip: Informational is starting ovpns1.
Dec 12 21:46:47	check_reload_status: Syncing firewall
Dec 12 21:46:46	check_reload_status: rc.newwanip starting ovpns1
Dec 12 21:46:46	kernel: ovpns1: link state changed to UP
Dec 12 21:46:46	check_reload_status: Reloading filter
Dec 12 21:46:46	kernel: ovpns1: link state changed to DOWN

Both devices were configured identically, using the same OpenVPN TAP 2.1 tutorial found here.
Both devices are running 2.1-RELEASE on Atom machies

Now, let me tell you about the differences.

The functional machine is running i386 where as the misbehaving machine is running AMD64
The misbehaving machine is a Netgate FW-7541 (http://store.netgate.com/Netgate-FW-7541-BTO-P1893C83.aspx) and came with pfSense pre-installed.
The pre-install appears to be running a copy of pfSense that they built internally: the build date on this device for 2.1-RELEASE (amd64) is Wed Oct 23 16:08:46 EDT 2013 and the firmware update notifies was factory set to the URL: https://firmware.netgate.com/auto-update/full_install/amd64
It is also notifying me that 2.1p1-RELEASE is now available for update/install?!?!?!

Also, aPinger won't seem to stay alive for more than an hour or two on this device

So I guess my questions are morphing into:
Is this an issue that anyone has experienced before?
Does anyone have any experience or knowledge into what Netgate is going here?
Do I just need to take this box down for maintenance, wipe, and do a clean install from a valid source… and resume troubleshooting is the issue persists?

Thanks for reading and responding, I appreciate it.

ahull

Well, the firmware update solved the VPN and aPinger issues.

My long term to do list includes switching this router over the straight pfSense, but all is well for now.

Andy