pfSense 2.7 with an old 2.4.5 config failing to upgrade

tbyte

@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 found

And 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.

stephenw10

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

tbyte

@stephenw10 This are the only lines with "gre" (excluding the certificates)

                        <priv>page-interfaces-gre</priv>
                        <priv>page-interfaces-gre-edit</priv>
        <gres></gres>

stephenw10

That's from the 2.4 config before it is restored?

tbyte

@stephenw10 yes on the live router.

stephenw10

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

tbyte

@stephenw10 That worked! Nice catch, thank you! Sorry for replying that slow, I couldn't test it until now.

davin.landry

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} thrown

Any ideas?

stephenw10

@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#L4161

Do you have custom gateway values in your config?

Steve

davin.landry

@stephenw10

Yes I do, we have 4 entries in 'Gateways' and 2 rely on the IPSec connection.

Also, sorry for the delay in responding.

stephenw10

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?

davin.landry

Yeah, they are for AWS. But no, no custom values, just have monitoring turned off.

stephenw10

Can we see the gateways section from the config you are importing? You can redact any public IP there if you wish.

davin.landry

config-router.xml

stephenw10

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>

davin.landry

Sorry. Here you go.

config-router.xml

stephenw10

Great. Nothing jumps out at me there, I've raised it with our devs.

stephenw10

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.

davin.landry

Yes I can retry, I'll let you know something after the holiday.

davin.landry

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