Messages

Hi tong2x,

Have you got static routes? If you do, are you using aliases for the networks in the routing table? That was the problem for me.

Aliases for networks don't work anymore in routing table (at least in my case).


Regards.

Hi,

In fact, when I lost IP connection with OPNsens after upgrading to 18.1 on Wednesday, my PC was connected to a routed VLAN. Then, I moved next to the appliance and connect to a switch port in the same VLAN as LAN port of OPNSense but I couldn't connect either. Disabling pf allowed me to connect by IP again. However, when I checked again this morning being more calm, I've noticed that the IP from which I was testing in OPNSense LAN VLAN was not authorised, and that's why I could connect after disabling pf.

So I was wrong and filtering was not the problem. Sorry for confusion.

I checked then the routing table and I found that my static routes were missing. Until now, I was using static routing with networks configured by label (see attachment) and that seems not to be working anymore since v18.1. After rewriting my static routes in IP format, everything seems to be working fine.

Regards.

Hi AdSchellevis,

Thank you very much for your answer.

Thank you for explanations about hidden rules. I didn't know. That isn't the problem then.

This is not a multiwan setup. The problem started after upgrading to v18.1.
For your information, the device is part of a HA cluster and in normal conditions it's the master node. Now I have failed over the secondary node which is still in v17.7.12_1.
The affected device is at my office and I'm not there today. I will keep on analyzing tomorrow morning. I'll keep you informed.

Regards.

Hi everybody,

Today I upgraded one of my A10 appliances from 17.7.12_1 to 18.1 version first.
After that I couldn't connect to OPNsense anymore by IP but only by console port.

I noticed that incoming IP traffic was being blocked. Outgoin traffic was OK. I though maybe about some bug so I continued upgrading to the last available version 19.7.2.

Unfortunately, incoming IP traffic is still being blocked. I disabled pf in order to test and then I could connect again by IP and so to GUI. After that, I saw that there are new floating rules that have been automatically generated and that can't be disabled, which seems to explain the issue (you can find a screenshot attached). However, I don't understand why these rules are there as there weren't in 17.7.12_1.

Could you help me, please ?

Thank you in advance.

Regards.

It works!!!  :D :D :D

Thank you very much Ad!

Regards,

farsoft

Hi Ad,

As expected, same behaviour with your new code.

Here is the hasync section of my /conf/config.xml file on master node:

Code Select Expand

<hasync>
    <pfsyncpeerip>172.31.167.86</pfsyncpeerip>
    <pfsyncinterface>lan</pfsyncinterface>
    <synchronizetoip>172.31.167.86</synchronizetoip>
    <username>root</username>
    <password>*******</password>
    <pfsyncenabled>on</pfsyncenabled>
    <synchronizestaticroutes>on</synchronizestaticroutes>
    <synchronizeusers>on</synchronizeusers>
    <synchronizeauthservers>on</synchronizeauthservers>
    <synchronizecerts>on</synchronizecerts>
    <synchronizerules>on</synchronizerules>
    <synchronizeschedules>on</synchronizeschedules>
    <synchronizealiases>on</synchronizealiases>
    <synchronizenat>on</synchronizenat>
    <synchronizeipsec>on</synchronizeipsec>
    <synchronizeopenvpn>on</synchronizeopenvpn>
    <synchronizedhcpd>on</synchronizedhcpd>
    <synchronizewol>on</synchronizewol>
    <synchronizelb>on</synchronizelb>
    <synchronizevirtualip>on</synchronizevirtualip>
    <synchronizednsforwarder>on</synchronizednsforwarder>
    <synchronizednsresolver>on</synchronizednsresolver>
    <synchronizeshaper>on</synchronizeshaper>
    <synchronizecaptiveportal>on</synchronizecaptiveportal>
  </hasync>


Hi Ad,

Yes, I'm sure sync doesn't happen on apply.

I think the problem is related to the check for the existence of synchronizetoip.

It seems that the check is KO an then, configd_run('filter sync restart') is never called.

I've commented the test as below and tried again.

Code Select Expand

if (!file_exists("/var/run/booting")) {
        configd_run('filter reload');
        // if ( isset($config['hasync']['synchronizetoip']) && trim($config['hasync']['synchronizetoip']) != "") {
            configd_run('filter sync restart');
        // }
    }

It has worked.

Log on backup:

Code Select Expand

Sep  8 13:07:23 LYFWINT2 configd.py: [2245481d-db51-4985-8f22-0bb1bb0842c2] Reloading filter
Sep  8 13:07:24 LYFWINT2 opnsense: /usr/local/etc/rc.filter_configure_sync: Could not find IPv6 gateway for interface(wan).
Sep  8 13:07:24 LYFWINT2 opnsense: /xmlrpc.php: ROUTING: setting IPv4 default route to 10.0.0.138
Sep  8 13:07:24 LYFWINT2 opnsense: /xmlrpc.php: Removing static route for monitor 8.8.8.8


However, synchronizetoip is set up on the master (see attached screenshot).

Best regards,

farsoft

Hi Ad,

Your command seems to work.

On the master:

Code Select Expand

root@LYFWINT1:~ # configctl filter sync restart
OK


On the backup:

Code Select Expand

