Messages

Hi,
I had a similar issue few months ago. In my case, I upgraded wan connection from 1GB to 2.5GB.
My proxmox server is connected to a switch at 10GB.

I solved my problem enabling flow control on the switch ports involved.
In your case I suggest to check and try to enable flow control on both Intel network devices (via some tunables?).

In my server I don't use passthrough, I use virtio driver combined with Multiqueue configuration.

I hope this could help.

Best regards

I agree, a GitHub ticket for reasonable requests or production bugs is a good start to gain traction.


Cheers,
Franco

My several attemps to update the crl certificate even caused a crash in the system and I correctly uploaded the crash report as suggested.

Look, you have developed some extremely broken workflow around a misfeature that never should have been there. Need to replace a certificate? Then issue a new certificate, install it, configure it for all places which happen to be using it, and only AFTER that revoke the old certificate. I would hazard to say that's what about 99% of users do. Instead of developing a concept of "per-application" CRL.

The errors in importing the external certificates has been reported in my previous posts and one just need to read them.

Good luck, don't have time for post hunting.

If you do not care of reading what other people wrote there is no need to post at all with all your non-sense comments. Goodbye

One reply for all your comments...
I know very well what a crl certificate is as I am been working in the security business for decades now.
I also know very well the "good reasons" mentioned by @franco where a CA must publish a single crl as a unique (reliable) source of information.
My point is that in the scenario described the opnsense firewall is NOT the CA that is publishing the crl. It is just one of (possibly) many devices that are using it. The goal of the administrator is to keep the configuration working and being able to quickly switch configuration objects in order to keep it running and secure. That is the exact reason why all major industry security devices are using object oriented configuration strategy.
Whoever says that the current way of managing certificates in opnsense is better then the older way never worked in a complex production environment or just don't care.
The errors in importing the external certificates has been reported in my previous posts and one just need to read them.
I can only add that now opnsense is not even able to recognized that an external certificate has been signed by an external imported CA! And that's exactly why an error is raised whenever I try to update the crl certificate...because the device is not able to link the certificate to the imported CA.

The 24.X allowed to import several versions of crl certificates. And this makes perfect sense to me and allows administrator to revert quickly to older (still valid) versions in case of error. Also, allows to update one configuration at a time (for example, starting with a test service). This way I am forced to update all the services depending on that CA at the same time.
That said, it is not working! the new crl is not accepted and raised errors.

In my honest opinion the certificate management is now a total mess...

I probably have the same issue...apparently couldn't import new crl certificate anymore (I opened a separate post for this...). I tried to delete the imported CA and then tried to reimport it without success...I get the following error in the logs:

[OPNsense\Trust\Cert:cert.cb6ce1a9-1a7c-4b36-b203-746c5fb5906a.caref] Please select a valid certificate from the list{66c460d82d748}

My External CA is RSA based size 2048 bits.

Any ideas?

Hi, thank for your reply...Unfortunately your suggestion does not solve the issue: first of all, even if it worked, I would rewrite the older crl certificate that, maybe, I still need for different cases...second, I tried to overwrite the crl certificate like you said but when I try to apply the changes I get an error "Certificate does not seem to exist" corresponding to the CA certificate...
Should I delete the referenced CA and then reimport it? But it is referenced sever times in the configuration...

The system/trust/revocation section in the webui lacks of the add button...how can I import a new crl certificate?

Any help?

@rmlinnovator

Hi, I am running a very similar hardware and no crashes here yet. I am still testing though.
About your configuration I noticed two things you should investigate on:

1) According to Proxmox documentation you should set "machine" option to "q35"  if one wants to pass through PCIe hardware.
2) To optimize communication between the host and the guest it is also suggested to install and enable the qemu guest agent

Let me know if this helps.

Best regards

I searched the forum and could not find anything useful about this subject...iperf does not work on my opnsense.
I go to Interfaces/Diagnostic/iperf and create a new instance on lan interface. After few seconds a result summary appears where the port is declared. Then, I run my iperf client pointing to the firewall ip and port of iperf instance...this connection fails by timeout.
I took a packet capture from opnsense and I can see the client trying to connect but the firewall does not respond.
I also ckecked the firewall log and I can confirm no rules are blocking this communication.

Any ideas?

Thanks,
Fabrizio

Yes, I did

Hi, I managed to workaround the issue but I still don't understand why opnsense is working this way.

1 - I found that the problem occurs while bridge filter is enabled and you set "Automatic outbound NAT rule generation" in outbound nat mode section
2 - If I set outbound nat mode to "Manual" and replicate the same exact automatic outbound nat rule the problem is still there: at least this one makes sense!
3 - After some investigations it seems that the firewall is ignoring the fact that you set WAN Interface in the nat rule. Documentation says that this is the interface the rule applies to. And by reading this I understand the rule is going to be executed in case a packet is traversing that interface. Instead, the rule seems to be applied even when a packet is traversing other interfaces (not involving wan interface, ie packet traversing from a bridge interface to another).
4 - So, the workaround is to recreate outbound nat rules while setting a filter for destination address (only public networks destinations will be source natted)

Again, can someone explain the rationale behind this behavior?

Hi, I am a senior network admin but I am also new in Opnsense usage.
I created a lan bridge following documentation (https://docs.opnsense.org/manual/how-tos/lan_bridge.html) and everything seems to work.
Except that I discovered that traffic flowing from one lan (bridge) interface to another it is source natted with the wan address. Why?
After some investigations I found out that disabling bridge filter (net.link.bridge.pfil_bridge=0) solves the issue.
But this way I have no firewall filtering.

Would you please explain the logic of this behavior and a possible solution?

Thanks in advance for your help.