Messages

I have the same question.

Both options do the job. Thanks a lot.

Thanks a lot for your reply. I will play with this a little bit and feedback here.

I use OPNsense behind a stateless firewall. I noticed that the source port randomization does not stick to the ephemeral port range (e. g. TCP 32768-65535) but seems to be using anything > 1024 (FreeBSD AFAIK uses 49152-65535 only).  So I was wondering if there is a possibility to set the port range that can be used as ephemeral port range in OPNsense or if I need to disable source port rewriting or open up the whole range (>1024) in the stateless firewall. Thanks for your input.

you are right, "pkg update -q" takes forever and "pkg rquery ..." takes quite long as well. Any idea on how to fix this?

In idle mode there are zero pkg-processes.

If I go to System > Firmware > Status two processes are fired up.

I ran "pkg update -f" but that seems to be fine as well (see attachment).

did a package capture but there is no indication of any dns problems, all queries seem to get resolved and there are no lost/wrong packages

also tried dnsmasq instead of unbound, makes no difference.

I checked that a hundred times but cannot find any mistake. I put DNS-Servers in General and Unbound uses them as forwarders. I also tried not to use unbound for the system.

I installed OPNsense in a Proxmox VM to the best of my knowledge with nothing out of the ordinary (firewall, haproxy and ipsec). However, in this instance I face the issue that the `System: Firmware: Status` page takes forever to load. Well, that is not exactly true since after a reboot it actually loads very quickly and what I would describe as normally. Shortly after a reboot it takes minutes to load the page with this error showing in the logs:

Code Select Expand


configd.py Timeout (120) executing : firmware tiers


If I then proceed to clicking `Check for updates` it again takes very very very long to complete the check or just fail.

Code Select Expand


Fetching changelog information, please wait... fetch: transfer timed out (in the window itself)

Backend log:

Retrieve upgrade progress status (for minutes)

configd.py unable to sendback response [opnsense|||product_tier|||1 opnsense-devel|||product_tier|||1 os-acme-client|||product_tier|||3 os-acme-client-devel|||product_tier|||3 os-apcupsd|||product_tier|||3 os-apcupsd-devel...

view plugin tiers (last entry in the log)


For the rest the system feels fast and snappy and there are no other issues  I can think of/experience.

Does someone have an idea what might make configd.py time out?

I did reinstall the system as well but same issue.

Did you find a solution? In my case I had to remove WireGuard completely. After that everything was back up and running. Spend hours troubleshooting this.

I still have this issue after the recent upgrade to OPNsense 22.10-amd64. Now wg0 did not come up but wg1 did. I thought I was clever by setting up a cronjob to restart WireGuard daily. But apparently this didn't help. So I had to manually restart the service in the dashboard to have wg0 up and running.

This is quite weird, because I do not have this issue on any community installation.

And to answer to Franco: no, no OpenVPN running.

I'm trying to setup IPsec vpn using EAP to authenticate. I tried to follow the guide here: https://wiki.opnsense.org/manual/how-tos/ipsec-rw-srv-eapradius.html but I run into some issues:

• The guide tells me to not select any "Backend for authentication" on "VPN: IPsec: Mobile Clients" however, the GUI does not allow this
• When trying to connect as user I have a "loading EAP_RADIUS method failed" in the logs and the auth request never hits the RADIUS server
• Of course I tested the RADIUS server conf

Does anyone have an idea?

I have the same problem with the latest Business Edition 22.4.2. After reboot only wg0 kind of comes up, meaning handshake is established but zero traffic through the tunnel. After manually restarting the service both the interfaces wg0 and wg1 come up and start working.

Since upgrading to 22.4 I'm experiencing the exact same problem. Did you find a solution?

I just restarted the wireguard-go service from dashboard and it started working. Maybe the service does not initialize correctly (noticed that wg1 was missing before the restart)?