Messages

Hi all,

I've been following this thread since its beginning since I have IPv6 intermittent issues. My ISP is Xfinity. I have Monit email me when its ping6 test fails. For the most part it's stable. That is, for a given boot of my router, IPv6 will either work till the next boot or not work at all.

Whether it works or not, I have the same details when I run "ifctl -O -i igc1". Even when it's not working, I can still ping6 the Xfinity gateway (a link-local address). I cannot ping6 to any host I've tried on the internet; I can't even ping the Xfinity name server.

My conclusion has been that it's an Xfinity issue. Maybe when they receive my DHCP request they do some setup and there's some variability in that. My single call to Xfinity support was not helpful; the support person didn't know anything about the topic and refused to escalate my issue.

I'm just adding those details in case it sheds any light, even though my problem seems different.

What happens when one restarts routing from the dashboard? Is it a combination of commands from action_interface.conf? Does that make a new DHCP request to my ISP? I'm trying to figure out the most light-weight action that could trigger Xfinity to perform its setup again.

OK. I think I misunderstood your request for the cli format. I thought you wanted to understand the syntax for pfctl. I'd be very interested to learn if OPNsense provides an API for modifying, inserting, or deleting rules.

I see this might not be your desire, but if you were to use pfctl yourself and regarding loading the main ruleset on a running system, consider this excerpt from an article at http://undeadly.org/cgi?action=article&sid=20060929080943...

"""
There's no need to flush rules before loading a new ruleset like

  $ pfctl -Fr -Fn -f /etc/pf.conf

In fact, this not only wastes CPU cycles, but introduces a (brief) temporary state with no rules loaded, when packets might pass that both the old and the new ruleset would block. A simple invokation with -f is sufficient and safe: while the new ruleset is being uploaded to the kernel, the old ruleset is still in effect. Once the new ruleset is completely uploaded, the kernel switches the rulesets and releases the old set. Any packet, at any time, is either filtered by the entire old ruleset or the entire new ruleset. If the upload fails for any reason, the old ruleset remains intact and in effect.

There are no pfctl commands to add or remove individual rules from a loaded ruleset. However, the output of pfctl -sr is valid input for pfctl -f. For instance, additional rules can be inserted at the beginning or end of the ruleset using:

  $ (echo "pass quick on lo0"; pfctl -sr) | pfctl -f -
  $ (pfctl -sr; echo "block all") | pfctl -f -
"""

Hi there,

PF is document here https://www.openbsd.org/faq/pf/. Making use of that within OPNsense is another story.

I've done some study, but I'm sure many other people know a whole lot more.

OPNsense seems to configure PF in the PHP code found mostly in two places: /usr/local/opnsense/mvc/app/library/OPNsense/Firewall/Plugin.php and /usr/local/etc/inc/filter.inc. It seems to do it based on the contents of /conf/config.xml. I have no idea how one would hook into that machinery. There is a suggestion in the code that some anchors are configurable; Plugin#anchorToText is called when the code builds the final rules. However, I've been unable to find any code calling Plugin#registerAnchor, which would have set something up for the anchorToText call. You can read the PF reference to learn how anchors could have helped you had they existed in strategic places.

The code does leave all the rules that are generated in the file /tmp/rules.debug. The lines in that file are in the syntax that PF expects. After the code builds that file, it runs "pfctl -f /tmp/rules.debug". You could craft your own file, xyz, and put a script in /usr/local/etc/rc.syshook.d/start, which would run after the firewall is setup and replace what it configured by running "pfctl -f xyz". But that seems pretty dangerous except for someone who is extremely knowledgable.

Then again, I could be completely wrong about everything. :) I've been watching this thread since you started it, hoping someone who actually knows something chimes in. I hope my post is not a complete waste of your time.

Regards,
Barold

Well, it appears to have been a IPv6 problem with my ISP. Sorry for the noise.

I have two installations. At the start of the upgrade process I receive the output

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 24.1.1 at Wed Feb 21 20:21:18 UTC 2024
Fetching changelog information, please wait... fetch: transfer timed out
fetch: /usr/local/opnsense/changelog/changelog.txz appears to be truncated: 0/128592 bytes

That seems to prevent the web ui from applying the update. It might be transient since a reboot and retry managed to avoid this problem for one of my installations. I've not managed to get it to work on the other.

On the firewall that has the update successfully applied, all System/Firmware tabs are very slow to render. For example, the changelog list stays empty for quite a while. I suspect the same truncated file is causing this and some process is stuck on that until it times out.

The firewall that did update on the second attempt is working in all other ways that I've checked.

Hello everyone.

I've encountered the fabulous packet flow diagram at https://forum.opnsense.org/index.php?topic=36326.0. (It's so good that it gives me goosebumps.) One thing in the diagram confuses me quite a bit. Whenever that happens I usually learn something new. :)

The diagram depicts that Suricata processes ingress traffic before pf scrubs. How does Suricata manage that before potentially fragmented packets are reassembled?

Thank you for this post; I learned a lot from it.

I'm not sure policies are practical for me. I don't want to speak for others, but I'll raise my issues on the hope it adds some useful information.

Initially I was lulled into a false sense of security when setting up a policy. After studying the details of the implementation, I couldn't figure out a way to use them reliably. This is likely the result of my inexperience.

The biggest problem I have is in specification of "Rules" in the "Rule details" dialog used when setting up a Policy. The choices presented are across every installed ruleset. Choosing a particular ruleset does *not* cause the collection of rule choices to be limited to the metadata of that ruleset. Further, even if the metadata is represented in the chosen ruleset, it doesn't mean that the metadata is consistently applied by the original ruleset. Some examples:

Suppose I set up a policy for the emerging-exploit.rules where you focus on the affected_product=Adobe_Coldfusion. Unfortunately, one of the rules in that ruleset did not include that piece of metadata. The rule sid:2025836, msg:"ET EXPLOIT Adobe Coldfusion BlazeDS Java Object Deserialization Remote Code Execution" does not include the "affected_product" metadata.

Suppose I want to target particular rules in emerging-exploit.rules that have a particular "confidence" ("High", "Medium", or "Low). While many rules in that ruleset specify a confidence, most do not. I might even think to specify confidence, thinking it applied to some ruleset I'm targeting, but that ruleset doesn't use that metadata at all.

At the end of the day, I have to make a careful study of every ruleset before settling on any policy. Generally, policies seem too course-grained for my use, but even if I do manage to settle on one, I have two issues.

1 - When rulesets are updated, things could have changed to make the policies that were set up obsolete. That's my inexperience talking; maybe there are conventions in place to prevent that. But if, say, metadata was subtly modified on new versions of some rules, the policies set up could easily miss their targets. If I really want set "drop" on a rule that had a default of "alert", then the only way I see to do that with confidence that it lasts into the future is to do that with a "Rule Adjustment".

2 - I have not found a convenient way to figure out which rules are affected by policies. When I just had a single policy, I tried to just diff the two folders /usr/local/etc/suricata/rules and /usr/local/etc/suricata/opnsense.rules. I thought to just see which files were modified and review the rule changes. Seemed easy enough. Unfortunately, OPNsense makes subtle modifications to every file (adding spaces in the comments at the top), so every file shows as modified.

This thread is really about policies, so the following comment is off-topic. Rule adjustments only show the sid, they don't show the msg: attribute. That makes it very hard to review the adjustments. Once again, the diff'ing the original rules and generated rules is problematic. However, this is solvable with a little scripting.