pfSense 2.7 with an old 2.4.5 config failing to upgrade
-
@stephenw10 No GRE tunnels, but there are IPSecs and one of them (V1) has 28 x P2 tunnels some of which may be overlapping because it can not be converted to V2.
Btw 2.6 has no problems with that config. Or at least on the surface. And then I can upgrade to 2.7. Which probably means that something changed in the upgrade process from 2.6 to 2.7 which is strange. I saw that they are just functions upgrade_X_to_Y() which upgrade the conf versions and they were not supposed to change or should have failed when I upgraded from 2.6 to 2.7 too.Btw I'm seeing things like this:
route: route has not been found route: route has not been found route: route has not been foundAnd this:
Setting up extended sysctls...sysctl: empty numeric value sysctl: kern.ipc.nmbclusters=131072: Invalid argument sysctl: empty numeric value sysctl: kern.ipc.nmbclusters=131072: Invalid argument done. -
Did you previously have any GRE tunnels? Check in the config directly for any gre/gres tags.
That section would not have run when you upgraded from 2.6 because the config version would already have been above that. It runs when you import an older config with a version of 20.2 or older which means from pfSense 2.4.X or before. See: https://docs.netgate.com/pfsense/en/latest/releases/versions.html
-
@stephenw10 This are the only lines with "gre" (excluding the certificates)
<priv>page-interfaces-gre</priv> <priv>page-interfaces-gre-edit</priv> <gres></gres> -
That's from the 2.4 config before it is restored?
-
@stephenw10 yes on the live router.
-
Ok, that looks like a bug. https://redmine.pfsense.org/issues/14859
You can workaround it by simply removing the
<gres></gres>line before importing it if you need to.Steve
-
@stephenw10 That worked! Nice catch, thank you! Sorry for replying that slow, I couldn't test it until now.
-
I'm having a similar problem, but I'm upgrading from 2,2.6. I've looked for gre/gres in my config but don't see that anywhere. I do have a IPSec connection though.
My error also has different numbers and paths.
Fatal error: Uncaught TypeError: Unsupported operand types: string * int in /etc/inc/upgrade_config.inc:4163
Stack trace:
#0 /etc/inc/config.lib.inc(513): upgrade_130_to_131()
#1 /usr/local/pfSense/include/www/backup.inc(403): convert_config()
#2 /usr/local/www/diag_backup.php(63): execPost(Array, Array)
#3 {main} thrown in /etc/inc/upgrade_config.inc on line 4163
PHP ERROR: Type: 1, File: /etc/inc/upgrade_config.inc, Line: 4163, Message: Uncaught TypeError: Unsupported operand types: string * int in /etc/inc/upgrade_config.inc:4163
Stack trace:
#0 /etc/inc/config.lib.inc(513): upgrade_130_to_131()
#1 /usr/local/pfSense/include/www/backup.inc(403): convert_config()
#2 /usr/local/www/diag_backup.php(63): execPost(Array, Array)
#3 {main} thrownAny ideas?
-
@davin-landry said in pfSense 2.7 with an old 2.4.5 config failing to upgrade:
upgrade_config.inc:4163
That code updates custom gateway monitoring settings to be valid in newer instances.
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/upgrade_config.inc#L4161Do you have custom gateway values in your config?
Steve
-
Yes I do, we have 4 entries in 'Gateways' and 2 rely on the IPSec connection.
Also, sorry for the delay in responding.
-
Ah so gateways at the remote side of a VTI tunnel?
That should still be valid. Do you have custom values in those? Latency, ping frequency etc?
-
Yeah, they are for AWS. But no, no custom values, just have monitoring turned off.
-
Can we see the gateways section from the config you are importing? You can redact any public IP there if you wish.
-
-
That appears to be only the ipsec config. What matters here is the gateway section like:
<gateways> <gateway_item> <interface>opt9</interface> <gateway>172.27.116.1</gateway> <name>WG0GW</name> <weight>1</weight> <ipprotocol>inet</ipprotocol> <descr></descr> <monitor_disable></monitor_disable> <gw_down_kill_states></gw_down_kill_states> </gateway_item> <gateway_item> <interface>opt14</interface> <gateway>dynamic</gateway> <name>GIF0_TUNNELV4</name> <weight>1</weight> <ipprotocol>inet</ipprotocol> <descr><![CDATA[Interface GIF0_TUNNELV4 Gateway]]></descr> </gateway_item> <gateway_item> <interface>opt17</interface> <gateway>dynamic</gateway> <name>WWAN0_PPP</name> <weight>1</weight> <ipprotocol>inet</ipprotocol> <interval>5000</interval> <time_period>100000</time_period> <alert_interval>20000</alert_interval> <descr><![CDATA[Interface WWAN0_PPP Gateway]]></descr> <monitor>1.1.1.1</monitor> <loss_interval>19995</loss_interval> </gateway_item> <gateway_item> <interface>opt25</interface> <gateway>10.0.2.1</gateway> <name>WG_GW0</name> <weight></weight> <ipprotocol>inet</ipprotocol> <descr><![CDATA[Wireguard gateway]]></descr> <gw_down_kill_states></gw_down_kill_states> </gateway_item> <defaultgw4>WAN_DHCP</defaultgw4> <defaultgw6></defaultgw6> </gateways> -
Sorry. Here you go.
-
Great. Nothing jumps out at me there, I've raised it with our devs.
-
Hmm, OK are you able to retest that?
If so try removing the
<interval/>lines from the config before importing it. If that prevents the error we should be able to add something to allow it. -
Yes I can retry, I'll let you know something after the holiday.
-
Test was successful most of the settings are now in the new system. A few things aren't working, like the openVPN service and DHCP service won't start but I think it might be because it doesn't have any real connections.
I'm also getting the following error now.PHP Errors:
[28-Nov-2023 03:29:20 America/Chicago] PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /etc/inc/upgrade_config.inc:4290
Stack trace:
#0 /etc/inc/config.lib.inc(513): upgrade_136_to_137()
#1 /etc/rc.bootup(135): convert_config()
#2 {main}
thrown in /etc/inc/upgrade_config.inc on line 4290
