Messages

I have my RADIUS server set to automatically create users. This works fine, except the user is created with a shell of /usr/sbin/nologin Is there a way to make this something different so a new user can log in via SSH without first having to log into the web UI and change the shell?

The reason I say it's only kind of working is that when I try logging in with the user, I get the error: "No page assigned to this user! Click here to log out."

I finally got this working. Pro tip: don't copy an existing rule. Even if all the settings look correct, it doesn't work until the rule is created.

I finally got the same error as you. On the NPS policy Settings tab, instead of Class = admins, try Class = CN=admins. This worked for me.

hm, I removed the User Groups condition and re-added it and now the NPS log shows access granted, but my OPNsense tester still shows failed. I think it's not understanding the server's response. The System General log shows "Radius unexpected response:"

You got further than I did. Did you add any RADIUS attributes to your network policy? I can't get my authentication requests from OPNsense to match my policy, and I'm using the same two conditions that are working on a couple of Juniper and Arista policies (User Groups and Client Friendly Name).

I discovered another pass rule on the ingress interface that was passing the packets in question, so they never matched the first rule. That explains how they were caught by the egress rule on the WAN, which did its job.

I can make the first rule quick and move it to the bottom of the every interface's ruleset, but this is less elegant and leaves two questions unanswered.

• How can the first rule operate on a packet at egress before the second rule operates on the same packet at ingress?
• Why are some packets dropped by the second rule while others are not? I have verified this by enabling logging on the second rule.

OPNsense 24.7.7

This firewall host has a WAN interface (lagg0_vlan17) with a publicly routable IPv4 address and multiple LAN interfaces. I created a floating rule to prevent packets with rfc5735 (local and invalid) destination addresses from being leaked on to the internet. I also created an outbound rule on the WAN as a last-resort catch-all rule for the same purpose. These two rules look like this:

Code Select Expand

block return in inet from any to <rfc5735> label "c66bd7ebe022fedb2fdd2d7bdfbf7ee5"
block drop out log quick on lagg0_vlan17 inet from any to <rfc5735> label "f8905c704b9481e346fca8eebfa98578"

To my surprise, I'm seeing packets logged by the second rule. I believed that packets would be evaluated against 'in' rules as they entered an interface, and against 'out' rules as they exited an interface. If this assumption is correct, then only packets originating from the firewall itself should match the second rule, as any packets from local hosts should have matched the first rule at ingress and been dropped. Yet I'm seeing packets in the log that did not originate from the firewall. So what have I got wrong?

The solution turned out to be pretty simple:

Code Select Expand

location / {
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://172.31.0.1;
        }

The live widgets are working with these two extra options.

The only thing that comes to mind is an IP address conflict, but the chances of it co-occuring on multiple interfaces seems remote. Are you able to look at the console while the network interfaces stop responding? It might be interesting to watch top or tcpdump during an outage.

I set up an nginx reverse proxy to handle requests to OPNsense's web UI. This appears to work well so far, except that the CPU, Firewall and Traffic graphs on the dashboard don't display any data. This isn't my area of expertise, so can anyone recommend any modifications to my nginx config to get these graphs to display properly?

Code Select Expand

server {
listen 80;
server_name opnsense.example.org;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name opnsense.example.org;

location / {
proxy_pass http://172.31.0.1;
}
}

I was trying to work with a host that was temporarily moved from another network. Re-IPing the host broke some ACLs so I was trying to preserve its IP address, and adding an interface to OPNsense wasn't an option. I was able to connect to the host and update the ACls to get things working.

Ok, that makes sense. Thank you.

OPNsense 24.7 DVD/ISO installer on Vmware 7.0U2 v19 virtual machine

I created a new VM and booted it from the installer ISO in UEFI mode. It boots fine, then I log in as "installer". It asks me on which device to install OPNsense, and I choose a ZFS install type "stripe". I choose the only device available, da0, which is an 8-GB virtual disk that I created as new with the VM. It warns me that the disk will be wiped and I select YES. Then I get the attached error (also quoted in subject).

Some web searches didn't turn up much, so I shut down the VM, increased the disk size to 10 GB and tried again. This time the installer succedded, but 'zpool list' shows that ZROOT is only 2 GB. What do I have to do to get the installer to use the whole virtual disk?

I have an OPNsense pair configured in HA. I have an existing subnet with a CARP IP and ISC DHCP server running:

Code Select Expand

Interface: opt14
CARP address: 10.13.4.1/24
VHID: 134
DHCP Range: 10.13.4.100 - 10.13.4.199

So far this works as expected and the DHCP server serves leases on the primary subnet.

I need to run a second DHCP pool on this same interface but a different subnet. I created a VIP on the new subnet using the same VHID as the CARP interface:

Code Select Expand

Interface: opt14
VIP: 172.31.0.254/24
VHID: 134

Then I added a secondary pool to the DHCP server on this interface:

Code Select Expand

Range: 172.31.0.16 - 172.31.0.32

As soon as I save the change, the DHCP service stops and the log shows:

bad range, address 172.31.0.16 not in subnet 10.13.4.0 netmask 255.255.255.0

What am I doing wrong?
Is there a way to achieve what I'm trying to do?

I think I found them in /conf/backup/.