"Recent posts
#1
Development and Code Review / Re: 26.7.5 git tag for src rep...
Last post by none - Today at 02:34:25 PMI think I saw pointers that this change would be ARM related, while searching for this error.
Your builds are AMD64 only, right?
I will wait for 26.7.6 and try again.
Thanks for the feedback :)
none
Your builds are AMD64 only, right?
I will wait for 26.7.6 and try again.
Thanks for the feedback :)
none
#2
26.7 Series / Re: Quectel EC25‑E / EG25‑G Mi...
Last post by (MARLOO) - Today at 02:31:09 PMHi Franco,
Thank you for the clarification and for pointing out the commit
https://github.com/opnsense/core/commit/fe4c91516a35c
From what I understand, this change (introduced in 25.7.1) should have addressed part of the PPP/chat script issue on the OPNsense side, while some underlying problems in the FreeBSD stack since 14 (and now 15.1) may still remain.
For the time being, I will keep this thread open on my end. Once I receive the modem and deploy it on OPNsense 26.7.5 / FreeBSD 15.1, I will perform a structured test as a secondary WAN (failover) and follow up with a detailed report, including:
Modem model (EC25‑EUX ) and firmware version
PPP configuration (init string, APN, dial number)
Whether the connection establishes reliably out of the box or requires additional workarounds beyond the fix in the above commit.
This should provide a concrete data point for the current stack.
Thanks
Thank you for the clarification and for pointing out the commit
https://github.com/opnsense/core/commit/fe4c91516a35c
From what I understand, this change (introduced in 25.7.1) should have addressed part of the PPP/chat script issue on the OPNsense side, while some underlying problems in the FreeBSD stack since 14 (and now 15.1) may still remain.
For the time being, I will keep this thread open on my end. Once I receive the modem and deploy it on OPNsense 26.7.5 / FreeBSD 15.1, I will perform a structured test as a secondary WAN (failover) and follow up with a detailed report, including:
Modem model (EC25‑EUX ) and firmware version
PPP configuration (init string, APN, dial number)
Whether the connection establishes reliably out of the box or requires additional workarounds beyond the fix in the above commit.
This should provide a concrete data point for the current stack.
Thanks
#3
General Discussion / Re: Remote logging to Alloy, o...
Last post by homelabber123 - Today at 02:23:43 PMOkay, after some more digging, it looks like the CA is actually loaded & hashed properly in `/etc/ssl/certs`
And when I get the issuer hash, from both the client & server pems, I get the same correct hash:
So it "should" be working :D But it's not.
So I'd love to get some direction, if anyone can spot anything.
And when I get the issuer hash, from both the client & server pems, I get the same correct hash:
Code Select
$ openssl x509 -in server.pem -noout -issuer_hash
17d48176
$ openssl x509 -in client.pem -noout -issuer_hash
17d48176
$ ls /etc/ssl/certs/17d48176.0
/etc/ssl/certs/17d48176.0
So it "should" be working :D But it's not.
So I'd love to get some direction, if anyone can spot anything.
#4
General Discussion / Remote logging to Alloy, over ...
Last post by homelabber123 - Today at 01:42:01 PMHello good people,
I'm trying to do the following thing:
Overall, I've arrived at a pretty decent & workable solution, using TCP as transport.
And the final piece that I want to achieve is to actually transport those logs over TLS(4) - effectively doing mTLS between OPNsense (as syslog-provider) and Grafana Alloy (as syslog-receiver)
What I did was the following:
Here is the relevant Grafana Alloy configuration:
On the OPNsense side, I've done the following:
The error that I'm getting on the Alloy side is the following:
Which kind-of leads me to think that OPNsense is not using the CA to validate the server cert when doing the handshake.
Debugging steps I've done:
I would really appreciate your help & directions.
Please ask for whatever additional information & context you think you'll need.
p.s. the limit to TLS 1.2 was from another initial error that I was getting about a "tls: bad record MAC"
I'm trying to do the following thing:
- Pipe some of the logs, generated by OPNsense
- Remotely, to a Grafana Alloy instance (that then feeds it to Loki, etc.)
Overall, I've arrived at a pretty decent & workable solution, using TCP as transport.
And the final piece that I want to achieve is to actually transport those logs over TLS(4) - effectively doing mTLS between OPNsense (as syslog-provider) and Grafana Alloy (as syslog-receiver)
What I did was the following:
- I generated a CA, to sign the client and server certs.
- And then generated the client and server certs, where OPNsense is the client / provider, and Alloy is the server / receiver
Here is the relevant Grafana Alloy configuration:
Code Select
otelcol.receiver.syslog "remote_syslog" {
protocol = "rfc5424"
allow_skip_pri_header = true
tcp {
listen_address = "0.0.0.0:8094"
tls {
cert_file = "/etc/alloy/certs/server.pem"
key_file = "/etc/alloy/certs/server.key"
client_ca_file = "/etc/alloy/certs/ca.pem"
min_version = "1.2"
max_version = "1.2"
}
}
output {
logs = [otelcol.exporter.syslog.syslog_out.input]
}
}
On the OPNsense side, I've done the following:
- Imported the CA in System -> Trust -> Authorities, by simply pasting the PEM string
- Respectively, imported the client certs - pem & key, in System -> Trust -> Certificates
- The CA cert shows "usages" 1 & the client certs correctly display the issuer
- And last but not least, I created a new remote logging target, over TLS(4), that's using the only client certificate from the point above
- And for a good measure, I've restarted (multiple times) the Loggign service.
The error that I'm getting on the Alloy side is the following:
Code Select
remote error: tls: unknown certificate authority
Which kind-of leads me to think that OPNsense is not using the CA to validate the server cert when doing the handshake.
Debugging steps I've done:
- I've validated that the certs are good, using openssl s_client -connect {host}:{port} -CAfile ./ca.pem -cert ./client.pem -key ./client.key -state
- In fact, I've validated this from the OPNsense box itself (sshed, copied the certs in a temp folder and tasted
- I also manually sent a log line, via the openssl s_client invocation from above, using the same certs, and confirmed that it's working.
- And from digging around, it kind of looks like the imported CA is not being used by OPNsense at all
I would really appreciate your help & directions.
Please ask for whatever additional information & context you think you'll need.
p.s. the limit to TLS 1.2 was from another initial error that I was getting about a "tls: bad record MAC"
#5
Development and Code Review / Re: 26.7.5 git tag for src rep...
Last post by franco - Today at 01:36:36 PMThere is no 26.7.5 tag because 26.7.5 doesn't have a base/kernel update. In most cases use the last tag for stable build...
In this instance https://github.com/opnsense/src/commit/ed7f8101a197c4d1f was missing, but I didn't see this during our builds. A bit strange.
Cheers,
Franco
In this instance https://github.com/opnsense/src/commit/ed7f8101a197c4d1f was missing, but I didn't see this during our builds. A bit strange.
Cheers,
Franco
#6
Documentation and Translation / Re: Documentation mismatch: GU...
Last post by franco - Today at 01:29:42 PMFixed in https://github.com/opnsense/docs/commit/c5438d834 -- thanks!
#7
26.7 Series / Re: Quectel EC25‑E / EG25‑G Mi...
Last post by franco - Today at 01:21:02 PMAs far as I know that's still an issue but nobody talks about it anymore. Something wrong with FreeBSD since 14 I think, but never found out why.
But didn't https://github.com/opnsense/core/commit/fe4c91516a35c fix this on our end? It was introduced in 25.7.1 more than a year ago.
Cheers,
Franco
But didn't https://github.com/opnsense/core/commit/fe4c91516a35c fix this on our end? It was introduced in 25.7.1 more than a year ago.
Cheers,
Franco
#8
26.7 Series / Re: Good News: Less Memory-Saf...
Last post by appasquatic - Today at 01:20:33 PMAgreed!
In fact, hardware independent memory safety has to be a candidate for my Christmas wish list.
I did find this (C++ Smart Pointer Discipline or Zig) but it seems there still a lot of rework is required for use of new Zig libraries, or Smart pointers within C++
In fact, hardware independent memory safety has to be a candidate for my Christmas wish list.
I did find this (C++ Smart Pointer Discipline or Zig) but it seems there still a lot of rework is required for use of new Zig libraries, or Smart pointers within C++
#9
26.7 Series / Re: Good News: Less Memory-Saf...
Last post by KulaSekra - Today at 11:59:06 AMThe interesting part is that even if CHERI itself needs dedicated hardware, getting this kind of work into FreeBSD now could still be valuable long term. If a hardware-independent mitigation can eventually cover the existing x86-64 base, that would make the whole thing much more practical for OPNsense users rather than waiting for new firewall hardware to become commonplace.
#10
German - Deutsch / Re: Unbound-DNS Erweitert
Last post by k0ns0l3 - Today at 11:58:59 AMTHX ;)
lg k0ns0l3
lg k0ns0l3
