Messages

Hi there,
I run a opnsense 2700 series FW, running version 25.1.9_2 and just enabled suricata / IPS.

I am not using any of the plugins relating to IDS/IPS, but the 'normal' downloadable rulesets (Administration / Download section).

The Policy / Rule adjustments section has some set of regression I think, because The Msg and Source columns are empty which makes identifying a previous adjustment virtually impossible...

Can someone test that on their setup and verify if this is a bug? Or if someone runs a different version we might pinpoint when this regression happened?

Thanks!

I suppose I should have tried that before posting, but: Using "Reset Log Files" solved the issue and everything works now on both FWs.
:)

Hi all,

After upgrading to OPNsense 24.7.8, zfs complains about not all features being enabled.
After running

Code Select Expand

zpool upgrade zroot
the system advises to update the boot code as well.
However, running

Code Select Expand

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 nda0
results in: gpart: /dev/nda0p2: not enough space
Since the system boots via UEFI (I think), this may be irrelevant, but why did the installer partition the disk like this:

Code Select Expand

gpart show
=>        3  500118181  nda0  GPT  (238G)
          3     532480     1  efi  (260M)
     532483        311     2  freebsd-boot  (156K)
     532794  482344960     3  freebsd-zfs  (230G)
  482877754   17240430     4  freebsd-swap  (8.2G)


156K looks like deliberately setting the size to exactly what was needed at the time without any kind of reserve for future changes?

Hi all,

I have recently upgraded my two OPNsense firewalls to 24.7 (running 24.7.8 to be precise).
On one the firewall dashboard widget works perfectly.
On the other (*very* busy FW - there are loads of logs available), the widget will endlessly display 'Waiting for data...'

I tried to compare the settings and everything seems identical on the two setups except the one where the widget works is a 'normal' setup while the one where the widget does not work is a 'transparent filtering bridge' type setup.

Also noteworthy: All other visualizations concerning FW-related stuff like Insight or the Firewall:Log Files:Overview work perfectly on both systems.

Any ideas what I may be missing / how to get this to work?

Thanks,
Martin

dev.igb.0.eee_disabled = 1
dev.igb.1.eee_disabled = 1
dev.igb.2.eee_disabled = 1
dev.igb.3.eee_disabled = 1

After my upgrade to 23.1 these tunables are shown as unsupported

In case anyone else stumbles across this...
The driver tunable used to be (assuming igb0 interface):

Code Select Expand

dev.igb.0.eee_disabled
You now have to use:

Code Select Expand

dev.igb.0.eee_control

Hi all,
I just noticed that the default settings for tunables do not seem to match:

net.inet.ip.redirect = 0

but

net.inet6.ip6.redirect = 1


Is there a reason for disabling redirects for ipv4 but not ipv6? Or are the tunables similar only in name but not function (which would be bad, too, I guess.)

Thanks,

Martin

The current code:

Code Select Expand

tcpflags ack

Ad suggested:

Code Select Expand

tcpflags ack,!psh
which I think would be an improvement.

My suggestion would be to try and narrow it down to packets doing nothing but ack by excluding larger payloads. E.g.:

Code Select Expand

tcpflags ack iplen 52

Shall I open an issue for this?

[should]

Very OT:

There is this one (weirder than average) episode of X-Files where Mulder meets a genie and actually has three wishes.
His first one is: peace on earth
after which he is the only living human being left on the planet.
So, yes. You should be specific when you ask for something. ;-)

Thanks to both of you for your replies.

@franco I agree that there is currently no discrepancy w/r to the documentation or the behavior. My point was that the functionality as it is defined right now is not particularily useful.

@AdSchellevis I guess my hope would be that eventually the shaper rule editor will allow for a more complete subset of the choices that the FW rule editor offers.
That would not only be true for tcp flags, but also specifying the type of icmp packet instead of picking them all, etc.

But certainly, all of this is just 'nice to have'.

Martin

Hi there,

I noticed something weird when trying to prioritize ACK packages.
Selecting "tcp (ACK packets only)" in the proto drop-down results in almost all tcp traffic being matched.
Doing something similar in m0n0wall or even the firewall solution that shall not be named, did not result in comparable behavior.
Though, with those solutions I could (and did) specify the packet size to something very small so only empty ACKs where prioritized. That does not seem to be an option in the OPNsense shaper currently?

