Pfsense "refreshes" interfaces unneccessary and many bugs in 2.1.4 to 2.1.5
-
I found out that my internet Connection drops once each day. This drops are permanent until manual intervenion is done.
This problem did NOT exist in 2.1.4, it was added in 2.1.5.
Sep 5 05:20:38 php: rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANVPN1_IPv6GW.
Sep 5 05:20:37 php: rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANVPN1_VPNV4.
Sep 5 05:20:35 check_reload_status: Reloading filter
Sep 5 05:20:35 check_reload_status: Restarting OpenVPN tunnels/interfaces
Sep 5 05:20:35 check_reload_status: Restarting ipsec tunnels
Sep 5 05:20:35 check_reload_status: updating dyndns WANVPN1_IPv6GW
Sep 5 05:20:35 check_reload_status: Reloading filter
Sep 5 05:20:35 check_reload_status: Restarting OpenVPN tunnels/interfaces
Sep 5 05:20:35 check_reload_status: Restarting ipsec tunnels
Sep 5 05:20:35 check_reload_status: updating dyndns WANVPN1_VPNV4Theres no "dyndns" on WANVPN1_VPNV4 and WANVPN1_IPv6GW.
What are it doing? WANVPN1_VPNV4 is a static OpenVPN client instance that goes thorugh the interface WAN, and WANVPN1_IPv6GW is a He.net GIF tunnel that is using WAN.
I have a dynamic OpenVPN client on WANVPN2 too, that goes through WAN. That interface is NOT restarted. So you can't blame anything on my WAN (standard internet Connection).The interfaces WANVPN1_VPNV4 and WANVPN1_IPv6GW shut down for a period of about 1 hour Before coming online again.
This unneccessary reloading causes Unbound (DNS resolver) to shut down permanently and not restart automatically again.
Only way to get Unbound running again is to manually restart it via web interface.Why are pfsense reloading these interfaces?
And what is this?
Sep 5 05:23:46 php: rc.newwanip: pfSense package system has detected an ip change 10.58.0.6 -> 10.58.0.6 … Restarting packages.I dont call that a "ip change".
And this is some problem too that existed in the 2.1.4, but did not cause a problem. Now its causes a problem due to these unneccessary reloads:
Sep 5 05:23:39 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (opt3).
Sep 5 05:23:39 php: rc.filter_configure_sync: Could not find IPv6 gateway for interface(opt3).opt3 is a Virtual Netowrk Adapter for a OpenVPN roadwarrior SERVER. opt3 is configured exactly like LAN, thus have NO gateways configured (and should not have any gateways configured).
-
I think you have a bug in your config.
-
Could you point him in some sort of direction for solving this??
@gonzopancho:
I think you have a bug in your config.
-
I had the same when I upgraded from 2.1.2 to 2.1.3
see this topic https://forum.pfsense.org/index.php?topic=76597
Since I get a static IP and IPv6 network from my provider I modified the /etc/rc.newwanip and /etc/rc.newwanip6 to return without any actions.
After the upgrade from 2.1.3 to 2.1.4 the issue returned as these files were overwritten by the new ones.
Also now I modified both files.I know it's not a very nice solution but for now I can live with it as my IP address never change.
Still I haven't been able to figure out the reason of this behavior. -
Could you point him in some sort of direction for solving this??
@gonzopancho:
I think you have a bug in your config.
As posted, he's edited two of the rc files to return without action.
Likely he was affected by the bug that this commit closed
https://github.com/pfsense/pfsense/commit/38f6f50a84e78eddbe4d639914422789ad0057d5he could have also been affected by the bug that placed a zero route (fixed in 2.1.5), but now, since he's hacked his system (completely allowed, but we're not responsible for the results, obviously), all bets are off.
-
As posted, he's edited two of the rc files to return without action.
Likely he was affected by the bug that this commit closed
https://github.com/pfsense/pfsense/commit/38f6f50a84e78eddbe4d639914422789ad0057d5he could have also been affected by the bug that placed a zero route (fixed in 2.1.5), but now, since he's hacked his system (completely allowed, but we're not responsible for the results, obviously), all bets are off.
I was affected by that bug as well. I changed that, (see this thread https://forum.pfsense.org/index.php?topic=76597.0) but still saw the issue.
At that time I edited the rc files to return without action.However in 2.1.4 I still see the interface refreshing. At first it looked like I was the only one suffering from this but not anymore.
For me, since I have static IP's I have a quick and certainly dirty workaround although I still have to look for the reason of this.
I will upgrade to 2.1.5 when time permits to find out if it is solved in this release -
Upgrading takes less time that replying to the thread….
-
Upgrading takes less time that replying to the thread….
Can you say the same for a system that's running embedded? :'(
-
Don't get me started - hehe.
Yeah. Embedded can sometimes take some time. -
I updated a different old post- but related to this- this morning
https://forum.pfsense.org/index.php?topic=68229.msg467037#msg467037
I think the strange timestamps in the system log are somehow a key factor in this- because only the lines that start with "check_reload_status" have the incorrect timestamp. I am also using an embedded image.