"Recent posts
#1
25.1, 25.4 Series / Reply-to not being added to se...
Last post by unfinishedimpact - Today at 06:37:06 PMI'm running V25.1.10 and have hit a snag with a multi-WAN setup which I suspect may be a bug (and possibly still present in later versions).
My setup consists of both a FTTP broadband connection (PPPoE) on the "WAN" interface (by identifier) and a Cable internet connection on opt4 (DHCP). Until recently, the Cable gateway was my primary connection (i.e. the default-route), and the PPPoE gateway was my secondary (failover), and everything was fine.
However today, I wanted to flip things around, so I promoted my PPPoE interface's gateway to a higher priority, so it became the default-route. It was then I noticed that inbound connections to my Cable internet's IP address began failing. The reason - the replies were routing asymmetrically and were going back out my PPPoE connection (clearly following the default route!).
I have double checked and I definitely do NOT have the "Disable reply-to on WAN rules" option ticked in Firewall->Settings->Advanced, which means OPNsense should be adding a reply-to flag to my inbound WAN rules for my cable internet connection.
When I dump out my ruleset (i.e. cat /tmp/rules.debug), no reply-to flag is being set on my inbound cable WAN rules. Although reply-to IS being correctly added to my PPPoE connection's inbound WAN rules.
So it almost seems like OPNsense only considers my PPPoE connection a WAN connection (even though I have an active, albeit lower-priority gateway on that interface).
I know I could go through and manually edit all my Cable internet WAN rules to force the reply-to, to the gateway of the cable internet, but this seems a kludge and also I have a few NAT port-forwards setup which don't seem to allow that option when using an associated, auto-generated WAN firewall rule (which cannot be edited). So I'd need to split these port-forwards out into NAT+separate access rules, which is even more kludgy!
This issue was masked when my default-route was set to the cable internet's gateway, because the return packets for inbound connections on my cable IP then just followed the default route back out the right (cable) interface. Seeing as my PPPoE connection IS getting the reply-to added to its rules, inbound connections to it always work OK, regardless of the default-route, which is why I never noticed the issue before switching gateways.
Does anybody have any thoughts on why OPNsense is refusing to add the reply-to flag on my cable interface's inbound WAN rules (but it's working just fine for the PPPoE interface!?!). Any help most appreciated!
My setup consists of both a FTTP broadband connection (PPPoE) on the "WAN" interface (by identifier) and a Cable internet connection on opt4 (DHCP). Until recently, the Cable gateway was my primary connection (i.e. the default-route), and the PPPoE gateway was my secondary (failover), and everything was fine.
However today, I wanted to flip things around, so I promoted my PPPoE interface's gateway to a higher priority, so it became the default-route. It was then I noticed that inbound connections to my Cable internet's IP address began failing. The reason - the replies were routing asymmetrically and were going back out my PPPoE connection (clearly following the default route!).
I have double checked and I definitely do NOT have the "Disable reply-to on WAN rules" option ticked in Firewall->Settings->Advanced, which means OPNsense should be adding a reply-to flag to my inbound WAN rules for my cable internet connection.
When I dump out my ruleset (i.e. cat /tmp/rules.debug), no reply-to flag is being set on my inbound cable WAN rules. Although reply-to IS being correctly added to my PPPoE connection's inbound WAN rules.
So it almost seems like OPNsense only considers my PPPoE connection a WAN connection (even though I have an active, albeit lower-priority gateway on that interface).
I know I could go through and manually edit all my Cable internet WAN rules to force the reply-to, to the gateway of the cable internet, but this seems a kludge and also I have a few NAT port-forwards setup which don't seem to allow that option when using an associated, auto-generated WAN firewall rule (which cannot be edited). So I'd need to split these port-forwards out into NAT+separate access rules, which is even more kludgy!
This issue was masked when my default-route was set to the cable internet's gateway, because the return packets for inbound connections on my cable IP then just followed the default route back out the right (cable) interface. Seeing as my PPPoE connection IS getting the reply-to added to its rules, inbound connections to it always work OK, regardless of the default-route, which is why I never noticed the issue before switching gateways.
Does anybody have any thoughts on why OPNsense is refusing to add the reply-to flag on my cable interface's inbound WAN rules (but it's working just fine for the PPPoE interface!?!). Any help most appreciated!
#2
25.7, 25.10 Series / Re: After updating Opnsense fr...
Last post by franco - Today at 06:10:31 PMTwo people ending up identifying Suricata as the culprit on 25.7.11 when it was updated to 8.0.3? Hmm... try reverting, restarting the service and see if that's better.
# opnsense-revert -r 25.7.10 suricata
Cheers,
Franco
# opnsense-revert -r 25.7.10 suricata
Cheers,
Franco
#3
General Discussion / Re: Where is TCP processed - C...
Last post by chemlud - Today at 05:58:19 PMTumbleweed is quite stable. Most of the time, you have to know, when you better NOT update, but that's not that hard.
The devices with Coreboot are "in production", so not easy to swap the OS. And as the problem is with TW updates, not with the browser (see above): how to test then?
So largely: Self-inflicted pain, one might say. It bugs me not to know, what is going on here. OPNsense has no traffic shaper enabled, what should IPS/IDS do to the bandwith of one client, but not to another on the same switch?
The devices with Coreboot are "in production", so not easy to swap the OS. And as the problem is with TW updates, not with the browser (see above): how to test then?
So largely: Self-inflicted pain, one might say. It bugs me not to know, what is going on here. OPNsense has no traffic shaper enabled, what should IPS/IDS do to the bandwith of one client, but not to another on the same switch?
#4
25.7, 25.10 Series / Re: OPNsense 25.7.10 . Noti...
Last post by pfry - Today at 05:23:16 PMQuote from: nero355 on Today at 04:46:33 PM[...]IMHO mainly the Samsung "Pro" Series NVMe SSD's have that issue and the rest not as much.[...]
Overall, it's just a matter of:
- power targets
- thermal mass
- radiative area
- convection/airflow
I get "enterprise" or "data center" devices (a stretch for M.2, but hey), which tend to nail themselves at maximum power (~8W for M.2) for maximum performance. Keeping such devices in the M.2 form factor cool is a challenge, especially where radiative area is constrained. Consumer-type devices keep cool(er) mainly through low power targets (which hurt performance) and PSLC caching (which greatly improves performance, but has a limited endurance). Same old tradeoffs.
#5
26.1 Series / Re: Destination NAT and Firewa...
Last post by keeka - Today at 05:17:58 PMOne rule performs the NAT and the second permits the resulting traffic. With the previous system, it was a NAT port forward rule and a (potentially auto-managed) firewall rule.
I have not tried 26.1RC yet. But I have a feeling, with the way I've set up NAT and FW under 25.7, a straight forward migration will not be possible. For example, the change in the priority of floating rules on single interfaces and the lack of auto/associated firewall rules for port forwards.
I have not tried 26.1RC yet. But I have a feeling, with the way I've set up NAT and FW under 25.7, a straight forward migration will not be possible. For example, the change in the priority of floating rules on single interfaces and the lack of auto/associated firewall rules for port forwards.
#6
General Discussion / Re: Where is TCP processed - C...
Last post by nero355 - Today at 05:10:58 PMQuote from: chemlud on Today at 01:36:40 PMTumbleweedIs that the only thing that shows this issue ?!
AFAIK Tumbleweed is a rolling distro based on "Not yet Stable code" like Debian Testing for example.
Could that be the issue ?
What happens when you boot a random Live environment of any other distro ?
QuoteWhat can downgrade HTTPS for a specific client? Fingerprinting, ID of install, whatever?I would say :
- Traffic Shaping Rules.
- IDS/IPS software anywhere in your network.
#7
General Discussion / Re: Forum connection issues
Last post by OPNenthu - Today at 05:00:37 PMThe issues seem to have tapered off for me, too. Haven't noticed the issue with fontawesome.com yet.
#8
General Discussion / Re: ISC-DHCP to KEA Migration ...
Last post by nero355 - Today at 04:59:40 PMThis is nice to have, but it's not really needed since you can Import/Export all Static DHCP Mappings by using the .csv files Import/Export option in the OPNsense webGUI ;)
#9
Hardware and Performance / Re: Multi Threaded PPPOE For M...
Last post by nero355 - Today at 04:55:20 PMIt's something that needs fixing in FreeBSD in order to be multi-threaded in OPNsense so head over there and try to find the right mailing list or GitHUB webpage connected to it :)
Please also note that these two things are different :
- Multi-threading support.
- Multiple CPU/Cores support.
All software is multi-threaded in general, but in order to benefit from the processing power of multiple CPU's or Cores some software needs additional development ;)
And in this case it's the lack of 'Multiple CPU/Core support' that limits the PPPoE speeds in FreeBSD/OPNsense compared to Linux based distros.
Please also note that these two things are different :
- Multi-threading support.
- Multiple CPU/Cores support.
All software is multi-threaded in general, but in order to benefit from the processing power of multiple CPU's or Cores some software needs additional development ;)
And in this case it's the lack of 'Multiple CPU/Core support' that limits the PPPoE speeds in FreeBSD/OPNsense compared to Linux based distros.
#10
25.7, 25.10 Series / Re: After updating Opnsense fr...
Last post by TCMSLP - Today at 04:54:25 PMSigned up to the forum to report exactly the same issue. The box appears stable until I login, then memory consumption quickly climbs to 100% and the UI becomes unresponsive. I've tried disabling host / neighbourhood discovery but this makes zero difference.
Update 1:
I've now identified the problem process:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 51727 0.1 58.8 11386908 2316112 - Ss 17:35 1:52.31 /usr/local/bin/suricata -D --netmap --pidfile /var/run/suricata.pid -c /usr/local/etc/suricata/suricata.yaml
After identifying this, I disabled intrusion detection and now everything is back to normal.
Update 2:
Re-enabling IDS (and IPS) immediately causes the issue again. However, I'm now wondering if new rules/changes may have increased memory usage; perhaps using the web UI is adding to this demand/exhaustion. Either way, disabling IDS has solved my immediate problem.
OPNsense 25.7.11_2, 4GB RAM, i5-4570.
Update 1:
I've now identified the problem process:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 51727 0.1 58.8 11386908 2316112 - Ss 17:35 1:52.31 /usr/local/bin/suricata -D --netmap --pidfile /var/run/suricata.pid -c /usr/local/etc/suricata/suricata.yaml
After identifying this, I disabled intrusion detection and now everything is back to normal.
Update 2:
Re-enabling IDS (and IPS) immediately causes the issue again. However, I'm now wondering if new rules/changes may have increased memory usage; perhaps using the web UI is adding to this demand/exhaustion. Either way, disabling IDS has solved my immediate problem.
OPNsense 25.7.11_2, 4GB RAM, i5-4570.
