[Solved?] Upgrade from 2.6.0 to 2.7.0 multiple gui issues, freezes, long wait times etc.
-
I am not an expert with the software, so explaining processes like to a kid is appreciated.
I don't touch settings that I don't know what they do, and they are extensive, so asking for some help.Before upgrading;
System -> Update/Package Manager worked fine.After:
System -> Update not accessible, infinite loading.
System -> Package Manager -> Available packages load incredibly slow. Once package is selected and confirmed, it will take about 1-2 minutes to go to a blank page, f12 network error was something about impartial PHP file transfer.What I've tried;
Restarting.SOLUTION:
I looked at the logs, it mentioned my openvpn. I decided to disable that interface and it now works. Okay? I have no clue, but I am attaching logs too.
I haven't really used that interface for anything, so no big loss. Did pfsense use that instead of WAN?Logs:
Dec 8 22:30:26 xinetd 43942 Reconfigured: new=0 old=2 dropped=0 (services) Dec 8 22:30:26 xinetd 43942 readjusting service 19001-tcp Dec 8 22:30:26 xinetd 43942 readjusting service 19000-tcp Dec 8 22:30:26 xinetd 43942 Swapping defaults Dec 8 22:30:26 xinetd 43942 Starting reconfiguration Dec 8 22:30:26 php-fpm 94224 /rc.start_packages: Restarting/Starting all packages. Dec 8 22:30:25 check_reload_status 417 Reloading filter Dec 8 22:30:25 check_reload_status 417 Starting packages Dec 8 22:30:25 php-fpm 378 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.0.48 -> 10.8.0.25 - Restarting packages. Dec 8 22:30:24 xinetd 43942 Reconfigured: new=0 old=2 dropped=0 (services) Dec 8 22:30:24 xinetd 43942 readjusting service 19001-tcp Dec 8 22:30:24 xinetd 43942 readjusting service 19000-tcp Dec 8 22:30:24 xinetd 43942 Swapping defaults Dec 8 22:30:24 xinetd 43942 Starting reconfiguration Dec 8 22:30:24 php-fpm 94224 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed IP addresses. Reloading endpoints that may use OVPNMULLVAD1_VPNV4. Dec 8 22:30:24 php-fpm 94224 /rc.openvpn: Gateway, NONE AVAILABLE Dec 8 22:30:24 php-fpm 94224 /rc.openvpn: Gateway, NONE AVAILABLE Dec 8 22:30:23 php-fpm 378 /rc.newwanip: Creating rrd update script Dec 8 22:30:23 php-fpm 378 /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.0.48. Dec 8 22:30:23 php-fpm 378 /rc.newwanip: Gateway, NONE AVAILABLE Dec 8 22:30:23 php-fpm 378 /rc.newwanip: Gateway, NONE AVAILABLE Dec 8 22:30:23 check_reload_status 417 Reloading filter Dec 8 22:30:23 check_reload_status 417 Restarting OpenVPN tunnels/interfaces Dec 8 22:30:23 check_reload_status 417 Restarting IPsec tunnels Dec 8 22:30:23 check_reload_status 417 updating dyndns OVPNMULLVAD1_VPNV4 Dec 8 22:30:23 rc.gateway_alarm 2952 >>> Gateway alarm: OVPNMULLVAD1_VPNV4 (Addr:1.1.1.1 Alarm:1 RTT:0ms RTTsd:0ms Loss:100%) Dec 8 22:30:21 php-fpm 378 /rc.newwanip: Removing static route for monitor 1.1.1.1 and adding a new route through 10.8.0.1 Dec 8 22:30:20 xinetd 43942 Reconfigured: new=0 old=2 dropped=0 (services) Dec 8 22:30:20 xinetd 43942 readjusting service 19001-tcp Dec 8 22:30:20 xinetd 43942 readjusting service 19000-tcp Dec 8 22:30:20 xinetd 43942 Swapping defaults Dec 8 22:30:20 xinetd 43942 Starting reconfiguration Dec 8 22:30:20 php-fpm 378 /rc.newwanip: rc.newwanip: on (IP address: 10.8.0.25) (interface: OVPNMULLVAD1[opt1]) (real interface: ovpnc1). Dec 8 22:30:20 php-fpm 378 /rc.newwanip: rc.newwanip: Info: starting on ovpnc1. Dec 8 22:30:19 xinetd 43942 Reconfigured: new=0 old=2 dropped=0 (services) Dec 8 22:30:19 xinetd 43942 readjusting service 19001-tcp Dec 8 22:30:19 xinetd 43942 readjusting service 19000-tcp Dec 8 22:30:19 xinetd 43942 Swapping defaults Dec 8 22:30:19 xinetd 43942 Starting reconfiguration Dec 8 22:30:19 check_reload_status 417 rc.newwanip starting ovpnc1 Dec 8 22:30:19 kernel ovpnc1: link state changed to UP Dec 8 22:30:18 check_reload_status 417 Reloading filter Dec 8 22:30:18 kernel ovpnc1: link state changed to DOWN -
I'd guess the OpenVPN server is passing a default route to the client. Unless you've disabled that the the VPN will become the default route for the firewall when it connects.
