Incoming traffic blocked after upgrade from 17.7.12_1 to 18.1 and then to 19.7.2

[farsoft]

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.

[AdSchellevis]

The rules where there before, but not visible for the end-user.
You can also use the inspect button (top right corner) now to see which rules actually are triggered.

Is this a multiwan setup by the way? and when did the issue start (which version)? 

[farsoft]

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.

[farsoft]

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.

[tong2x]

The rules where there before, but not visible for the end-user.
You can also use the inspect button (top right corner) now to see which rules actually are triggered.

Is this a multiwan setup by the way? and when did the issue start (which version)?

mine is dev build 75, was ok on build 44
mine is on a multiwan, but forcing the default or specific wan does not help either
almost same, outgoing seems ok but internal transfer/access seems to be blocked

[farsoft]

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.

[tong2x]

@farsoft
I have upgraded to 19.7.3
had a minor issue with may WAN2, not having internet for local lan
(but sure wan is OK, at least the actual modem hardware)

since it seems that the default route, which is wan1 is ok...
I remove the wan group, removed the wan2 interface.
then reinstalled wan2 interface..
viola, the routing seems to have corrected it self...

iguess somethings gets mixed up when upgrading