"Recent posts
#1
26.7 Series / Re: Caddy Layer4 Route TLS (SN...
Last post by ept - Today at 08:20:55 PMThank you, that solves it!
(I have to admit that I even saw this PR, but didn't realize from the problem description that it fits to my issue.)
(I have to admit that I even saw this PR, but didn't realize from the problem description that it fits to my issue.)
#2
26.7 Series / Re: Dashboard: Interface Stati...
Last post by MoonbeamFrame - Today at 08:13:26 PM #3
26.7 Series / Dashboard: Interface Statistic...
Last post by vimage22 - Today at 07:57:35 PMVersion 26.7.3_11 (clean install)
After login, the Dashboard shows "Interface Statistics" with a very long vertical dimension. On the automatic refresh, it returns to normal, configured size. Is this a "Theme" issue, or something else?
After login, the Dashboard shows "Interface Statistics" with a very long vertical dimension. On the automatic refresh, it returns to normal, configured size. Is this a "Theme" issue, or something else?
#4
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by oc - Today at 07:20:49 PMHello meyergru,
Just so I know which info to collect for not confusing you - which interface should that be? As I think we now ruled out the initial suspect (inbound WG). Just for recollection - the OPNsense boots normally with the three outbound WG connections to names instead of IPs disabled, and with the inbound connection enabled. Hence it's one or more of the three causing the unwanted behavior (pointed out by others as well).
Would it be simpler to disable two of the three outbound WG connections, and provide the output of the third one? At least that way there would be some clear attribution...Thank you!
Just so I know which info to collect for not confusing you - which interface should that be? As I think we now ruled out the initial suspect (inbound WG). Just for recollection - the OPNsense boots normally with the three outbound WG connections to names instead of IPs disabled, and with the inbound connection enabled. Hence it's one or more of the three causing the unwanted behavior (pointed out by others as well).
Would it be simpler to disable two of the three outbound WG connections, and provide the output of the third one? At least that way there would be some clear attribution...Thank you!
#5
26.7 Series / Re: Boot stuck for 1-2 min aft...
Last post by oc - Today at 07:19:22 PMHello Gilgamesh,
I have the same issue. Sharing with you my topic: https://forum.opnsense.org/index.php?topic=52901.0
Did you find any solution in the meantime?
I have the same issue. Sharing with you my topic: https://forum.opnsense.org/index.php?topic=52901.0
Did you find any solution in the meantime?
#6
26.7 Series / Re: block events without Label...
Last post by vimage22 - Today at 06:36:31 PMAll loggings settings in Advanced are unchecked. And this is how it was setup in older versions. So still puzzled why these appear.
Also, just realized the rule is set to Pass, not block.
And "Disable RFC4890 requirement rules" is unchecked.
Does this show anything interesting?
action [block]
class 0x00
dir [in]
dst ff02::16
dsthostname ff02::16
flow 0x00000
hoplimit 1
interface bridge0
ipversion 6
label
length 76
protoname icmp
protonum 1
reason ip-option
src ::
srchostname ::
status 2
Also, just realized the rule is set to Pass, not block.
And "Disable RFC4890 requirement rules" is unchecked.
Does this show anything interesting?
action [block]
class 0x00
dir [in]
dst ff02::16
dsthostname ff02::16
flow 0x00000
hoplimit 1
interface bridge0
ipversion 6
label
length 76
protoname icmp
protonum 1
reason ip-option
src ::
srchostname ::
status 2
#7
26.7 Series / Re: block events without Label...
Last post by lmoore - Today at 06:14:15 PMCheck setting for Disable RFC4890 requirement rules in Firewall -> Settings -> Advanced, is it unticked?
#8
26.7 Series / Re: block events without Label...
Last post by vimage22 - Today at 06:00:06 PMAgreed, but then shouldn't this be displayed as the Label? "IPv6 RFC4890 requirements (ICMP)"
#9
26.7 Series / Re: Caddy Layer4 Route TLS (SN...
Last post by Monviech (Cedrik) - Today at 05:59:07 PMYou can add a sequence to the routes already and theyre rendered in that order. :)
Its also needed for other things so I added it almost at the beginning of that feature.
https://github.com/opnsense/plugins/blob/261c32ef7196199a7bc0224bc4df7b9a02eb1d57/www/caddy/src/opnsense/mvc/app/controllers/OPNsense/Caddy/forms/dialogLayer4.xml#L17
Its also needed for other things so I added it almost at the beginning of that feature.
https://github.com/opnsense/plugins/blob/261c32ef7196199a7bc0224bc4df7b9a02eb1d57/www/caddy/src/opnsense/mvc/app/controllers/OPNsense/Caddy/forms/dialogLayer4.xml#L17
#10
26.7 Series / Re: Caddy Layer4 Route TLS (SN...
Last post by meyergru - Today at 05:32:18 PMThis appears to be the already identified caddy-l4 routing bug described in PR #455, rather than merely another insufficient prefetch-buffer size.
If a TLS matcher needs more data because the ClientHello arrived in multiple TCP segments, a subsequent HTTP route can reach a definitive non-match and inadvertently suppress the pending TLS match. Post-quantum ClientHellos make this much more reproducible because they commonly span multiple TCP segments.
This fits your observations exactly: curl and Firefox without Kyber send a smaller ClientHello, whereas current Firefox and Chromium trigger the bug.
As a workaround, try placing all Layer 4 HTTP routes before all TLS/SNI routes. PR #455 specifically identifies that route ordering as a workaround and states that caddy-l4 0.1.2 is affected. IDK if that is possible via the GUI, though... otherwise, Deciso would have to either include the PR or change configuration ordering.
If a TLS matcher needs more data because the ClientHello arrived in multiple TCP segments, a subsequent HTTP route can reach a definitive non-match and inadvertently suppress the pending TLS match. Post-quantum ClientHellos make this much more reproducible because they commonly span multiple TCP segments.
This fits your observations exactly: curl and Firefox without Kyber send a smaller ClientHello, whereas current Firefox and Chromium trigger the bug.
As a workaround, try placing all Layer 4 HTTP routes before all TLS/SNI routes. PR #455 specifically identifies that route ordering as a workaround and states that caddy-l4 0.1.2 is affected. IDK if that is possible via the GUI, though... otherwise, Deciso would have to either include the PR or change configuration ordering.
