Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Darkvader

#1
26.7 Series / Re: OpenVPN fd=8,Code=13 error
August 15, 2026, 05:41:40 PM
I've just spent a little more time getting things set up and it honestly looks like openvpn is just completely borked in my setup for some reason, I'm really scratching my head on this.

For a few more details:
Hardware wise opnsense is installed in a proxmox 9 VM that has 2x X86-64-V2-AES cores on a q35 platform, 3GB ram and 6x NICS(5 Intel Passed through to the vm ala SR-IOV and 1x Paravirtualised (for a management interface with proxmox))

The physical chip on the board is an Intel(R) Celeron(R) CPU 3865U @ 1.80GHz quite old but i shouldn't expect any massive issues in how sudden it stopped working.

So far i've reinstalled from scratch twice, updated the hypervisor and made sure the system is actually communicating properly with the outside world.

also, disabling the firewall rule to OpenVPN so it doesn't receive connection attempts stops the messages (and will get caught in the firewall log) so the overall handshake seems to be working but the openvpn process just can't move past it.

It actually looks a little like the OpenVPN server process doesn't have any permissions allocated to it. I was thinking i could try and see if maybe adding perms or elevating the process would help but I'm not skilled with FreeBSD.

Any suggestions from this point?
#2
26.7 Series / Re: OpenVPN fd=8,Code=13 error
August 13, 2026, 04:59:59 PM
26.1.3 was where it was set up and worked fine. I had the system get a bit stuck between versions for a little while (my 5g connection never seems to finish an update) so latest packages were installed even with the .3 kernel and base, I then did a manual upgrade to 26.1.11 where it stopped working, then in re-imaging went to 26.7 which also doesn't work.

I can send you my config if you'd like.
#3
26.7 Series / OpenVPN fd=8,Code=13 error
August 13, 2026, 01:02:46 PM
Hello, I would like some help figuring out why I have this particular error on a previously fully working openvpn config.

2026-08-13T10:50:47 Error openvpn_server1 Connection Attempt write UDPv4: Permission denied (fd=8,code=13)
this line will fill the openvpn server logs and no clients can connect. I've spent the last hour re-creating the install and manually transferring the openvpn config over, only for it to do the same thing on the new install.
all instances are affected too.

over the last week, this config worked flawlessly but after an update it seems to be completely borked. I also can't seem to get it working by changing options around, it just seems to give the same error constantly now.

please help.
#4
Hi Everyone, a bit of a weird question.

My modem does dynamic Local and public DHCP allocation for the WAN address and opnsense gets a bit in a twist with it.

What it does is when the modem is powered on the device connected to it (opnsense here) is given a local address (192.168.100.x in this case) and then when the modem itself is allocated a public address it will do a bit of a handshake then do a quick swap so the opnsense box has the public IP and can communicate directly.

Where it gets a bit funky is that Opnsense regularly thinks there's a conflict with arp, will start ignoring DHCP addresses and then will lose all WAN connectivity.

here's a line from the log:
<3>[67488] arp: 4x:8x:cx:8x:3x:7x is using my IP address 18x.2x.1x.5x on igb0!that MAC is the modems MAC address, so it's successfully telling opnsense the public ip, but opnsense thinks there's something wrong and will refuse to use it.
Is there a way to turn off the arp ip collision stuff, it's seriously causing a headache with this handover.

the way i've worked around it for now is to set the WAN address staically to a 192.168.100.x address, which isn't ideal as it now means i'm double NAT'ed.
#5
Is there any way i can help with diagnosing the issue? I can do a packet capture of a download. It's just very strange, there's nothing else i use that is affected in this way.
#6
That's what doesn't make sense, changing the location doesn't remedy the issue but when i connect through the vpn to a different location that SAME url works as expected. also, it's strange how the server will report a size for the file, but then fail to serve it completely.
I've tried the Default Repo, the LeaseWeb San Fransisco (US) server, The University of Kent Server (UK) server and The Opnsense server within the Netherlands. All will fail.
There's obviously something funky going on.

My hardware for reference is:
- D-Link DWP-1010 Rev B 5G&LTE Modem on the Three Network
- Chinese mini computer with 6 nics that's running Proxmox with the Opnsense software as a vm. That's also configured to use the 5 intel nics directly with PCI passthrough.

however i doubt this is a hardware issue.
#7
Hello,

I'm having an uphill battle getting my opnsense installation updated. I've scoured the forum and discovered the curl/fetch method to update and even trying that doesn't work. I'm getting some strange errors.

curl https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/sets/base-26.1.3-amd64.txz --output  base=26.1.3-amd64.txz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 94 135.5M  94 127.8M   0     0  5282k     0   0:00:26  0:00:24  0:00:02  4323k
curl: (56) OpenSSL SSL_read: OpenSSL/3.0.19: error:0A000126:SSL routines::unexpected eof while reading, errno 0

and
fetch https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/sets/base-26.1.3-amd64.txz
base-26.1.3-amd64.txz                          97% of  135 MB 3529 kBps    01s
fetch: base-26.1.3-amd64.txz appears to be truncated: 138295975/142168104 bytes

Running curl and fetch twice seems to give different file sizes, even when trying multiple times, which suggests to me a problem on the download server side of things.
This also applies when downloading the file with firefox. that also will fail too.

No other download fails over my connection. sometimes i do get hitching but that shouldn't cause an EOF to be sent when I try to download something.

This is about the fifth time i've had failed updates with the same packages (base and kernel) on different versions. Sometimes they resolve themselves, sometimes they don't and need me to fight it. I believe i'm having the same issue on multiple servers/repos because even changing repos doesn't seem to resolve the problem.

I did see something a little while ago that people do have issues with 5G NSA/LTE connections, which is what i'm using; however, i doubt that'd cause the issue i'm having here. Nothing else i download fails in the same way.

I have tested this a few different ways and it seems to me that when the download exceeds an amount of time, it will close the connection and stop the download. over my vpn, which allows a much faster download (because it's not traffic shaped as much), it completes sucessfully.
Is there anything you'd suggest i can try? or is there something else going on here?

Thanks
D.