Messages

hi all, searching for workaround via physical interface for Zenarmor visibility?

I'm running OPNsense with Zenarmor (Sensei) and using multiple OpenVPN instances (TUN interfaces). As widely documented, Netmap does not support TUN interfaces, which means Zenarmor can't see or filter any traffic coming through those VPNs.

I understand this is a FreeBSD/Netmap limitation, not a Zenarmor issue.

I attempted to bridge the OpenVPN TUN interface with a physical VLAN interface to force traffic to flow through a Netmap-visible interface, hoping Zenarmor could then perform packet inspection. But as expected, TUN interfaces can't be bridged due to the lack of Ethernet framing.

I then tried routing traffic from the OpenVPN subnet (e.g. 172.17.2.0/24) through vlan with outbound NAT and firewall rules, but Zenarmor still doesn't pick up this traffic.

My question:

Is there any known workaround (even dirty or semi-supported) that could make Zenarmor see and filter traffic coming from OpenVPN (TUN), perhaps by routing or redirecting it through a physical interface that Netmap supports? Or is this fundamentally impossible without switching to WireGuard or using TAP (which has its own limitations in OPNsense)?

Any ideas, tricks, or experiences are welcome.

Thanks in advance.

same here, captive not working in a production. As a authentication I'm using external radius server, where the user get successfully negotiated.

Code Select Expand

Auth: (38) Login OK: [captive.user] (from client OPNsense port 0 cli XX:XX:XX:XX:XX) - VLAN ID: XXXX >> You're User (from client opnsense.ip)
Anyway, Captive says login failed.

ok, at Network/Headers was the answer for correct endpoint.

Code Select Expand

{OPNSENSE_URL}/api/openvpn/client_overwrites/del/{uuid}
thanks again!

Update: Got it working – here's where I went wrong and what the fix looks like, thanks again for the guide!

I was doing Incorrect JSON structure – The API expects a top-level key called "cso", like this:

Code Select Expand

{
  "cso": {
    "common_name": "...",
    ...
  }
}
And wrong servers field – You must provide the UUID of the OpenVPN instance (not its name or description).
You can retrieve these UUIDs by calling:

Code Select Expand

curl -X POST 'https://your.opnsense/api/openvpn/instances/search' ...
Have another Q, what about removing CSO. By inspecting API while removing CSO i can not see the correct endpoint. Im trying it with:

Code Select Expand

curl -X POST 'https://my.opnsense.host/api/openvpn/client_overwrites/del' \
-u 'APIKEY:APISECRET' \
-H 'accept: application/json' \
-H 'content-type: application/json' \
--data-raw '{"uuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}' \
--insecure
and getting

Code Select Expand

{"errorMessage":"Endpoint not found"}

Follow-up: Still getting {"result":"failed"} despite updated syntax and values

I tried adjusting the request syntax after reviewing the updated API docs and checking existing CSO entries via the search endpoint.

Here's the command I used:

Code Select Expand

curl -X POST 'https://my.opnsense.host/api/openvpn/client_overwrites/add' \
-u 'APIKEY:APISECRET' \
-H 'accept: application/json' \
-H 'content-type: application/json' \
--data-raw '{
  "common_name": "test.user",
  "description": "IP-Reservation",
  "servers": "OVPN-Proton-IN (52002 / UDP)",
  "tunnel_network": "172.17.2.107/32"
}' \
--insecure
Before sending the request, I verified the servers value by listing current CSOs with:

Code Select Expand

curl -X POST 'https://my.opnsense.host/api/openvpn/client_overwrites/search' \
-u 'APIKEY:APISECRET' \
-H 'accept: application/json' \
-H 'content-type: application/json' \
--data-raw '{}' \
--insecure | jq '.rows[] | select(.servers | startswith("OVPN"))'
Which returned:

Code Select Expand

{
  "uuid": "298345e2-da80-45a4-ad65-295670b148d1",
{
  "uuid": "298345e2-da80-45a4-ad65-295670b148d1",
  "enabled": "1",
  "servers": "OVPN-Proton-IN (52002 / UDP)",
  "common_name": "howno",
  "block": "0",
  "push_reset": "0",
  "tunnel_network": "",
  "tunnel_networkv6": "",
  "local_networks": "",
  "remote_networks": "",
  "route_gateway": "",
  "redirect_gateway": "",
  "register_dns": "0",
  "dns_domain": "",
  "dns_domain_search": "",
  "dns_servers": "",
  "ntp_servers": "",
  "wins_servers": "",
  "description": ""
}
}
I updated the request payload accordingly, but unfortunately, the API still responds with

