"Recent posts
#1
Intrusion Detection and Prevention / Re: Suricata not exiting on st...
Last post by franco - Today at 09:44:08 AMHey,
Larger thread here https://forum.opnsense.org/index.php?topic=52203.0 testing was inconclusive so far.
Doesn't seem to affect netmap so it's same same but different.
If you can find out more that would be helpful.
Cheers,
Franco
Larger thread here https://forum.opnsense.org/index.php?topic=52203.0 testing was inconclusive so far.
Doesn't seem to affect netmap so it's same same but different.
If you can find out more that would be helpful.
Cheers,
Franco
#2
Intrusion Detection and Prevention / Re: Constant DNS queries for o...
Last post by franco - Today at 09:43:20 AMThe tweak was shipped in 26.7.1.
Cheers,
Franco
Cheers,
Franco
#3
26.7 Series / Re: 26.7.1: "state-insert,bloc...
Last post by fastboot - Today at 08:30:48 AMI have now found another example which does not involve hairpin access to an internal server.
10.1.1.1 is the firewall address on this VLAN.
There is a destination NAT rule which redirects outbound UDP port 123 traffic to the firewall itself, so clients are forced to use the local NTP service. The interface firewall rule allows the subnet to access the firewall address on UDP ports 53 and 123.
This means the issue is not limited to hairpin NAT towards an internal server. It also occurs with UDP traffic destination-NATed to a service running locally on the firewall.
Code Select
vlan0.695,state-insert,block,in,4,0x0,,255,41990,0,none,17,udp,76,10.1.1.14,10.1.1.1,49753,123,56
10.1.1.1 is the firewall address on this VLAN.
There is a destination NAT rule which redirects outbound UDP port 123 traffic to the firewall itself, so clients are forced to use the local NTP service. The interface firewall rule allows the subnet to access the firewall address on UDP ports 53 and 123.
This means the issue is not limited to hairpin NAT towards an internal server. It also occurs with UDP traffic destination-NATed to a service running locally on the firewall.
#4
General Discussion / Re: Help needed to update boot...
Last post by franco - Today at 08:06:42 AMOne thing I wanted to test is if it still works in hybrid UEFI/Legacy boot mode. The standard FreeBSD installers do not work well with cross-booting. Easy to test in a VM.
Cheers,
Franco
Cheers,
Franco
#5
General Discussion / Re: Help needed to update boot...
Last post by meyergru - Today at 08:03:49 AMThe script is quite clever. I tested it on all my different installations, SATA, NVME and virtio, but all UEFI and it worked flawlessly.
#6
26.7 Series / 26.7.1: "state-insert,block" e...
Last post by fastboot - Today at 08:02:56 AMHi,
after upgrading from 26.1.x to 26.7.1, I noticed something odd that I haven't seen before.
Immediately after the upgrade, my firewall started logging a large number of state-insert,block events.
The reason I'm posting this is the timing. I've been collecting all OPNsense firewall logs in Graylog for quite some time, so I searched the last 30 days.
Result:
At first I assumed this was a WebServer issue because that was the first service that stopped working. However, nginx and PHP-FPM were both running normally and TLS handshakes completed successfully, so I started investigating the firewall instead.
The firewall log shows entries like these:
The corresponding PF rule is:
For reference, this is the current output of pfctl -si:
The state table is clearly not full, so this doesn't appear to be a state table limit issue.
My setup:
I'm not claiming that Suricata or NAT Reflection are the cause. They are simply part of my environment.
The only thing I can say with confidence is :
I'll also attach a screenshot from Graylog showing exactly that.
Has anyone else seen this after upgrading to 26.7.x?
Could this be related to the FreeBSD 15.1 / PF changes?
I did a rollback to a created snapshot, as I had not much time to debug.
Cheers,
fb
after upgrading from 26.1.x to 26.7.1, I noticed something odd that I haven't seen before.
Immediately after the upgrade, my firewall started logging a large number of state-insert,block events.
The reason I'm posting this is the timing. I've been collecting all OPNsense firewall logs in Graylog for quite some time, so I searched the last 30 days.
Result:
- Before the upgrade: 0 occurrences of state-insert
- Immediately after upgrading to 26.7.1: thousands of state-insert,block events
At first I assumed this was a WebServer issue because that was the first service that stopped working. However, nginx and PHP-FPM were both running normally and TLS handshakes completed successfully, so I started investigating the firewall instead.
The firewall log shows entries like these:
Code Select
match,pass,in,...
192.168.1.2 -> 192.168.243.10:12345
state-insert,block,in,...
192.168.1.2 -> 192.168.243.10:12345
The corresponding PF rule is:
Code Select
@218 pass in log quick on igc0_vlan4096 inet
flags S/SA keep state
label "88f5cbb7-6e4c-47da-9811-ca92e09741a7"
divert-to 8000
Evaluations: 92502
Packets: 23425
States: 7
State Creations: 1093
For reference, this is the current output of pfctl -si:
Code Select
State Table
current entries: 5717
Counters
state-insert: 7184
state-limit: 0
memory: 0
The state table is clearly not full, so this doesn't appear to be a state table limit issue.
My setup:
- OPNsense 26.7.1 (upgraded from 26.1.x)
- Suricata Inline IPS
- Hairpin NAT / NAT Reflection for exposed https service which failed after the upgrade
- Graylog for centralized firewall logging
I'm not claiming that Suricata or NAT Reflection are the cause. They are simply part of my environment.
The only thing I can say with confidence is :
- 30 days of Graylog history before the upgrade: 0 state-insert events.
- Immediately after upgrading to 26.7.1: thousands of state-insert,block events.
I'll also attach a screenshot from Graylog showing exactly that.
Has anyone else seen this after upgrading to 26.7.x?
Could this be related to the FreeBSD 15.1 / PF changes?
I did a rollback to a created snapshot, as I had not much time to debug.
Cheers,
fb
#7
Tutorials and FAQs / Re: [How-To] NPTv6 with dynami...
Last post by franco - Today at 07:57:49 AM> What can we practically gain from that change?
So the users were saying it *should* be possible to do this... and now they *can* do it and not raise tickets about how inferior the system is?
Cheers,
Franco
So the users were saying it *should* be possible to do this... and now they *can* do it and not raise tickets about how inferior the system is?
Cheers,
Franco
#8
26.1, 26,4 Series / Re: [SOLVED] Large number of f...
Last post by franco - Today at 07:55:03 AMHey Larry,
Nice, thank you for the follow up. :)
Cheers,
Franco
Nice, thank you for the follow up. :)
Cheers,
Franco
#9
26.7 Series / Re: Are RSA-7680 Trust store c...
Last post by franco - Today at 07:52:23 AMHi Paul,
I don't think we ever supported 7680. Theoretically it would be easy to add so the question is if OpenSSL/PHP/Phpseclib cope with it.
Cheers,
Franco
I don't think we ever supported 7680. Theoretically it would be easy to add so the question is if OpenSSL/PHP/Phpseclib cope with it.
Cheers,
Franco
#10
26.7 Series / Re: Services widget
Last post by drosophila - Today at 06:02:19 AMThe old one wasn't consistent, either: it used the "play" and "stop" icons for its status display (instead of being actionable buttons as convention makes one expect). I've always wondered why it doesn't use the same status indicator as the ddns and the gateway widget (a colored dot, but sadly its size is not consistent: the dot in the gateway monitor is much smaller than the one in the ddns widget). So the new version is more logical / expectation-consistent than the old one, which is always a plus.
To me, the smaller height of the individual lines is welcome, and the full-line coloring could possibly be toned down into coloring only the part that contains the controls? (BTW, where did the start / stop go? I can only judge from the provided screenshots ATM though, maybe they've been moved).
Coloring the entire line will, if extended to the entire the GUI, end up coloring most parts of the screen in green, which defeats the purpose of a dark theme at least, and will probably be harder on the eyes all in all, and may end up looking cluttered / toy-like?
The ddns widget could use an overhaul as well though, to display the type and name in one line as it does ATM, but to then display the IP address and update time as full line each, instead of cutting it off at the same boundary as the type. The current way is OK for IPv4, but breaks with IPv6. Maybe this is already fixed in the new release already?
Also, the header isn't displayed for the "image" widget either, so it's not entirely unusual. Maybe the header itself could be shrunk for the all widgets, to remove the unnecessary empty space below the orange line, like it is done with the memory, disk, CPU, ddns and some other widgets?
To me, the smaller height of the individual lines is welcome, and the full-line coloring could possibly be toned down into coloring only the part that contains the controls? (BTW, where did the start / stop go? I can only judge from the provided screenshots ATM though, maybe they've been moved).
Coloring the entire line will, if extended to the entire the GUI, end up coloring most parts of the screen in green, which defeats the purpose of a dark theme at least, and will probably be harder on the eyes all in all, and may end up looking cluttered / toy-like?
The ddns widget could use an overhaul as well though, to display the type and name in one line as it does ATM, but to then display the IP address and update time as full line each, instead of cutting it off at the same boundary as the type. The current way is OK for IPv4, but breaks with IPv6. Maybe this is already fixed in the new release already?
Also, the header isn't displayed for the "image" widget either, so it's not entirely unusual. Maybe the header itself could be shrunk for the all widgets, to remove the unnecessary empty space below the orange line, like it is done with the memory, disk, CPU, ddns and some other widgets?
