Topics

[An error occurred while attempting XMLRPC sync with username test and https://192.168.x.x/xmlrpc.php parse error. not well formed]

Hello,

I'm testing the update 20.7.7(_1) on a two node OPNsense HA-Cluster and everytime I want to sync the config from Master to Backup I get the following error: "An error occurred while attempting XMLRPC sync with username test and https://192.168.x.x/xmlrpc.php parse error. not well formed"
The changes I made on the Master node didn't affect the GUI of the Backup Node (for example: new alias, new firewall rule,...) but after a checksum test of the config.xml (md5 /usr/local/etc/config.xml) and ipsec config file (md5 /usr/local/etc/ipsec.conf) on both nodes the checksums were equal as they should be.

Am I checking the wrong files or is there a problem with applying the config to the GUI?

PS: Except for updating the nodes I didn't change anything in the configuration of "High Availability".

Greetz,
bitmusician

Hi,

since updating from 20.1.9 to 20.7 the hardware acceleration isn't working properly. The time it takes to do the encryption has increased a lot (like if there's no hardware acceleration enabled). I've tested this on different hardware and tried it before updating, where it was working like expected.

Before updating the output of "openssl speed -evp aes-256-cbc" was:

Code Select Expand

Doing aes-256-cbc for 3s on 16 size blocks: 342721 aes-256-cbc's in 0.38s
Doing aes-256-cbc for 3s on 64 size blocks: 600792 aes-256-cbc's in 0.38s
Doing aes-256-cbc for 3s on 256 size blocks: 315407 aes-256-cbc's in 0.41s
Doing aes-256-cbc for 3s on 1024 size blocks: 257082 aes-256-cbc's in 0.27s
Doing aes-256-cbc for 3s on 8192 size blocks: 104498 aes-256-cbc's in 0.08s
OpenSSL 1.0.2o-freebsd  27 Mar 2018
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      14324.34k   100442.61k   198754.93k   991066.23k 10957409.48k


After updating it's:

Code Select Expand

Doing aes-256-cbc for 3s on 16 size blocks: 55925433 aes-256-cbc's in 3.06s
Doing aes-256-cbc for 3s on 64 size blocks: 22414986 aes-256-cbc's in 3.02s
Doing aes-256-cbc for 3s on 256 size blocks: 5712456 aes-256-cbc's in 3.05s
Doing aes-256-cbc for 3s on 1024 size blocks: 1069014 aes-256-cbc's in 3.01s
Doing aes-256-cbc for 3s on 8192 size blocks: 183532 aes-256-cbc's in 3.05s
Doing aes-256-cbc for 3s on 16384 size blocks: 62895 aes-256-cbc's in 3.00s
OpenSSL 1.1.1d-freebsd  10 Sep 2019
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc     292181.85k   475708.72k   479963.48k   363942.35k   492192.46k   343490.56k


greetz,
bitmusician

Hi,

since the firmware update from version 20.1.2 to 20.1.3 we are experiencing some issues with our policy based routing. We have one Firewall rule with a configured specific gateway group and since I updated the firewall the traffic is sent over the default route and not the gateway group in the firewall rule. We also tested it with a single Gateway in the firewall rule but it didn't work out, so we had to configure a route for this traffic over one of the specific gateways.

Does anybody have a solution for this problem?

Greetz,
bitmusician :)

Hello,

what I'm writing now is not only an issue in version 20.1 but it got "worse" with the update.

Every time we change the IPsec tunnel configuration over the WebGUI, the configuration change is only written in the /conf/conf.xml on the Backup-Host but not in the /usr/local/etc/ipsec.conf. On the WebGUI of the Backup host it looks like the changes have been made but after comparing the files of both Master and Backup with the command "md5 /usr/local/etc/ipsec.conf" you can see that the changes didn't affect on the Backup Host.

So before 20.1 we had to make some kind of "dummy-change" on the Backup-Host that means to simply open one of the tunnel configurations, save and apply again. This was the solution until now because now you have to additionally perform a HA-Sync BEFORE the dummy-change.

Is there any planned change about this in further versions? I mean it's ok when you know what to do but it would be great if a normal HA-Sync would synchronize the IPsec configuration too!  ;D

Thanks,
Bitmusician

Hi,
as we updated and tested the functionality of our test cluster from version 19.1.6 to 19.1.8 and after that our productive cluster from 19.1.4 to 19.1.8, we noticed that there is a little problem with switching the CARP roles. After we finished updating both nodes in each cluster we wanted to know, if the role switching behavior works as before (when MASTER is set into maintenance mode he becomes BACKUP). So node 1 (MASTER) went into maintenance mode but unfortunately stayed Master for this Cluster. Deactivating CARP on this node and activating it again didn't make it work. The only thing that helped us having a normal switching behavior again when one of the nodes is set into maintenance mode was changing the skew of the advertising frequency of one VIP on the MASTER node from 0 to 1 and then back from 1 to 0 again.

Maybe this workaround helps somebody with the same problem.

Greeetz,
bitmusician