Code Select Expand

{"result":"failed"}

Hi again, and thanks for quick reply!
After several tests and with help from search and instances/search API calls, I believe I've finally figured out why my CSO API calls keep returning

Code Select Expand

{"result":"failed"}.
Root cause: missing name field in OpenVPN instances?

The API endpoint client_overwrites/add expects server_list to include internal OpenVPN instance names, not just their descriptions. These names are normally set internally when creating an instance, but in my case, all instances returned:

Code Select Expand

"name": null,
"description": "OVPN-Proton-IN"
This explains why the CSO can't be added – the instance has no valid internal name, and the API doesn't know where to attach the override.

Code Select Expand

curl -X POST 'https://my.opnsense/api/openvpn/instances/search' \
-u 'APIKEY:APISECRET' \
-H 'accept: application/json' \
-H 'content-type: application/json' \
--data-raw '{}' \
--insecure | jq '.rows[] | {name, description}'

Am I wrong?

Hi,
I'm trying to add a Client Specific Override (CSO) using the OPNsense API and curl, but I keep getting the response {"result":"failed"}.

I've tried various payload formats, using this OPNsense API doc as a base. Since I couldn't find a full schema for OPNsense CSO, I borrowed the format from the pf API here: https://pfrest.org/api-docs/#/VPN/postVPNOpenVPNCSOEndpoint

Here's one example I tested:

Code Select Expand

curl -v -k --location https://my.opnsense.host/api/openvpn/client_overwrites/add \
-u "key:secret" \
--header 'Content-Type: application/json' \
--data '{
  "common_name": "test.user",
  "disable": false,
  "block": false,
  "description": "IP-Reservation",
  "server_list": ["OVPN-Proton-IN"],
  "tunnel_network": "172.17.2.107/24"
}'

I also tried with escaping quotes and with other field combinations, but always got the same result.

The API call completes successfully with HTTP 200, but the body returns:

Code Select Expand

{"result":"failed"}
full output:

Code Select Expand

* Host my.opnsense.host:443 was resolved.
* IPv6: (none)
* IPv4: 192.0.2.123
*   Trying 192.0.2.123:443...
* Connected to your.opnsense.host (192.0.2.123) port 443
* ALPN: curl offers h2,http/1.1
* (TLS handshake and certificate ok)
* using HTTP/2
* Server auth using Basic with user '[REDACTED]'
> POST /api/openvpn/client_overwrites/add HTTP/2
> Host: your.opnsense.host
> Authorization: Basic [REDACTED]
> User-Agent: curl/8.7.1
> Accept: */*
> Content-Type: application/json
> Content-Length: 213
>
* upload completely sent off: 213 bytes
< HTTP/2 200
< content-type: application/json; charset=UTF-8
< server: OPNsense
< date: Fri, 11 Apr 2025 17:06:49 GMT
< set-cookie: PHPSESSID=[REDACTED]; path=/; secure; HttpOnly; SameSite=Lax
<
{"result":"failed"}
Any idea what I might be doing wrong? Is the tunnel_network key invalid in OPNsense? What's the correct schema for the CSO add endpoint?

Thanks!

hi, i can start new topic, anyway, before I'll try to ask here.
I'm trying to use API for adding new CSO.

The client has made a successful request. as code 200 is the answer, but at the end of response is {"result":"failed"}.

here is the curl command:

Code Select Expand

curl -v -k -u "key":"secret" \
-H 'Content-Type: application/json' \
-X POST "https://firewall.ip/api/openvpn/client_overwrites/add" \
-d '{"enabled": true, "common_name": "test.user", "server_list": ["OVPN-IN (52002 / UDP)"]}'
could someone help?

Sorry about that, I just wanted to be as clear as possible, and... At least now we know.

Same thing, being called different ways. From reading the thread "there are at least two ways to assign a segment tag to an interface. Either directly on the interface in the virtualizer or by using a bridge and tagging the segment directly in KVM."

- directly on the interface in the virtualizer =  let OPNsense itself tag the packets and remove the VLAN settings from the virtual interface

and of course the expected "opposite":

- "KVM level" = VLAN tagging by the hypervisor (KVM in this case) and OPN blissfully unaware

This was just a answer for @viragomann, didn't want to get much into it. This does not have anything to do with my issue because firewall can see the VLAN and is accessible, just wanted to be clear with the whole setup. Anyway, my problem is still ongoing and have no idea what I'm doing wrong.

What's a segment tag?

vlan, network segmentation

[Proxmox level]

Can you discribe this more clearly, please?

Certainly, there are at least two ways to assign a segment tag to an interface. Either directly on the interface in the virtualizer or by using a bridge and tagging the segment directly in KVM.

Proxmox level:

Code Select Expand

/etc/pve/nodes/pve/qemu-server/XXXXX.conf
net0: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbr0,tag=10

Code Select Expand

dc01 ~
> # nmcli connection show
NAME    UUID                                  TYPE      DEVICE
enp6sXX  XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX  ethernet  enp6sXX
KVM level:

Code Select Expand

/etc/pve/nodes/pve/qemu-server/XXXXX.conf
net0: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbr0

Code Select Expand

> # nmcli connection add type vlan con-name vlan0.10 ifname vlan0.10 dev enp6sXX id 10

> # nmcli device status
DEVICE      TYPE      STATE                  CONNECTION
vlan0.10    vlan      connected              vlan0.10


Code Select Expand

> # nmcli connection show
NAME        UUID                                  TYPE      DEVICE
vlan0.10    XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX  vlan      vlan0.10

This might indicate an asymmetric routing issue.

Run a packet capture on the client side Interface and sniff the DNS traffic to see, what's really going on.

Will try later today

Hi and thanks for reply

Is the alias of the type "hosts"?

Yes it is

Is this the correct interface?
This one, the clients are connected to?

This is also correct, iface has a static IP and kea is serving dhcp on that segment.

Did you try to explicitly set the pool options to "round robin"?

yes, round robin with sticky address and also the default option, what, based on the docu, "round robin" is

--

Also would be good to mention that once my DNS server iface is tagged at the Proxmox level, it is working.
Once I tag the segment whit-in the KVM it's acting as described reply from unexpected source.
Proxmox's Open vSwitch is set as simple L2, so L3 routing is only OPNsense doing.

I tested bypassing OPNsense and configured L3 on the switch, and everything started working

Whatever level i tag the iface this is working

Hello,

I'm having an issue with my internal DNS running on Samba AD, which is in a different segment than the queried DNS servers.

Code Select Expand

nslookup nic.cz
;; reply from unexpected source: 10.10.0.11#53, expected 10.10.0.12#53
;; reply from unexpected source: 10.10.0.11#53, expected 10.10.0.13#53
Server: 10.10.0.11
Address: 10.10.0.11#53
I have configured port forwarding in OPNsense according to this guide, but instead of querying 127.0.0.1, I use a host alias "DNS-Services" that includes my internal Samba DNS servers (10.10.0.11, 10.10.0.12, 10.10.0.13).

Port Forwarding Settings:
   •   Interface: vlan0.10
   •   Protocol: TCP/UDP
   •   Destination / Invert: Checked
   •   Destination: vlan0.10 net
   •   Destination Port: DNS
   •   Redirect target IP: DNS-Services
   •   Redirect target port: DNS
   •   NAT reflection: Disabled

I tested bypassing OPNsense and configured L3 on the switch, and everything started working. This makes me confident that the issue is on the firewall.

Could you point me in the right direction and help me identify where I'm making a mistake?

I'm back, templates downloading is working again so the patch helped but issue with redirecting is still ongoing.
After day of testing and troubleshooting the redirection issue, I haven't been able to find a solution. However, I can share my observations:

   •   Captive Portal is running and can be manually accessed via https://captive.domain.name:8000, certs are ok.
   •   After connecting to the network, the login page does not appear automatically – the user must manually enter a URL to be redirected.
   •   Both HTTP and HTTPS behave the same way, switching Captive Portal to pure HTTP does not solve the issue.
   •   Testing with http://captive.apple.com only works once
           •   The first time I enter this URL, I am redirected to the Captive Portal.
           •   If I enter it again (without restarting the client), no redirection occurs.
   •   Entering the same address twice in a row does not return the user to the Captive Portal.

Any idea?