"Recent posts
#1
General Discussion / Crowdsec Observations
Last post by ruzamai - Today at 03:09:49 AMJust putting my observations here after 3 years I guess of using Crowdsec across various platforms.
I've noticed that Crowdsec has never blocked anything that my firewall rules don't block anyway. And there's constant pressure to upsell.
The observability into IP addresses is great.
However, it doesn't seem to be necessary other than as a scare sell to replace Fail2Ban, which I don't use either because I don't need it - because of the afore mentioned firewall rules.
I'm certain it's useful if you don't want to spend in depth time configuring firewalls, and then it makes sense.
In my case it's needless overhead, and I'm removing it from all my infrastructure, including Opnsense.
Interested to hear what others think.
Edit - Crowdsec's only practical use is for dashboard insights, and on the free tier those can be exhausted for a month in just minutes, while your servers provide free attack intel for the Crowdsec network, that you can't use yourself unless you upgrade your account for a ridiculous subscription charge.
On one server this month Crowdsec claimed it had blocked nearly 20k attacks, all of which however were already blocked by the firewall. So Crowdsec is just claiming normal noise as prevented attacks. The "prevented attacks" on this network were mostly against an ipv4 network with no open ports, so blocked by default, with a small number against an ipv6 network with only port 443 open.
If I'm missing something here please explain it to me!
Samuel
I've noticed that Crowdsec has never blocked anything that my firewall rules don't block anyway. And there's constant pressure to upsell.
The observability into IP addresses is great.
However, it doesn't seem to be necessary other than as a scare sell to replace Fail2Ban, which I don't use either because I don't need it - because of the afore mentioned firewall rules.
I'm certain it's useful if you don't want to spend in depth time configuring firewalls, and then it makes sense.
In my case it's needless overhead, and I'm removing it from all my infrastructure, including Opnsense.
Interested to hear what others think.
Edit - Crowdsec's only practical use is for dashboard insights, and on the free tier those can be exhausted for a month in just minutes, while your servers provide free attack intel for the Crowdsec network, that you can't use yourself unless you upgrade your account for a ridiculous subscription charge.
On one server this month Crowdsec claimed it had blocked nearly 20k attacks, all of which however were already blocked by the firewall. So Crowdsec is just claiming normal noise as prevented attacks. The "prevented attacks" on this network were mostly against an ipv4 network with no open ports, so blocked by default, with a small number against an ipv6 network with only port 443 open.
If I'm missing something here please explain it to me!
Samuel
#2
Hardware and Performance / Re: DEC750 realistic 10G expec...
Last post by pfry - Today at 02:51:48 AMHow about "sysctl hw.hn | grep udp". It's a reach, but hey.
#3
Russian - Русский / Re: os-xray — плагин Xray-core...
Last post by tyra - Today at 02:44:13 AMДоброй ночи. Подскажите никак не могу завести xray всё зелёное а вот:
Bytes In 0 B
Bytes Out 0 B
Packets In 0
Packets Out 0
в конфиге прописываю ip routera и с ip local пробывал трафик не идёт...
Bytes In 0 B
Bytes Out 0 B
Packets In 0
Packets Out 0
в конфиге прописываю ip routera и с ip local пробывал трафик не идёт...
#4
Hardware and Performance / Re: Sanity check for N100 / i2...
Last post by pfry - Today at 02:38:57 AMQuote from: nero355 on June 08, 2026, 06:47:47 PM[...]Why would that be slower than the speed between two random Clients that are let's say connected to the same Default LAN network of OPNsense?[...]
Additional CPU load. Also, OPNsense likely compares well to FreeBSD (and perhaps less well to Windows or Linux), but I tune FreeBSD extensively for network/TCP performance, while I don't bother so much with OPNsense, as I terminate few sessions on the firewall. But then, I'm only speculating, as I haven't tested this scenario.
#5
26.1, 26,4 Series / Re: Gratitious ARP from ISP ca...
Last post by pfry - Today at 02:26:49 AMWhat is the Atrie equipment on your network? I assume it's Wienenergie, assuming the IPs and MACs are real (those MAC numbers do not appear to be random within the range). Is the service delivered via fiber to the modem you mention?
That's an... odd behavior. VRRP, etc. will use virtual MACs, not actual, so the MAC should not change. It could be some sort of odd proxy, e.g. if you are somehow connected to multiple drops (that is, multiple upstream interfaces/ports are visible) which are unlimited ARP proxies (like the equipment Vz/Frontier uses here). I would expect a static entry to sorta fix that issue. Telco devices tend to be promiscuous forwarders, so hitting the wrong MAC might still work; since it's a real bridge, it should not duplicate packets when looped (you can check, if you have access to equipment connected to the Internet elsewhere, where you could send, say, a ping, and look for duplicates) (I had that situation with an old DSL-ish service).
(Oddly, FreeBSD and Windows are vulnerable to ARP proxies, while Linux is not. One of these days I'll look into that... But if you had a Linux-based router handy, you could see how it behaves.)
That's an... odd behavior. VRRP, etc. will use virtual MACs, not actual, so the MAC should not change. It could be some sort of odd proxy, e.g. if you are somehow connected to multiple drops (that is, multiple upstream interfaces/ports are visible) which are unlimited ARP proxies (like the equipment Vz/Frontier uses here). I would expect a static entry to sorta fix that issue. Telco devices tend to be promiscuous forwarders, so hitting the wrong MAC might still work; since it's a real bridge, it should not duplicate packets when looped (you can check, if you have access to equipment connected to the Internet elsewhere, where you could send, say, a ping, and look for duplicates) (I had that situation with an old DSL-ish service).
(Oddly, FreeBSD and Windows are vulnerable to ARP proxies, while Linux is not. One of these days I'll look into that... But if you had a Linux-based router handy, you could see how it behaves.)
#6
26.1, 26,4 Series / Re: Gratitious ARP from ISP ca...
Last post by Seimus - Today at 02:21:33 AMStatic arp will pin a specific MAC to a Specific IP. If that MAC is not available the IP will not be reachable.
There are cases where static ARP is used.
But your logs point to be an issue on the ISP side of things. Did you try to contact the ISP?
Regards,
S.
There are cases where static ARP is used.
But your logs point to be an issue on the ISP side of things. Did you try to contact the ISP?
Regards,
S.
#7
26.1, 26,4 Series / OPNSense forwarding packets se...
Last post by ChristopherL - Today at 02:17:15 AMHi,
I am having an issue where OPNSense is creating duplicate packets every time there is unknown unicast on our network. The cause seems to be the firewalls attempting to forward any packets that arrive on their interface, even if those packets aren't sent to the firewall's MAC address.
I found this topic, but there was no resolution. This differs slightly from our setup, as our firewalls are running on physical hardware.
This caused an outage for us in the following scenario:
In our DMZ we have two border routers running linux, an HA pair of OPNSense office firewalls running CARP, and a few DMZ hosts.
The border routers were responding to ARP requests for the gateway address twice, once with the physical interface MAC address and once with a linux bridge MAC address, but would only send packets with the physical interface MAC.
If a host learnt the bridge MAC, it would send packets to that MAC address, but because there would be no replies from that MAC address, the switches would eventually time out their MAC table entry, and would start flooding the unknown unicast.
The flooded packets would arrive at (both of) the OPNSense firewalls, and they would forward them on to the gateway, creating duplicate packets.
However, if the OPNSense firewalls also learnt the bridge MAC address, their forwarded packets would also be broadcast. This would create a routing loop, where we would generate 128 copies of every packet, as well as a bunch of TTL exceeded ICMP.
We have resolved this issue by stopping the gateways from responding twice to ARP requests, but potentially we could see a similar problem any time there is unknown unicast on the network, for instance if a host went down.
Here's a (anonymised) tcpdump (this was taken after the outage, during testing, when the firewall had learnt the correct MAC address).
ifconfig suggests we have the IFF_PROMISC flag set on this interface (and, as best as I can tell, not IFF_PPROMISC):
Looking through the source code, this comment suggests that promiscuous packets shouldn't be forwarded. And the logic for that appears to be here.
However, for whatever reason, it seems that these packets are being forwarded.
I am running:
Type opnsense-business
Version 26.4_6
Architecture amd64
And we have these plugins:
os-caddy (installed)
os-cpu-microcode-intel
os-frr (installed)
os-lldpd (misconfigured)
os-net-snmp (installed)
os-OPNBEcore (installed)
os-OPNWAF (installed)
os-relayd (installed)
os-zabbix7-agent (installed)
Do you have any suggestions what would be causing these packets to be forwarded?
I am having an issue where OPNSense is creating duplicate packets every time there is unknown unicast on our network. The cause seems to be the firewalls attempting to forward any packets that arrive on their interface, even if those packets aren't sent to the firewall's MAC address.
I found this topic, but there was no resolution. This differs slightly from our setup, as our firewalls are running on physical hardware.
This caused an outage for us in the following scenario:
In our DMZ we have two border routers running linux, an HA pair of OPNSense office firewalls running CARP, and a few DMZ hosts.
The border routers were responding to ARP requests for the gateway address twice, once with the physical interface MAC address and once with a linux bridge MAC address, but would only send packets with the physical interface MAC.
If a host learnt the bridge MAC, it would send packets to that MAC address, but because there would be no replies from that MAC address, the switches would eventually time out their MAC table entry, and would start flooding the unknown unicast.
The flooded packets would arrive at (both of) the OPNSense firewalls, and they would forward them on to the gateway, creating duplicate packets.
However, if the OPNSense firewalls also learnt the bridge MAC address, their forwarded packets would also be broadcast. This would create a routing loop, where we would generate 128 copies of every packet, as well as a bunch of TTL exceeded ICMP.
We have resolved this issue by stopping the gateways from responding twice to ARP requests, but potentially we could see a similar problem any time there is unknown unicast on the network, for instance if a host went down.
Here's a (anonymised) tcpdump (this was taken after the outage, during testing, when the firewall had learnt the correct MAC address).
Code Select
root@office-fwa:~ # tcpdump -nevi lagg0 host 192.0.2.1 and icmp
tcpdump: listening on lagg0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:44:29.101744 22:22:22:22:22:22 > 44:44:44:44:44:44, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 25992, offset 0, flags [DF], proto ICMP (1), length 84)
192.0.2.2 > 192.0.2.1: ICMP echo request, id 40050, seq 403, length 64
12:44:29.101747 66:66:66:66:66:66 > 88:88:88:88:88:88, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 25992, offset 0, flags [DF], proto ICMP (1), length 84)
192.0.2.2 > 192.0.2.1: ICMP echo request, id 40050, seq 403, length 64In this example 192.0.2.1 is the gateway, 192.0.2.2 is the host. 22:22:22:22:22:22 is the host MAC, 44:44:44:44:44:44 is the router bridge MAC, 88:88:88:88:88:88 is the router physical interface MAC, and 66:66:66:66:66:66 is the firewall MAC.ifconfig suggests we have the IFF_PROMISC flag set on this interface (and, as best as I can tell, not IFF_PPROMISC):
Code Select
root@office-fwa:~ # ifconfig lagg0
lagg0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500It seems that this is because we are running CARP.Looking through the source code, this comment suggests that promiscuous packets shouldn't be forwarded. And the logic for that appears to be here.
However, for whatever reason, it seems that these packets are being forwarded.
I am running:
Type opnsense-business
Version 26.4_6
Architecture amd64
And we have these plugins:
os-caddy (installed)
os-cpu-microcode-intel
os-frr (installed)
os-lldpd (misconfigured)
os-net-snmp (installed)
os-OPNBEcore (installed)
os-OPNWAF (installed)
os-relayd (installed)
os-zabbix7-agent (installed)
Do you have any suggestions what would be causing these packets to be forwarded?
#9
General Discussion / Re: newbie trying to set up ne...
Last post by lumilumi - Today at 01:22:20 AMso ive been talking too with my buddy about this
we've come up with the solution of
ISP modem -- connecting to mini PC running opensense
then repurposing my old "openwrt one" (openwrt one is a box that openwrt designed to run openwrt / supports their funds)
to run that as the wifi piece (since I already have this box)
I may switch the openwrt one to a netgear: https://www.amazon.com/NETGEAR-Wireless-Access-Point-WAX210PA/dp/B0DLDMHCWC
how do I configure the settings in order for the mini pc to "send the internet" to the openwrt one, so that the openwrt one can be my wifi access point?
we've come up with the solution of
ISP modem -- connecting to mini PC running opensense
then repurposing my old "openwrt one" (openwrt one is a box that openwrt designed to run openwrt / supports their funds)
to run that as the wifi piece (since I already have this box)
I may switch the openwrt one to a netgear: https://www.amazon.com/NETGEAR-Wireless-Access-Point-WAX210PA/dp/B0DLDMHCWC
how do I configure the settings in order for the mini pc to "send the internet" to the openwrt one, so that the openwrt one can be my wifi access point?
#10
General Discussion / Re: losing internet connection...
Last post by Djazeiry - Today at 01:05:52 AMQuote from: nero355 on May 14, 2026, 01:49:13 PMQuote from: Djazeiry on May 14, 2026, 10:43:23 AMeverything works fine for a few days and then suddenly i lose the internet connection on the networkWhat are your hardware specifications ?!
And are you 100% sure it's not the Ubiquiti Wireless Bridge having issues for whatever reason ?!
Thanks for your answer , nope there is no issues when put back a tenda "simple" internet stay vonnected and everything works normally for days , and when i put back the opensns backup file ...it work normally for two weeks and then it won't resolve any domaine name
