Messages

To add my tuppence worth, it is very annoying when configuring things like IOT devices or some so-called smart devices, where you have to let it get assigned a lease, then try to change it to the address you actually want, particularly if you want a static reservation. Some of these devices do not display a MAC so you have no choice but to allow a DHCP discovery first.  It plays havoc with my Homeassistant and expensive WiZ bulbs, for example.

Fake or not, I hope something is sorted in the GUI.

Dnsmasq DHCP on new guest interface receives Discover but sends no Offer until a manual dnsmasq override is added

## Summary

I ran into what looks like a Dnsmasq/OPNsense edge case while adding a new guest Wi-Fi interface.

A new guest subnet/interface was created and DHCP was enabled in the OPNsense GUI. The network path itself was confirmed working:

* client DHCP Discover packets reached the correct guest interface
* `dnsmasq` was running and listening on UDP 67
* the generated `dnsmasq.conf` already contained a DHCP range for the new interface

Despite that, no `DHCPOFFER` or `DHCPACK` was sent.

The issue was only resolved after adding a manual override file under:

```text id="y967c9"
/usr/local/etc/dnsmasq.conf.d/
```

with an explicit interface-scoped DHCP definition for the guest interface, then restarting `dnsmasq`.

After that, DHCP immediately worked and guest clients could:

* obtain leases
* resolve DNS
* access the internet
* remain isolated from internal RFC1918 networks

## What makes this look like a bug / edge case

Before the workaround:

* DHCP Discover packets were definitely arriving on the intended guest interface
* the interface was up and addressed correctly
* the generated `dnsmasq.conf` already had a DHCP range for that interface
* but `dnsmasq` never sent an Offer

After adding an explicit manual override for that interface:

* `DHCPOFFER`
* `DHCPREQUEST`
* `DHCPACK`

all appeared immediately.

So it seems the GUI-generated scope existed, but was not actually sufficient for live DHCP service on that new interface.

## Workaround that fixed it

A custom dnsmasq drop-in file was added with explicit interface binding plus router/DNS options for the guest subnet, followed by:

```sh id="c8b9xw"
configctl dnsmasq restart
```

## Question

Has anyone seen this before with newly added interfaces/VLAN-backed guest networks in OPNsense using dnsmasq?

I have a fuller write-up with config excerpts and before/after packet captures if needed, but I wanted to start with a cleaner summary first in case this is already a known issue.

I feel silly now. Somehow I forgot that you have to add each new interface scoped for to the list in: Services: Dnsmasq DNS & DHCP

Hi
I'm trying to set up OPNsense to request and manage renewals of SSL certs.  The server should work together with a separate HAProxy server, which should handle the receipt of cert uploads for client machines.
My problem is I can't seem to get certificate (.PEM) files to upload successfully from OPNsense using remote SFTP/SSH.

Using a small script:

Code Select Expand

mkdir -p /root/testcert
cd /root/testcert

# Self-signed test cert (doesn't matter what it is)
openssl req -x509 -nodes -newkey rsa:2048 \
  -keyout test.key \
  -out test.crt \
  -subj "/CN=mydomain.com" \
  -days 1

cat test.crt test.key > test.pem

Now push it to HAProxy:

Code Select Expand

cat /root/testcert/test.pem | \
  ssh -i /var/etc/acme-client/sftp-config/id.ed25519 \
      -p 22 \
      acme-certpusher@192.168.99.252 \
      "mydomain.com"




The 2 errors I keep getting are:

1. bash: line 1: mydomain.com: command not found

2. It seems OPNsense ACME automation (type "SSH remote command") does not pipe any certificate data so I end up with:

Code Select Expand

Nov 21 12:54:36 mydomain acme-certpush[142212]: Fri Nov 21 12:54:36 GMT 2025 Starting certpush for domain/command: mydomain.com
Nov 21 12:54:36 mydomain acme-certpush[142220]: PEM missing certificate block
The indication is that I'm not getting the fullchain.pem, which is supposed to end up in /etc/haproxy/certs/domainx/.
On checking OPNsense, I can see the fullchain.cer, the mydomaain.com/cer .csr & .key , sitting in /var/etc/acme-client/cert-home/12345678901112.84768251/mydomain.com

Can anyone tell me if this plan, of running separate HAProxy instead of HAProxy running on OPNsense, will work?

Hi

It seems OPNsense 25x has changed many things.
I have a setup where OPNsense is a VM and HAProxy is also a VM.  I want OPNsense (on 10.10.20.10) to handle certificate requests via Cloudflare DNS-01 and then upload the certificate obtained to HAProxy on 10.10.20.20 using OPNsense ACME client's Automation workflow.
I would like to assign a user on OPNsense (with nologin if possible), say cert-bringer, who authenticates with its SSH key.

When I set this up by giving HAProxy cert-bringer's public key, I keep getting errors like this: Permission denied (publickey).

Do I need to create an OPNsense user for this to work?
If so, what access rights do I give that user?

If not, then how can I achieve this goal?

bernie

Just a couple of things:

The rule looks right. Your profile could be odd... Maybe ufw status verbose might be more revealing than ufw status numbered.

