previously working: -> The backup firewall is not accessible or not configured.

[Wolfspyre]

I've a pair of hosts running OPNsense 24.7.a_341 (X11SDV-4C-TP8F)

igb0 is their heartbeat interface, crossconnected

Code: [Select]

[root@evey /usr/local/etc]# ifconfig igb0
igb0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: Heartbeat (opt1)
options=4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
ether 00:xx:xx:xx:xx:e8
inet xx.xx.100.3 netmask 0xfffffff8 broadcast xx.xx.100.7
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


Code: [Select]

[root@atticus /home/wolfspyre]# ifconfig igb0
igb0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: Heartbeat (opt1)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,NOMAP>
ether 00:xx:xx:xx:xx:c8
inet xx.xx.100.2 netmask 0xfffffff8 broadcast xx.xx.100.7
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

they can ping/interact across the hb interface.

failover still generally works... (carp)
however recently I noticed that an haproxy change I made didn't synchronize to the secondary....
I went to jiggle the handle, and got the response in the webUI `the backup firewall is not accessible or not configured`

this is weird, as things had been working fine (and honestly, I'm not sure when things **STOPPED** working, because the opnsense-log output is so clogged with the erroneous 
`telemetry token missing in /usr/local/etc/suricata/rule-updater.config` messages, I didn't notice:

Code: [Select]

<11>1 2024-04-10T18:20:00-05:00 evey.wolfspyre.com opnsense-devel 47647 - [meta sequenceId="3"] /usr/local/etc/rc.filter_synchronize: An error occurred while attempting XMLRPC sync with username wolfspyre and https://xx.xx.100.2/xmlrpc.php parse error. not well formed

however, I'm not really sure how to begin diagnosing this... backup of the primary config, and restore to to the primary host works, which presumably conveys that the config is okay.


running the /usr/local/etc/rc.filter_synchronize command manually on the primary

Code: [Select]

[root@evey /usr/local/etc]# /usr/local/etc/rc.filter_synchronize
send >>>
Host: xxx.xxx.100.2
User-Agent: XML_RPC
Content-Type: text/xml
Content-Length: 117
Authorization: Basic dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
<?xml version="1.0"?>
<methodCall>
<methodName>opnsense.firmware_version</methodName>
<params>
</params></methodCall>received >>>

Deprecated: Creation of dynamic property IXR_Message::$currentTag is deprecated in /usr/local/opnsense/contrib/IXR/IXR_Library.php on line 239

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/opnsense/contrib/IXR/IXR_Library.php:239) in /usr/local/opnsense/contrib/IXR/IXR_Library.php on line 464

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/opnsense/contrib/IXR/IXR_Library.php:239) in /usr/local/opnsense/contrib/IXR/IXR_Library.php on line 465

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/opnsense/contrib/IXR/IXR_Library.php:239) in /usr/local/opnsense/contrib/IXR/IXR_Library.php on line 466

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/opnsense/contrib/IXR/IXR_Library.php:239) in /usr/local/opnsense/contrib/IXR/IXR_Library.php on line 467
<?xml version="1.0"?>
<methodResponse>
  <params>
    <param>
      <value>
      <struct>
  <member><name>base</name><value><struct>
  <member><name>version</name><value><string>24.1.5</string></value></member>
</struct></value></member>
  <member><name>firmware</name><value><struct>
  <member><name>version</name><value><string>24.7.a_341</string></value></member>
</struct></value></member>
  <member><name>kernel</name><value><struct>
  <member><name>version</name><value><string>24.1.5</string></value></member>
</struct></value></member>
</struct>
      </value>
    </param>
  </params>
</methodResponse>
error >>>
parse error. not well formed

makes it hard to know if the deprecation warnings are contributing to the problem or not.


Suggestions?

[Wolfspyre]

Huh..
I was really kinda hoping that someone here would be able to help...
Or at least to point me in a direction...

am I the only one encountering issues like this?

Code: [Select]

[root@evey /usr/local/etc]# opnsense-version
OPNsense 24.7.a_372
[root@evey /home/wolfspyre]#  /usr/local/etc/rc.filter_synchronize

Deprecated: Creation of dynamic property SimpleXMLRPC_Client::$url is deprecated in /usr/local/etc/inc/XMLRPC_Client.inc on line 92
send >>>
Host: xxx.xxx.100.2
User-Agent: XML_RPC
Content-Type: text/xml
Content-Length: 117
Authorization: Basic dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==
<?xml version="1.0"?>
<methodCall>
<methodName>opnsense.firmware_version</methodName>
<params>
</params></methodCall>received >>>

Deprecated: Creation of dynamic property IXR_Message::$currentTag is deprecated in /usr/local/opnsense/contrib/IXR/IXR_Library.php on line 239

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/opnsense/contrib/IXR/IXR_Library.php:239) in /usr/local/opnsense/contrib/IXR/IXR_Library.php on line 464

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/opnsense/contrib/IXR/IXR_Library.php:239) in /usr/local/opnsense/contrib/IXR/IXR_Library.php on line 465

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/opnsense/contrib/IXR/IXR_Library.php:239) in /usr/local/opnsense/contrib/IXR/IXR_Library.php on line 466

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/opnsense/contrib/IXR/IXR_Library.php:239) in /usr/local/opnsense/contrib/IXR/IXR_Library.php on line 467
<?xml version="1.0"?>
<methodResponse>
  <params>
    <param>
      <value>
      <struct>
  <member><name>base</name><value><struct>
  <member><name>version</name><value><string>24.1.5</string></value></member>
</struct></value></member>
  <member><name>firmware</name><value><struct>
  <member><name>version</name><value><string>24.7.a_372</string></value></member>
</struct></value></member>
  <member><name>kernel</name><value><struct>
  <member><name>version</name><value><string>24.1.5</string></value></member>
</struct></value></member>
</struct>
      </value>
    </param>
  </params>
</methodResponse>
error >>>

is this a known issue that I somehow just failed to read up on?

am I jus doin-it-wrong?

Would love a nudge in the right direction if someone has some pointers.

[Patrick M. Hausen]

Try running supported release like 24.1.6 instead of a development version.
Check the firewall rules on the HA sync interface on the secondary node.
Use tcpdump to perform a packet trace on the HA sync interface.
The primary node must be able to login to the UI over the HA interface - did you change the interfaces setting for the UI?

[Wolfspyre]

hai Patrick!
yea.
No changes to the firewall rules have occurred. hence the confusion. the sync between primary/secondary has been working fine for years.

carp is still working
ssh between the two works properly.
creds haven't changed

dev version has **USUALLY** been pretty stable.
that being said; switching the standby to from dev to 'production'  got things back to synchronizing.


Thanks a bunch for the tip (altho 24.1.5 is the latest my standby sees...  rebooting now to see if that changes anything... )

where are you seeing 24.1.6?

[Patrick M. Hausen]

On all of my firewalls? Released last Thursday.

https://forum.opnsense.org/index.php?topic=40049.0

[Wolfspyre]

[[solved]]

SO... setting the deployment type to 'production' as opposed to 'development' resolved the problem.

my guess is that right now, something in the php deprecation emissions causes the ha sync process to fail...

I'd think that this aughtn't happen... but we don't live in a perfect world...

so yeah. if you're running an HA pair, and you're running into problems, try switching the deployment type
( found in system -> settings -> administration -> deployment ((towards the bottom)) )
back to production and see if it resolves your issue