Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Tugdualenligne

#1
Just wanted to share as I spent hours trying to solve this:
Situation:
- OPNsense firewall with ACME client able to create certificates using PAT (Gandi's Personal Access Token, required to create the txt record in the DNS system temporarily)
- for some reason, the PROD ACME environment wasn't able to create a certificate, while the STAGING ACME environment was able to

Solution:
- I logged in OPNsense root shell account using SSH
- I copied the last two lines of the STAGING file found in here /var/etc/acme-client/accounts/*_stg/account.conf
- I edited /var/etc/acme-client/accounts/*_prod/account.conf, replacing the last line GANDI_LIVEDNS_TOKEN by the last two lines that are in the STAGING account.conf
- then within OPNsense web UI I issued a new PROD certificate, imported it (there's a small button for that), and switched in System / Settings / Administration the two STAG and PROD certificates to obviously use the new valid PROD certificate

I've been trying to solve that for months
At last!

(where * is for example 64da74b3412297.72803120_prod, or *_stag)
#2
but I can obtain Let's Encrypt staging certificates.
Very strange issue. Any help appreciated
Here's my error logs:
2024-03-02T18:57:52   opnsense   AcmeClient: validation for certificate failed: oceanos.XXXX.fr
2024-03-02T18:57:52   opnsense   AcmeClient: domain validation failed (dns01)
2024-03-02T18:57:52   opnsense   /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php: AcmeClient: The shell command returned exit code '1': '/usr/local/sbin/acme.sh --issue --syslog 6 --log-level 1 --server 'letsencrypt' --dns 'dns_gandi_livedns' --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/65da763b0ae855.58243047' --certpath '/var/etc/acme-client/certs/65da763b0ae855.58243047/cert.pem' --keypath '/var/etc/acme-client/keys/65da763b0ae855.58243047/private.key' --capath '/var/etc/acme-client/certs/65da763b0ae855.58243047/chain.pem' --fullchainpath '/var/etc/acme-client/certs/65da763b0ae855.58243047/fullchain.pem' --domain 'oceanos.XXXX.fr' --domain 'oceanos.XXXX.fr' --days '1' --force --ocsp --keylength '4096' --accountconf '/var/etc/acme-client/accounts/65da74b1412297.72803520_prod/account.conf''
2024-03-02T18:57:47   opnsense   AcmeClient: using challenge type: DNS-challenge
2024-03-02T18:57:47   opnsense   AcmeClient: account is registered: ACME
2024-03-02T18:57:47   opnsense   AcmeClient: using CA: letsencrypt
2024-03-02T18:57:47   opnsense   AcmeClient: issue certificate: oceanos.XXXX.fr

And

2024-03-02T18:57:51   acme.sh   [Sat Mar 2 18:57:51 CET 2024] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
2024-03-02T18:57:51   acme.sh   [Sat Mar 2 18:57:51 CET 2024] Please add '--debug' or '--log' to check more details.
2024-03-02T18:57:51   acme.sh   [Sat Mar 2 18:57:51 CET 2024] Error add txt for domain:_acme-challenge.oceanos.XXXX.fr
2024-03-02T18:57:50   acme.sh   [Sat Mar 2 18:57:50 CET 2024] Adding txt value: SHslfCqq9nxoy4A_rKvmsJp4LF_anCWl0iluEB3jU_Y for domain: _acme-challenge.oceanos.XXXX.fr
2024-03-02T18:57:50   acme.sh   [Sat Mar 2 18:57:50 CET 2024] Getting webroot for domain='oceanos.XXXX.fr'
2024-03-02T18:57:50   acme.sh   [Sat Mar 2 18:57:50 CET 2024] Getting webroot for domain='oceanos.XXXX.fr'
2024-03-02T18:57:48   acme.sh   [Sat Mar 2 18:57:48 CET 2024] Getting domain auth token for each domain
2024-03-02T18:57:48   acme.sh   [Sat Mar 2 18:57:48 CET 2024] Multi domain='DNS:oceanos.XXXX.fr,DNS:oceanos.XXXX.fr'
2024-03-02T18:57:48   acme.sh   [Sat Mar 2 18:57:48 CET 2024] Using CA: https://acme-v02.api.letsencrypt.org/directory


Issue logged here https://github.com/opnsense/plugins/issues/3844
#3
Thanks for your response.
That might not be my ideal solution (i.e. encrypting smb traffic internally), but I'll look into it

Any other idea gents?
#4
Everything is in the subject of this message.
Can someone please explain how to protect Samba (port 445 TCP) with Suricata, while not slowing too much the network speeds? What rules do you activate / deactivate? My network is 100% Linux and MacOsx with Gb interfaces and switches, which deliver great speeds when Suricata is off.
Suricata IDS/IPS are active on LAN, WLAN and DMZ interfaces, working great but slowing in particular SMB flows. Rest of traffic do not appear to slow down, or, at least, this is not noticeable.
Many thanks in advance
#5
I got the issue another time. When I deactivate the WG (WireGuard) interface in the Wireguard settings, it stops the 100% CPU usage. So I'm staying with that setting at the moment...

If anyone has an idea... it'll be most welcome

Many thanks
#6
Hi there,
Any idea why I get that error in my logs? I don't have IPv6 configured on my OPNsense (except the WAN address, but with no relay configured)

I get:
dhcp6c[10139]: Sending Solicit
dhcp6c[10139]: advertise contains NoAddrsAvail status

Many thanks in advance
#7
Thanks for your response. I tried and rebooted my system. Will keep you posted on what happens next (if any).

By the way, going to the root console, I noticed the follwing messages that appear a bit weird (I didn't disable the wg (WireGuarg) interface, so not sure why it was 'destryed'
#8
I'm using a Qotom Q350G4, CPU i5-4200U
#9
Hi there, I've had twice the same issue with one my CPU bloated at 100% on this:
/usr/local/sbin/syslogd -s -c -c -P /var/run/syslog.pid -p /var/run/legacy_log -S /var/run/legacy_logpriv -k -s -s -f /var/etc/

In the Suricata logs I get also that message (inked to the WireGuard interface I have created):
suricata: [101248] <Error> -- [ERRCODE: SC_ERR_NETMAP_READ(264)] - Error reading data from iface 'wg1': (55u) No buffer space available

The only way to stop that 100% use was to stop the Suricata IDS.
Issue is that 1/ this is not normal; 2/ it barely enables the rest of the system to function correctly (web sites not accessible); 3/ and my server is quite hot! (passive cooling)

I have had that issue with both versions 20.1.3 and 20.1.4

Any ideas how to correct that please?

Many thanks in advance
#10
I'm qui te interested in this as well.
Any views on that?
Thx
#13
Hi there, hope you're OK in this difficult Covid-19 environment.

I installed OPNsense running on Proxmox on a dedicated machine with 4 NIC.

My home network is as follow (^v are representing links) :

ISP Fiber ONT (public IP)
^v
ISP Router/Wifi 192.168.0.254 (the ISP router is also a Wifi AP)
        ^v LAN1 Wifi 192.168.0.0/24
        ^v WAN OPNsense NIC1 192.168.0.31 (access authorized from private networks)
                  ^v LAN2 OPNsense NIC2 192.168.3.0/24
                            ^v Laptops and other mobile devices
                  ^v DMZ OPNsense NIC3 192.168.2.0/24
                            ^v VM1 Plex 192.168.2.18
                            ^v VM2 Duplicati 192.168.2.16
                            ^v VM3 ...

The situation:
- LAN1 and LAN2 access the Internet without any issue
- LAN2 access the DMZ without any issue
- Issue #1: DMZ can ping Google.com but:
- cannot open a web page, or cannot update my Linux VMs (apt-get does not work, on any of the 3 VM)
- Plex cannot connect to the Internet. The WAN interface denies access with a "default deny rule" that I suppose is because of a floating rule (that I can't delete!)
- Issue #2: LAN1 and Internet cannot access the DMZ (while it should, thru for example port 32400 for Plex)

Illustration of issue #1 for Plex (firewall log; the 86.xx IP is my public address, the xx.0.50 IP is my phone from LAN1, the xx.2.18 is my VM1 from DMZ):
cf. image #1

I have tried everything:
- many tries to NAT and FW rules
- enabling a DMZ on my ISP Router and directing flows to the OPNsense WAN address
- and many, many other things (cleared the states, tried Outbound NAT auto reflection, rebooted, etc.)

Any help very welcomed as I'm (quite) new to firewalls and getting a bit crazy with this!

Below my NAT, Floating rules, WAN, DMZ and LAN settings:
Firewall NAT settings
cf. image #2

Firewall Floating rules
cf. images #3, 4, 5

Firewall WAN settings
cf. image #6

Firewall DMZ settings
cf. image #7

Firewall LAN settings
cf. image #8