AFAIK, ufw is really just a management front-end for iptables. I'm pretty sure systemctl stop ufw won't disable the active rule-set, nor will systemctl disable ufw until after a reboot. It's possible that there's some outbound filtering happening so maybe try again after issuing ufw disable on both machines...
[\quote]

Yes systemctl disable ufw followed by systemctl stop ufw works.

The rule does look correct. You may want to add logging to see what happens to incoming connections:

Code Select Expand

ufw allow in log proto tcp from 192.168.0.212 to any port ldaps
[\quote]

Cheers. Done!

IIRC, there is an OpenLDAP profile (which you can confirm by issuing ufw app list), so you could also use:

Code Select Expand

ufw allow in log proto tcp from 192.168.0.212 to any app "OpenLDAP LDAPS"
[\quote]

Will look into that.

I don't think I have ever commissioned an LDAP server with port 389/tcp closed. Perhaps there is a dependency and you need both open (I think this unlikely but possible)...

I think port 389 is unsecured unless used with tls  and is mostly used for MS AD but it seems to be enable here on the mail/ldaps server anyway. I think perhaps it's there for outlook/AD compatibility.

Finally, in relation to your concerns regarding name resolution, you could use an entry at /etc/hosts while troubleshooting. Perhaps reboot afterwards to be sure no lingering resolver issues exist.

Do you mean entry in the host file (like 192.168.0.212 cloud3) on ldaps host and vice versa?

Thank you Benyamin.

It's great to have you helping to confirm or clarify my thinking and steps in this troubleshoot.

Indeed the ports are open and using netcat returns: connected to 192.168.0.213 636 port [tcp/*] succeeded!

ldap/s is not aalowed on the WAN and as both VMs are on the same LAN subnet ldap has been restricted to  open and listening from 192.168.0.213 to recieve only from 192.168.0.212.
The ufw rule is:
ufw allow proto tcp from 192.168.0.212 to any port ldaps

ufw status shows below in the attachment.
I agree that as they are on the same network OPNsense shouldn't be interfering and I can see no rules that could prevent it. I tried your suggestion to turn ufw of on both machines but the result is the same though I used
systemctl stop ufw.  I then tried sytemctl disable ufw but again the result is no connection.

At this stage I'm beginning to suspect the ldap script attempting to contact and register with the mail server ldap service may be trying to resolve the external DNS FQDN IP rather than the internal IP. As I dont want this to happen I may need a way to change that.

Hi
Thanks for the pointers.

When I issue  ~# lsof -i -P
on the mailserver with the ldap database I get 3 ldap readings

slapd 4242 openldap   8u IPv4 33726 0t0 TCP localhost.localdomain:389 (listen)
slapd 4242 openldap   9u IPv4 33728 0t0 TCP *:636 (listen)
slapd 4242 openldap 10u IPv4 33729 0t0 TCP *:636 (listen)

So it seems the ldaps port is open and listening.

As far as the network is concerned  thanks for the warning on the IP's but they are not my real ones.
I have and internal network lan of the range 192.168.0.0/24. Both mail and nextcloud VMs are no that lan and the ufw firewall on the mail/ldaps VM is set allow ldaps from anywhere the ip of the nextcloud/ldap client.

It is true I have one network card with an public IP set on VMBR0
The VMs access the world through VMBR1 using the separate mac address ordered specially for the second IP address bought for proxmox virtualization using a routed configuration similar to :

iface lo inet loopback

iface enp35s0 inet manual
        up route add -net X.X.X.X/X netmask 255.255.255.X gw X.X.X.X dev
enp35s0
# route X.X.X.X./X via X.X.X.X

auto vmbr0
iface vmbr0 inet static
        address <PUBLIC-IP/29>
        gateway <TO PUBLIC-GW>
        bridge-ports enp35s0
        bridge-stp off
        bridge-fd 0
        pointtopoint <PUBLIC-GW>
        bridge_hello 2
        bridge_maxage 12

auto vmbr101
iface vmbr101 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0
#OPNSense_LAN1

auto vmbr100
iface vmbr100 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0
#OPNSense_LAN0

auto vmbr1
iface vmbr1 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0
#OPNSense_WAN0 Assigned to MAC Address of 2nd PUBLIC-IP


I can't see any reason other than the incomplete setting in OPNsense.

My setup is a baremetal AMD ryzen 7 wit single nic with IP 1 for Public/internet connection + additional IP 2 and MAC address for  virtualization.This is configured as a debian 11 Linux server with proxmox and 2 Ubuntu 20.04LTS VM's for Mail-in-a-box_LDAP (VM1), Cloud-in-a-Box (Nextcloud) (VM2) and a MX Linux (VM3) Workstation for maintenance/testing.

The MIAB_LDAP uses and serves ldap over port 636 to mail users and is designed to provide the CIAB (Nextcloud) with the same ldaps services for nextcloud users so that the two services can usethe same credentials for users on both mail and collaboration/storage services.

The 4th VM in this setup is a OPNsense server with version 20.19. It serves as the gateway and firewall and once working fully may also provide proxy and automated certification services through Let's Encrypt.
I can access the internet through all VM's and the Host. But ldaps will not connect between the VM1 & VM2

I am now frustrated and tired after 3 days of failure.  There seems no reason for this failure. the default layout is as below in the attachment:

Help :'(  :confused:

:confused: