Messages

Thanks a lot for Your interest in the topic. We'll observe other services, that are of such properties, that they have lots of request, many clients and a characteristics of burst traffic.

No, I have no influence on configuration on the client's side.
I'm just wondering if there's a change recently in default network stack on some OSes or in CSP or something like that, that causes an impact on TCP session management...
We were forced to migrate some publicly available services from virtual instances of OPNsense to Fortigate clusters, which do not impose a problem.

Hi!
Some time ago we've been noticing the service behind one of our OPNsense's is being shortly and unpredictably inaccessible. Diagnosis showed some of the connections were interrupted and it corelated with growing "state mismatch" pfctl counter.
Since then we're monitoring this parameter on almost all of our FWs. As of now I'm experiencing it for a 4th time, with 4th OPNsense instance, I think there's a patern.
Meaning first we start noticing sporadical counter increase, then zabbix triggers based on it become more frequent, then the service owner starts complaining because his clients start noticing the behaviour.
In 2/4 cases changing "Firewall Optimization" from Normal to Aggressive fixed the problem as for now, for other 2/4 only prolonged the time to experience the problem again.

The change mentioned above has been introduced to our configs, because the first case was really eye opening.
One client was generating lots of HTTP request to the service from his Azure cloud environment, sometimes very frequent, and traffic dump showed TCP source port in those request was circulating in a range of only 10 different numbers, meaning the numbers were reused when old FIN_WAIT sessions were still present in a state tables of our firewalla. Hence same src/dst IP, and src/dst port were used, matching old sessions for new SYN packets - packets were dropped, state mismatch counter grew. That's our conclusion.
In other 3 cases we did not find such explanation for firewall behaviour.

Does that ring a bell to anyone, specially OPNsense developers, why it happens now and why aggresive mode doesn't fix it in a consistent manner?

I did some tests. Although traffic is flowing correctly through the firewall, the problems appear somewhere else. Crash reports are generated, related to some php migration script, users are uneditable, who knows what else

I know how to perform fresh install, maybe I should rephrase my question.
I'm worried that ie. v. 25.1.4 freshly installed system will not fully understand v21.1 configuration file, will skip parts of it (services configs, IPsec configs and so on) and I'd be forced to deal with hidden problems.
If only the tool existed, that could convert or verify the consistency of configuration after old config import.

Hi! I found general rule to perform incremental updates .1, .7, one by one and so on, but...
I got OPNsense instance being quite important to run uninterruptible, but running 21.1 version. I'd like to update it to the latest and greatest version, but with minimal count of reboots. Anyone knows the safest way to do that?
Is there a tool that can verify a configuration against given OPNsense version or maybe a configuration conversion tool?
Maybe someone tried and succeeded with fresh install ISO update, but skipping some versions?

Thx.

Hi!I need to change "Maximum IKEv1 phase 2 exchanges" aka max_ikev1_xchanges, but it's not a value field.
It's a checkbox, which is unchecked even if You check it, apply, open the section again.
Screenshot attached.

What do I miss?

There's definitely an issue after upgrade. I lost all NAT rules. After comparing config files before and after I see that new empty section showd up:

      <Filter version="1.0.3">
        <rules/>
        <snatrules/>
        <npt/>
      </Filter>

In "before" config all rules are int <nat> section and they're present also in "after"one, but are obviously ignored.
After adding 1:1 rule it show under new section mentioned above, but in not visible before, but named the same as in older config: <onetoone>

[does not]

Hi!
Through some testing I came to conclusion, that Routing->OSPF->Networks Tab is useless. I'm not sure if it's OPNsense fault or FRR's.
I have lo3 interface addressed as 100.127.127.127/32. If I have it configured on Networks tab, "sh ip ospf data" shows:

                Router Link States (Area 0.0.0.200)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
[...]
100.127.127.127 100.127.127.127  791 0x80000005 0xe511 3

but "sh ip ospf data router" does not show:

    Link connected to: Stub Network
     (Link ID) Net: 100.127.127.127
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metric: 0

Also, neighboring routers don't have the LSA , they don't receive it at all. The only way to see the stub network LSA is to configure ospf on "Interfaces" tab. If I do this, it does no longer matter if I use the Networks tab, or not.

Has anyone experienced this issue? I haven't use FRR on other operating systems, so I have nothing to compare with.