1
20.7 Production Series / Re: Error in menusystem.php after upgrade to 20.7
« on: August 05, 2020, 09:21:45 am »Code: [Select]
opnsense-patch 6434329
should fix your issue (https://github.com/opnsense/core/issues/4243).
Best regards,
Ad
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
should fix your issue (https://github.com/opnsense/core/issues/4243).
Best regards,
Ad
2
20.7 Production Series / Re: Cannot 'stop' flowd_aggregate -- Delays boot/reboot significantly
« on: August 05, 2020, 09:19:18 am »
Netflow is likely not your problem, if flowd_aggregate_enable is set to "NO" it wasn't started in the first place.
You can easily check if the aggregator has an issue by checking the local process list "ps fax | grep flowd_aggregate" on a console.
I expect our rc.d cleanup doesn't check if the service is actually used, which means it would tell it can't stop it when not configured, usually not something to worry about.
Best regards,
Ad
You can easily check if the aggregator has an issue by checking the local process list "ps fax | grep flowd_aggregate" on a console.
I expect our rc.d cleanup doesn't check if the service is actually used, which means it would tell it can't stop it when not configured, usually not something to worry about.
Best regards,
Ad
4
20.1 Legacy Series / Re: [BUG] inc/filter.inc: check for 'kill_states' / state flush on ruleset update
« on: July 15, 2020, 08:59:32 am »
The old ui page seems to depend on isset() indeed, but writes an actual value when set:
https://github.com/opnsense/core/blob/f3b5c0e8f7d28acd921940d8d11e4185e13043a7/src/www/system_advanced_firewall.php#L54
https://github.com/opnsense/core/blob/f3b5c0e8f7d28acd921940d8d11e4185e13043a7/src/www/system_advanced_firewall.php#L205-L209
We shouldn't try to fix the consumers in this case, since we use the same construction on multiple places , but changing the default config and changing the initial isset() is fine by me.
If you open a PR on GitHub we'll take a look. Since it's only an initial config issue (if advanced settings have never been written, the impact should be relatively low).
https://github.com/opnsense/core/blob/f3b5c0e8f7d28acd921940d8d11e4185e13043a7/src/www/system_advanced_firewall.php#L54
https://github.com/opnsense/core/blob/f3b5c0e8f7d28acd921940d8d11e4185e13043a7/src/www/system_advanced_firewall.php#L205-L209
We shouldn't try to fix the consumers in this case, since we use the same construction on multiple places , but changing the default config and changing the initial isset() is fine by me.
If you open a PR on GitHub we'll take a look. Since it's only an initial config issue (if advanced settings have never been written, the impact should be relatively low).
5
20.1 Legacy Series / Re: [BUG] inc/filter.inc: check for 'kill_states' / state flush on ruleset update
« on: July 14, 2020, 08:47:01 pm »
Hi Matthias,
I think your misreading the code here, filter_delete_states_for_down_gateways() is only called when kill_states is empty (either not set, non existing or 0).
https://github.com/opnsense/core/blob/86c40469dbd0641608e26f395259ba87c385d68c/src/etc/inc/filter.inc#L566-L568
The $any_gateway_down variable is true when there is at least one gateway that is marked down, but only evaluated when kill_states is empty (since not being called).
This will evaluate as being true in php when not set, 0 or non existing.
An example (just copy it in a .php file and execute):
The help text could probably be more descriptive, such as:
The slow gui issue can indeed be caused by reset states, certainly on unstable networks triggering filter reloads quite often due to all sorts of other technical issues.
I don't think it should be moved, but probably should be made conditional if $flush_states is allowed, since it doesn't take that into account it will also reset when no explicit flush is requested. In which case the configd call might need a parameter to pass the option as well (haven't look into it, but sounds logical)
Best regards,
Ad
I think your misreading the code here, filter_delete_states_for_down_gateways() is only called when kill_states is empty (either not set, non existing or 0).
https://github.com/opnsense/core/blob/86c40469dbd0641608e26f395259ba87c385d68c/src/etc/inc/filter.inc#L566-L568
The $any_gateway_down variable is true when there is at least one gateway that is marked down, but only evaluated when kill_states is empty (since not being called).
This will evaluate as being true in php when not set, 0 or non existing.
Code: [Select]
if (empty($config['system']['kill_states'])) {
An example (just copy it in a .php file and execute):
Code: [Select]
$tmp = ['xx' => [] ];
if (empty($tmp['xx']['non_existing'])){
echo "yeay, empty\n";
}
The help text could probably be more descriptive, such as:
Quote
Help text: The monitoring process will flush states
when a gateway goes down if this box is not
checked. Check this box to disable this behavior.
The slow gui issue can indeed be caused by reset states, certainly on unstable networks triggering filter reloads quite often due to all sorts of other technical issues.
Quote
I think lines 561-563 should be removed from
/usr/local/etc/inc/filter.inc, and be moved to
/usr/local/etc/rc.syshook.d/monitor/10-dpinger instead.
I don't think it should be moved, but probably should be made conditional if $flush_states is allowed, since it doesn't take that into account it will also reset when no explicit flush is requested. In which case the configd call might need a parameter to pass the option as well (haven't look into it, but sounds logical)
Best regards,
Ad
6
20.1 Legacy Series / Re: vIP wont sync on DEC4640
« on: June 29, 2020, 09:18:59 pm »
I don't know why not to be honest, carp addresses are just like others.
7
20.1 Legacy Series / Re: vIP wont sync on DEC4640
« on: June 29, 2020, 08:50:17 pm »
you can't sync aliases, since it would lead to IP conflicts (aliases are active addresses, carp ip's only when promoted as such).
Best regards,
Ad
Best regards,
Ad
8
20.1 Legacy Series / Re: default deny errors?
« on: June 27, 2020, 09:16:16 pm »
When capturing traffic in these case you will often see tcp retransmissions and/or excessive resets , pointing to other issues in your network (like mtu sizing issues).
From the firewalls perspective it's indeed as simple as Franco commented, if the return packet has no matching state, it will be dropped, in all cases I've witnessed so far, it did so for very valid reasons (broken switches, devices ignoring pmtu, network congestion, etc, etc).
When you need to find out the reasons, you have to start digging into the details by capturing traffic (and compare the results with how the tcp flow should react). This, unfortunately, can be time consuming.
Best regards,
Ad
From the firewalls perspective it's indeed as simple as Franco commented, if the return packet has no matching state, it will be dropped, in all cases I've witnessed so far, it did so for very valid reasons (broken switches, devices ignoring pmtu, network congestion, etc, etc).
When you need to find out the reasons, you have to start digging into the details by capturing traffic (and compare the results with how the tcp flow should react). This, unfortunately, can be time consuming.
Best regards,
Ad
9
20.1 Legacy Series / Re: pfsense vs opnsense vs manjaro linux
« on: June 24, 2020, 08:48:56 pm »
I think our release track record speaks for itself https://docs.opnsense.org/releases.html (181 releases since Januari 2015), and yes, proper release management is a lot of work if you don't want to risk breakage of existing setups.
Usually we assess if security issues warrant an intermediate release of our software or if it's possible to postpone until a more sensible release can be packaged (including other bug fixes and enhancements).
If for some reason you do require the latest (and greatest) version of a package, FreeBSD/HardenedBSD offers the ports tree to build the package yourself (our mirror can be found here : https://github.com/opnsense/ports).
Suricata 4 is a release version and isn't end of life (https://suricata-ids.org/about/eol-policy/), our development version ships 5 (as of Januari if I'm not mistaken).
It's ok to be a concerned citizen, but try not to mix feature enhancements (FreeBSD 12, suricata 5, ..) with security issues and one-shots (system X has fix Y earlier this time) with overal performance, it's not very realistic.
Best regards,
Ad
Usually we assess if security issues warrant an intermediate release of our software or if it's possible to postpone until a more sensible release can be packaged (including other bug fixes and enhancements).
If for some reason you do require the latest (and greatest) version of a package, FreeBSD/HardenedBSD offers the ports tree to build the package yourself (our mirror can be found here : https://github.com/opnsense/ports).
Suricata 4 is a release version and isn't end of life (https://suricata-ids.org/about/eol-policy/), our development version ships 5 (as of Januari if I'm not mistaken).
It's ok to be a concerned citizen, but try not to mix feature enhancements (FreeBSD 12, suricata 5, ..) with security issues and one-shots (system X has fix Y earlier this time) with overal performance, it's not very realistic.
Best regards,
Ad
10
20.1 Legacy Series / Re: Carp performance way too slow
« on: June 05, 2020, 09:48:28 am »
I would start looking at events in the logging, if there are no (notable) events, a packet capture helps to retrieve more insights as well.
If carp traffic isn't properly delivered to the machines, in most of the cases there are some pointers in the system log, such as flipping master/slave state or mac address issues.
Best regards,
Ad
If carp traffic isn't properly delivered to the machines, in most of the cases there are some pointers in the system log, such as flipping master/slave state or mac address issues.
Best regards,
Ad
11
Intrusion Detection and Prevention / Re: How to configure Spamhaus ASN-DROP ?
« on: June 04, 2020, 11:31:03 am »
ASN lists are not supported, you need to map them to ip ranges first and publish the list. OPNsense (currently) does not resolve ASN entries, in case of the Spamhaus list I don't expect many of those entries will resolve to anything at the moment ( e.g. https://mxtoolbox.com/SuperTool.aspx?action=asn:AS612&newAppVersion=1).
Although I'm not very familiar with these specific lists, I expect their intended usage seems more related to dynamic routing / BGP to deny access to publish new routes.
Best regards,
Ad
Although I'm not very familiar with these specific lists, I expect their intended usage seems more related to dynamic routing / BGP to deny access to publish new routes.
Best regards,
Ad
12
20.1 Legacy Series / Re: dpinger failing to detect up connection
« on: June 02, 2020, 08:47:27 am »
yes, we're using https://github.com/dennypage/dpinger (see https://github.com/opnsense/ports/blob/master/net/dpinger/Makefile).
Unfortunately I can't really help you with your question, although it sounds a bit odd if it doesn't recover from a disconnected network, if the address is lost, usually a reconnect will automatically signal dpinger with a monitoring event. (https://github.com/opnsense/core/blob/6529ef77efaefb9723d2b20c1c8b1ba839687625/src/etc/rc.newwanip#L155)
Best regards,
Ad
Unfortunately I can't really help you with your question, although it sounds a bit odd if it doesn't recover from a disconnected network, if the address is lost, usually a reconnect will automatically signal dpinger with a monitoring event. (https://github.com/opnsense/core/blob/6529ef77efaefb9723d2b20c1c8b1ba839687625/src/etc/rc.newwanip#L155)
Best regards,
Ad
13
General Discussion / Re: what exactly is "This Firewall" as a destination?
« on: May 31, 2020, 06:33:10 pm »
To be honest, quite often I just drop icmp in these situations too, although icmp packets are also used to send network status updates (such as the ones for PMTUD).
If everything works as expected, I probably wouldn't be too worried, if you experience transfer issues (with larger packets), you might want to consider allowing at least some icmp traffic.
If everything works as expected, I probably wouldn't be too worried, if you experience transfer issues (with larger packets), you might want to consider allowing at least some icmp traffic.
14
General Discussion / Re: what exactly is "This Firewall" as a destination?
« on: May 31, 2020, 04:00:16 pm »
as well as other other addresses assigned to this machines other interfaces (WAN address for example).
15
General Discussion / Re: what exactly is "This Firewall" as a destination?
« on: May 31, 2020, 11:31:55 am »
It shouldn't be either. "This firewall" translates to "self" for pf, as explained in "man pf.conf" it resolves to
I don't think we have a topic yet about these special nets in our docs.
Quote
...or the self keyword, in which
case all addresses assigned to the interface(s) will be added to the
table.
I don't think we have a topic yet about these special nets in our docs.