1
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.
2
Hardware and Performance / Re: DEC3862 various ethernet problem
« on: May 10, 2024, 10:43:31 pm »
You can check the chip revision via pciconf -lv, giving something like:
I found the I225-V revision 3 to be fine, reportedly they still have problems with some counterparts. I now have a machine with an I226-V revision 4 which counts media errors , which in my case do not directly cause degradation of the speed, but after a few hours of operation, the link stalls and can only be revived via a port reset.
This is reported also on pfSense forums and here. So it seems that the very chip that Intel created as a stopgap for the problematic I225 is even more problematic itself.
Code: [Select]
igc2@pci0:4:0:0: class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x8086 subdevice=0x0000
vendor = 'Intel Corporation'
device = 'Ethernet Controller I225-V'
class = network
subclass = ethernet
I found the I225-V revision 3 to be fine, reportedly they still have problems with some counterparts. I now have a machine with an I226-V revision 4 which counts media errors , which in my case do not directly cause degradation of the speed, but after a few hours of operation, the link stalls and can only be revived via a port reset.
This is reported also on pfSense forums and here. So it seems that the very chip that Intel created as a stopgap for the problematic I225 is even more problematic itself.
3
Web Proxy Filtering and Caching / Re: Squid 6.9 has been released
« on: May 10, 2024, 09:03:24 am »
Ah, so the disabling of openssl legacy functionality is limited to squid only by using a separate configuration file for it. Clever.
4
Hardware and Performance / Re: Much slower speed on DEC2750 vs Linux VM
« on: May 09, 2024, 06:32:04 pm »
Guessing from your earlier posts, you have traffic shaping enabled. See this.
Also, if you did not enable RSS on OpnSense itself, it may well be that its original speeds are not as much optimized as the through traffic it just routes.
Also, if you did not enable RSS on OpnSense itself, it may well be that its original speeds are not as much optimized as the through traffic it just routes.
5
Web Proxy Filtering and Caching / Re: Squid 6.9 has been released
« on: May 09, 2024, 02:07:44 pm »A workaround is in place in the plugins for os-squid and os-OPNProxy and seems to work.
An interim solution is to edit /usr/local/opnsense/service/templates/OPNsense/Trust/openssl.cnf
Change the following line from
legacy = legacy_sect
To
#legacy = legacy_sect
And execute:
# /usr/local/etc/rc.configure_firmware
A slightly better workaround that will require no user interaction will be shipped in 24.1.7
That workaround seems to have a side-effect: With my OpenVPN config, this disables legacy ciphers, resulting in OpenVPN not starting with: "Error openvpn_server2 Cipher BF-CBC not supported".
I also had a Google drive backup fail with an invalid p12 key, but that I am unsure if it is related.
6
Intrusion Detection and Prevention / Re: Which IDS IPS rules do you prefer
« on: May 09, 2024, 01:10:14 pm »
Yes, this adds a layer. I quote myself:
Just try.
Second order problems will be your problem when you enable IPS and then return here and ask "why does this not work"?
...
You will see that if you search the forum for questions about how suricata blocks legitimate traffic. And every single update may bring new rules along that then block something new - sometimes correctly, sometimes not.
Just try.
7
Intrusion Detection and Prevention / Re: Which IDS IPS rules do you prefer
« on: May 09, 2024, 01:04:02 pm »
What I tried to explain and what you obviously did not get is that the provided IDS/IPS rules from which you can choose have errors of first and second degree.
That means: 1) there may be things they do not catch and 2) there will be false alarms that may cripple your experience because these rules would block legitimate traffic if IPS is enabled.
The first order problems are not of your concern, since if you did not enable IPS at all, these unmitigated attacks would get unnoticed as well. However: do not expect perfect protection from an IPS.
Second order problems will be your problem when you enable IPS and then return here and ask "why does this not work"?
In order to avoid this, you will have to see which false alarms occur in your specific situation, i.e. with the services you actually use. We do not know, so either you invest the time or pay someone to do it for you. There is no "one size fits all" or "automagical" approach here. You will see that if you search the forum for questions about how suricata blocks legitimate traffic. And every single update may bring new rules along that then block something new - sometimes correctly, sometimes not.
If you neither want to invest the time yourself nor pay someone to do it, you are facing the question: "Do I want to risk crippling my internet connection for a mechanism I do not fully understand and which cannot reach 100% efficiency anyway?"
With Crowdsec, you may be getting the most of what you obviously want: You relay your decicions to the crowd, hoping that they have a similar use pattern as you and that the same rules are applicable for you, too. Whether that is true, depends largely on what your or others have in common w/r to the vulnerabled devices in question.
I just limit those devices to a separate VLAN, because then, I do not have to trust them.
That means: 1) there may be things they do not catch and 2) there will be false alarms that may cripple your experience because these rules would block legitimate traffic if IPS is enabled.
The first order problems are not of your concern, since if you did not enable IPS at all, these unmitigated attacks would get unnoticed as well. However: do not expect perfect protection from an IPS.
Second order problems will be your problem when you enable IPS and then return here and ask "why does this not work"?
In order to avoid this, you will have to see which false alarms occur in your specific situation, i.e. with the services you actually use. We do not know, so either you invest the time or pay someone to do it for you. There is no "one size fits all" or "automagical" approach here. You will see that if you search the forum for questions about how suricata blocks legitimate traffic. And every single update may bring new rules along that then block something new - sometimes correctly, sometimes not.
If you neither want to invest the time yourself nor pay someone to do it, you are facing the question: "Do I want to risk crippling my internet connection for a mechanism I do not fully understand and which cannot reach 100% efficiency anyway?"
With Crowdsec, you may be getting the most of what you obviously want: You relay your decicions to the crowd, hoping that they have a similar use pattern as you and that the same rules are applicable for you, too. Whether that is true, depends largely on what your or others have in common w/r to the vulnerabled devices in question.
I just limit those devices to a separate VLAN, because then, I do not have to trust them.
8
Hardware and Performance / Re: J4125/N100 and Wireguard (for 1Gbps ISP line)
« on: May 09, 2024, 11:52:30 am »Your command would upgrade the base FreeBSD to 14 and double the speed of Wireguard traffic, right? I presume it would also reduce CPU load as well?
Yes. As long as you also lock the kernel package in order to keep it over future updates.
And you cannot have your cake and eat it, too. When wireguard speed maxes out because of CPU saturation, the load will be at 100%. So, if efficiency doubles, you will get double the speed at - still - 100% CPU load - i.e., if the speed was limited by CPU in the first place. You will notice a drop in CPU load only if the resulting speed is more than sufficient for your bandwidth.
9
Hardware and Performance / Re: J4125/N100 and Wireguard (for 1Gbps ISP line)
« on: May 09, 2024, 09:54:31 am »
It is said already in one of your quoted threads, J4125, N5105 and N100 differ only marginally in their effective speeds.
As for Wireguard speeds on OpnSense in general and why reports for OpnWRT and "the other FreeBSD router" differ from what OpnSense can achieve: https://forum.opnsense.org/index.php?topic=38909.msg197650#msg197650
I think that with OpnSense, you will not reach 1 Gbps even with an N100 at this time. You probably could with this on top:
As for Wireguard speeds on OpnSense in general and why reports for OpnWRT and "the other FreeBSD router" differ from what OpnSense can achieve: https://forum.opnsense.org/index.php?topic=38909.msg197650#msg197650
I think that with OpnSense, you will not reach 1 Gbps even with an N100 at this time. You probably could with this on top:
Code: [Select]
opnsense-update -zkr 14-STABLE -a FreeBSD:14:amd64
10
General Discussion / Re: Opnsense ipv6 guide request
« on: May 09, 2024, 09:44:39 am »
In theory, the traffic shaping rules should already work if you specify IPv4/IPv4 for them.
That being said, I would refrain from using them, as:
a. I found them to break IPv6 traffic completely with one of my ISPs. I never found what causes this.
b. I also had strange effects on how traffic from the OpnSense itself seems to get shaped. This caused massive performance degradations with HAproxy.
That being said, I would refrain from using them, as:
a. I found them to break IPv6 traffic completely with one of my ISPs. I never found what causes this.
b. I also had strange effects on how traffic from the OpnSense itself seems to get shaped. This caused massive performance degradations with HAproxy.
11
Intrusion Detection and Prevention / Re: Which IDS IPS rules do you prefer
« on: May 09, 2024, 12:42:02 am »
Patrick is right on the money with this opinion.
Think of it this way: Just out of caution, you would have to activate all IDS rules first, just in case any trojan or virus exhibits a behaviour that the IDS might detect. Of course, there may be many attack patterns which are not even considered even by existing rules - how should we know?
Then, you will notice that some rules fire and cause warnings (be sure not to activate IPS yet, or else you will be offline!). Then, you will have to evaluate if a threat really exists or if it was a false alarm. In the latter case, you would have to disable that rule, because if you let it active and switch on IPS later on, it will potentially block legitimate traffic.
This a a cat-and-mouse game which you will never win, because with auto-updating rules, you may still find yourself in an uncomfortable position later. On the other hand, nobody guarantees that every threat will even be caught by this.
Think of it this way: Just out of caution, you would have to activate all IDS rules first, just in case any trojan or virus exhibits a behaviour that the IDS might detect. Of course, there may be many attack patterns which are not even considered even by existing rules - how should we know?
Then, you will notice that some rules fire and cause warnings (be sure not to activate IPS yet, or else you will be offline!). Then, you will have to evaluate if a threat really exists or if it was a false alarm. In the latter case, you would have to disable that rule, because if you let it active and switch on IPS later on, it will potentially block legitimate traffic.
This a a cat-and-mouse game which you will never win, because with auto-updating rules, you may still find yourself in an uncomfortable position later. On the other hand, nobody guarantees that every threat will even be caught by this.
12
General Discussion / Re: Opnsense ipv6 guide request
« on: May 09, 2024, 12:34:49 am »
There are two separate IPv6 addresses which you can get via DHCPv6 (as a client!) from your ISP that matter:
1. The IA_NA, which is the (/128) IPv6 for the WAN interface, which you can probably see from the dashboard. This may or may not exists, according to what your ISP allows. It is not needed per se, but it is easier when it exists. If that one exists, you should be able to ping from the OpnSense itself. If it does not work, you probably failed to set the IPv6 firewall routes from the guide.
2. The IA_PD, which usually is a /56 prefix (in your guide, it is only /60), from which the LAN interfaces can get routable IPv6 addresses (this can also be ssen on the dashboard). If you have no WAN IPv6, you can use those IPv6 GUAs to ping outside, as well. These prefixes can then be used to be distributed via DHCPv6 (as a server!) or (easier) SLAAC to to LAN clients, which can then also use IPv6.
1. The IA_NA, which is the (/128) IPv6 for the WAN interface, which you can probably see from the dashboard. This may or may not exists, according to what your ISP allows. It is not needed per se, but it is easier when it exists. If that one exists, you should be able to ping from the OpnSense itself. If it does not work, you probably failed to set the IPv6 firewall routes from the guide.
2. The IA_PD, which usually is a /56 prefix (in your guide, it is only /60), from which the LAN interfaces can get routable IPv6 addresses (this can also be ssen on the dashboard). If you have no WAN IPv6, you can use those IPv6 GUAs to ping outside, as well. These prefixes can then be used to be distributed via DHCPv6 (as a server!) or (easier) SLAAC to to LAN clients, which can then also use IPv6.
13
General Discussion / Re: Opnsense ipv6 guide request
« on: May 08, 2024, 11:30:58 pm »
There is exhaustive documentation on how to do this, what is it that you do not understand or what does not work?
If you are looking for a quick guide fo a specific ISP, then how about telling which it is? If your WAN already has an IPv6 address, just follow the docs on how to get IPv6 on the local interfaces, too.
If you are looking for a quick guide fo a specific ISP, then how about telling which it is? If your WAN already has an IPv6 address, just follow the docs on how to get IPv6 on the local interfaces, too.
14
German - Deutsch / Re: Https mit Lets Encrypt
« on: May 08, 2024, 10:57:52 pm »
Oder schalte die Prüfung, wie in der Fehlermeldung geschrieben, aus. Der Hintergrund ergibt sich auch direkt aus der Fehlermeldung: https://en.wikipedia.org/wiki/DNS_rebinding
15
German - Deutsch / Re: pfSense Angriff auf Firewall, ist opnsense auch betroffen?
« on: May 08, 2024, 02:58:21 pm »
https://docs.netgate.com/downloads/pfSense-SA-24_04.webgui.asc
Scheint eine Schwachstelle im Testcode für jquery-treegrid zu sein, die offenbar in OpnSense nicht eingesetzt wird.
Scheint eine Schwachstelle im Testcode für jquery-treegrid zu sein, die offenbar in OpnSense nicht eingesetzt wird.