If "tcp (ACK packets only)" matches any packet having the ACK flag set, then that is not (to me at least) particularly useful...

That's what I had attempted. The problem is, adding ng_bridge on boot is not sufficient (though that would have seemed like the obvious thing).
I have not yet made out what other module is needed. :-(

Franco, let's forget about the unsure stuff for a moment (For the unsure stuff I will have to reinstall 19.7 on some box and test it.).
What I am certain about:

Say you create a bridge, add ports and assign the bridge as an interface e.g. OPT1.
And then enable flowd for OPT1.

Pre 20.x it would record traffic out of the box. With 20.x it does not.

This is definitely due to the modules mentioned and is what I can get back working when adding the modules back in.
The previous post explained how I was so far unable to narrow it down to which specific modules are responsible.

Thanks, Ad.

I have tried to find out what the missing modules might be, but so far, no luck.

If I do not touch modules, I end up with the graph as shown in the attached vanilla.png
and the output of

Code Select Expand

ngctl types is:

Code Select Expand


There are 10 total types:
      Type name   Number of living nodes
      ---------   ----------------------
        ksocket       1
        netflow       1
         tcpmss       1
          pppoe       1
          ether      10
            tee       1
            ppp       1
          iface       1
           mppc       0
         socket       6


If I put all these (https://github.com/opnsense/core/blob/stable/19.7/src/etc/rc.loader.d/20-netgraph) into /boot/loader.conf.local, I end up with the graph as shown in the attached modules.png and this output

Code Select Expand


There are 31 total types:
      Type name   Number of living nodes
      ---------   ----------------------
        netflow       4
         socket       6
           vlan       0
            vjc       0
            tty       0
            tee       1
         tcpmss       1
          ether      13
         eiface       0
        rfc1490       0
          pred1       0
           echo       0
        pptpgre       0
          pppoe       1
        deflate       0
            ppp       1
          async       0
           pipe       0
          cisco       0
       one2many       0
           mppc       0
            car       0
         bridge       0
            lmi       0
           l2tp       0
        ksocket       4
            bpf       0
          iface       1
             UI       0
           hole       0
    frame_relay       0


I assumed I would see which types are missing by listing the used node types, but apparently, that is not true (or there might be ng_xyz modules that are not node types themselves, but add functionality to existing types?).

Also note that, apparently, I have to reboot after adding modules. Using

Code Select Expand

kldload ng_xyz to load each of the modules mentioned in https://github.com/opnsense/core/blob/stable/19.7/src/etc/rc.loader.d/20-netgraph without a reboot and then doing

Code Select Expand

/usr/local/etc/rc.d/netflow restart, I do not get the same results.

How would I go about narrowing this down without doing trial and error and module by module and having to reboot? Is there another service that needs restarting or is a reboot really necessary?

Giving this a bump as it is still the same behavior in OPNsense 20.1.2.

I can get some of the interfaces to log netflow data by loading kernel modules that are no longer loaded automatically since 20.1.x.

But I have not been able to get my pppoe or openvpn WAN ports to log egress traffic. (I have to admin though, that I do not know for certain these two ever did).

At any rate, manually adding kernel modules to be loaded on boot in order to get built-in features (Netflow) to work seems like a band-aid to me. :-) Are there plans to overhaul the reporting section?

Thanks, franco

Putting the content of this file https://github.com/opnsense/core/blob/stable/19.7/src/etc/rc.loader.d/20-netgraph
into /boot/loader.conf.local brought some improvement:

Code Select Expand


root@gw01:~ # /usr/local/etc/rc.d/netflow restart
setup bridge1
setup bridge0
setup bridge2
setup ovpnc1 [egress only]
ngctl: send msg: No such file or directory
error ovpnc1: cannot create netflow node for ovpnc1
setup pppoe0 [egress only]
ngctl: send msg: No such file or directory
error pppoe0: cannot create netflow node for pppoe0


So, some of the necessary modules are now loaded that weren't before.
At least, Reporting ->Netflow -> Cache now lists the bridges and their counters.

Obviously, however, my egress interfaces still don't collect data.