Messages

The same errors appear when running netstat and are also visible in Interfaces > Diagnostics > Netstat. I feel there's a strong possibility this is just cosmetic, as there are many reports online about how DCO reports interface stats differently from TUN mode, which may result in a higher error count. But seeing those errors tick up just makes me feel as if something is misconfigured on my end...

Hello,

I have an OpenVPN server running that runs perfectly on opnsense in TUN mode. When I switch to DCO mode, it still works perfectly and is significantly faster, but in the OPNsense dashboard's "Interface Statistics" widget, i see "in" errors continually ticking up as soon as a client connects to the server. The errors stop when no clients are connected and if I switch back to TUN mode, I get no errors at all, whether or not clients are connected to the server.

The OpenVPN logs show no errors at all and the connection is stable and fast in DCO mode.

Anyone else experience this? Is it just cosmetic?

Any insights would be appreciated.

Thanks!

Awesome, thanks!

Thanks, Franco.

Hopefully it gets fixed because the file gets regenerated whenever you make changes. Not sure it'll survive a reboot either - haven't tried yet.

Cheers

 

So, it turns out the culprit is in the file: /usr/local/etc/raddb/users. At the bottom of the file, there is:

DEFAULT Auth-Type := Accept
       Framed-Protocol = PPP

From what I gather this appears to break EAP authentication. Commenting the lines out fixes everything.

Now, I'd be inclined to think it's a bug but I have another machine running OPNsense with FreeRadius and on that box, everything works without commenting out those lines... Only difference is that one box (the one that had the issue) is using EAP-TLS, whereas the other box is using EAP-TTLS.

Anyone have any idea what might be happening?

Hello,

After the 25.7.8 update, I can no longer connect to WiFi. I'm using freeradius and all my devices now state "Unable to connect to [WiFi Network]" when I attempt to connect. Was connected just before the update. Logs don't show any errors. All I get is: Auth: (11) Login OK: [USERNAME/<via Auth-Type = Accept>] (from client WLAN port 0 cli MAC ADDRESS) over and over again, but my client never connects or gets an IP address.

Anyone else encounter this?

Cheers

Thanks for taking the time to answer my questions.

If anyone is successfully using 'no-resolv' in DNSmasq, I'd love to hear from you.

Cheers

Thanks again for the reply.

The docs appear to imply that DNSmasq is used for dhcp. I'm using KEA at the moment and would really rather not go through transferring all my reservations again.

Do you happen to know how to manually restrict the scope of server= to have dnsmasq still perform hostname resolution according to the host overrides list?

Thanks

Thanks for replying. I suspect you're correct.

However, I've tried defining local domains (local=/local.domain.1/ local=/local.domain.2/ - on separate lines). I've tried inserting bogus-priv. I've tried defining host overrides in the config (address=/local.domain.1/192.168.x.x). Whatever I do, local hostname resolution breaks.

I'm not a particularly advanced user regarding DNS, would you happen to know how to properly limit the scope of server=?

Cheers

Is anyone using 'no-resolv' without any side effects?

Hello,

I'm having a strange (I think) issue with DNSmasq. If I set it up to use the servers listed in System/Settings/General, everything works perfectly: I can go out to the internet and resolve local hostnames (as defined by the host overrides).

However, if I create a custom .conf file in /usr/local/etc/dnsmasq.conf.d/ with:

Code Select Expand

no-resolv
server=<dns server ip>
(using the same server that I would put in System/Settings/General), I can still go out to the internet but I lose local hostname resolution despite host overrides being defined.

Is this expected behavior?

Running 25.1.7_4.

Thanks

Hello,

I have a working road warrior WireGuard setup on my OPNsense box. It works well. However, if I do a sustained download when connected to the VPN (that saturates the connection), like a speed test, I can see packet loss on the WireGuard interface, in Interfaces > Diagnostics > Netstat. It's not major, usually 2000 to 3000 packets dropped out of roughly 900000 to 1000000 packets. So we're talking 0.22% or 0.33%. If I don't run a speed test, I get no packet loss at all.

I also have a road warrior IPsec setup on the same box and running a speed test while connected to IPsec does not incur any packet loss.

Is there something about WireGuard that makes it more prone to packet loss than other VPN protocols? I'm pretty sure this isn't a MTU/MSS issue - they've both been lowered to accommodate WireGuard, and were it that, I'd expect to see packet loss all the time, not just during sustained downloads/speed tests.

I'm trying to figure out if there's an issue with my WireGuard setup or if this is normal.

Any insights are welcome.

Thanks

Update: If I create my connection on the mac (without a profile) it connects. It sends exactly the same proposals as with the profile, so I don't understand why it works. Something appears to have changed in OPNsense's IPSec implementation that doesn't play nice with profiles. Even creating a standard profile with the same values as the connection created in the macOS UI fails to connect.

I want to use the profile because I specify options that are not available in the UI.

Again, any help would be appreciated. And I'm not expecting a "just do this, bro" or "tick this box" response. I guess I'm asking if anything has changed with IPSec in OPNsense since 24.7.4_1. Nothing changed on my end apart from the update.

Cheers

UPDATE: Saved and restored a config (i.e. the exact same settings the box was running prior to restoring) and now it works... Dunno what to say... Maybe something silently went wrong with the update and restoring the config fixed it? I guess there are some things Man is just not meant to know...

Hello,

I'm having issues with IPSec and macOS since the update to 24.7.4_1. Prior to the update, everything was working fine. Now, I can no longer connect from macOS. macOS is running the same version as before the 24.7.4_1 update.

I use a configuration profile (.mobileconfig) to setup my IKEv2 connection on macOS. And I'm aware there's a bug in macOS Sonoma, where it ignores the values you set in the profile for proposals and rekey time. Regardless what you configure in the profile, macOS will send the following proposals to the server:

2024-09-20T22:40:56-04:00   Informational   charon   11[CFG] <5> received proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048

So I made sure the server supported at least one of those:

11[CFG] <5> configured proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/ECP_521, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256

Prior to 24.7.4_1, the profile and connection worked just fine. Since 24.7.4_1, I can no longer connect. I've attached a picture of the logs. Happy to provide more logs if needed.



I also have a pfSense box that runs the same services and has IPSec setup with the same values and it connects just fine. But I don't want to go back to pfSense - I'm an OPNsense guy now :-)

Anybody else running into issues like this? Anyone have any ideas? Was IPSec changed in 24.7.4_1?

Any help would be appreciated. Thanks.

Hello,

Has anyone managed to configure an IPsec tunnel using eap-tls in the new "Connections" tab? There is no tutorial for this setup in the docs, only a legacy example using the old UI. I've tried adapting the tutorial for eap-mschapv2 that exists for the Connections tab to use eap-tls but it fails to connect, always.

I'm wondering if it's supported at this time.

Thanks.