Sep  8 11:07:32 LYFWINT2 configd.py: [622cb9cd-6ae7-45ac-9eb9-82dedefb64d2] Reloading filter
Sep  8 11:07:32 LYFWINT2 opnsense: /usr/local/etc/rc.filter_configure_sync: Could not find IPv6 gateway for interface(wan).
Sep  8 11:07:33 LYFWINT2 opnsense: /xmlrpc.php: ROUTING: setting IPv4 default route to 10.0.0.138
Sep  8 11:07:33 LYFWINT2 opnsense: /xmlrpc.php: Removing static route for monitor 8.8.8.8


Regards,

farsoft

Hi Ad,

Thank you for your answer.

No, there is nothing on the system log of the backup when I apply on the master.

However, I've tcpdumped on backup and I can see the XMLRCP queries when I apply on the master but changes are still not applied on the backup.

I've switched the GUIs from https to http to be able to see the content of the queries and then I've done a "Force config sync" on the master.

Here is an exctract from the POST query received on the backup:

Code Select Expand

POST /xmlrpc.php HTTP/1.0
Connection: close
Host: 172.31.167.86
User-Agent: XML_RPC
Content-Type: text/xml
Content-Length: 64748
Authorization: Basic cm9vdDpFeDQ5QGhvbWU=

<?xml version="1.0"?>
<methodCall>
<methodName>opnsense.restore_config_section</methodName>
<params>
<param><value><struct>
  <member><name>filter</name><value><struct>
  <member><name>rule</name><value><array><data>
  <value><struct>
  <member><name>type</name><value><string>block</string></value></member>
  <member><name>interface</name><value><string>wan</string></value></member>
  <member><name>ipprotocol</name><value><string>inet46</string></value></member>
  <member><name>statetype</name><value><string>keep state</string></value></member>
  <member><name>descr</name><value><string>Block tout</string></value></member>
  <member><name>log</name><value><string>1</string></value></member>
  <member><name>source</name><value><struct>
  <member><name>any</name><value><string>1</string></value></member>
</struct></value></member>
  <member><name>destination</name><value><struct>
  <member><name>any</name><value><string>1</string></value></member>
</struct></value></member>
  <member><name>updated</name><value><struct>
  <member><name>username</name><value><string>root@172.31.163.9</string></value></member>
  <member><name>time</name><value><string>1472546467.8115</string></value></member>
  <member><name>description</name><value><string>/firewall_rules_edit.php made changes</string></value></member>
</struct></value></member>
...


And the answer from the backup:

Code Select Expand

HTTP/1.0 200 OK
Expires: Fri, 09 Sep 2016 22:35:29 GMT
Cache-Control: max-age=180000
Connection: close
Content-Length: 161
Content-type: text/xml;charset=UTF-8
Date: Wed, 07 Sep 2016 22:35:30 +0200
Server: lighttpd/1.4.41

<?xml version="1.0"?>
<methodResponse>
  <params>
    <param>
      <value>
      <boolean>1</boolean>
      </value>
    </param>
  </params>
</methodResponse>


Another information that can help maybe: restarting the services on the backup from status_habackup.php page on the master works fine.

Hi everybody,

I've got a new little problem with my OPNsense A10 HA cluster (OPNsense 16.7.3-amd64).

I've setup XMLRPC Sync between the two nodes. If do a config change in master node (ex.: adding a new route or a new firewall rule), it's visible on the slave node but it's not applied automatically.

For instance, if I add a new route and apply the change on master node, I can see the new route immediately on the GUI of the slave node. However, if I look at routes status, it isn't there. If want to see it, I have to force an update and apply the changes on slave node.

I've found and old topic about a similar problem in an old OPNsense version but it was supposed to be fixed.

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

Have you got any idea, please ?

Thanks in advance.

Regards,

farsoft

Hi again Ad,

I confirm that everything works fine with Intel's original driver.

Thank you very much!

Best regards,

farsoft

Hi Ad,

Thank you very much for your answer.

I will install the original Intel driver tomorrow morning.

I will keep you informed.

Best regards,

farsoft

Hello everybody.

This is my first post.

I've bought two Deciso OPNsense A10 Dual Core SSD appliances in order to set up a HA cluster.

Everything seemed to work correctly but when I've started to do some failover tests, I've noticed that when I shut down the interfaces on the switches side or even if I unplug the network cables from any of the OPNsense interfaces, the status remains "active".

If I disable / enable OPNsense interfaces from the GUI, then the status changes to "no carrier". If I plug the cables, the interfaces go UP but if I unplugged again, the interfaces remain "active".

I've got same behaviour in both appliances.

For instance, now the cable at em0 interface is unplugged but here is the status of the interface:

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
        ether f4:90:ea:10:17:a8
        inet6 fe80::f690:eaff:fe10:17a8%em0 prefixlen 64 scopeid 0x1
        inet 172.31.167.85 netmask 0xffffff00 broadcast 172.31.167.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet 1000baseT (1000baseT <full-duplex>)
        status: active

My OPNsense version is 16.7.3-amd64.

I've searched at the forum and googled also but I haven't found any similar problem.

Have you got any idea, please?

Thank you very much.

Regards.

farsoft