Messages

Hi,

Our OpnSense (DEC-3850) is at the moment: 21.10

But 20% from 2,5-3 is not 10 though the real question is how realistic that assumption is considering IPsec is running in the first place and may be a feature from the firewall is used. Or I'm reading this wrong...
Cheers,
Franco

because of a maintenance from our datacenter provider, we where able to shutdown IPSec VPN and tested quickly again with iperf3 from one VLAN to another VLAN, so it goes over the OpnSense appliance. We had ~1Gb/s more throughput. So instead of ~3Gb/s we had nearly ~4Gb/s.

I'm not sure, if we can reach max ~5Gb/s in theory, because the traffic has to go twice over the same OpnSense Interface (which is a LACP 2x10Gb/s). But .. one important thing came into my mind: Before we switched to the DEC-3850, we had a real server (Supermicro x11SSH-LF) and reached ~5Gb/s. But anyway ...

The other mention you found from me (just found that thread after this one and  I've found out, that traffic from one VLAN to an other one is also pretty slow ): It is the same setting, sorry if it was not clear. I've tested every combination, in the moment, OpnSense jumps in .. the throughput breaks down. The question for me is: is that expected, that the "speed" goes under 50%, from what is in theory possible.


cu denny

Hello,

I'm joining this thread too .. we have:

* 4 x DEC-3850
* OPNsense 21.10.2-amd64 (Business edition)

Since we use OpnSense .. we have the problem with throughput .. we had in the beginning a SuperMicro X11-SSH with ~5Gb/s and switched than to the appliance. We never reach more than 2-3Gb/s (iperf3, without any special options) and it seems .. the problem is the VPN stack. So, if you have a IPSec tunnel, all traffic slows down, even it does not go through the tunnel.

we tested:

* VM -> VM same hypervisor (Proxmox) same VLAN = ~16Gb/s
* VM -> VM different  hypervisor (Proxmox) same VLAN = ~10Gb/s
* VM -> VM different  hypervisor (Proxmox) different VLAN  = 1,5Gb/s -  ~3Gb/s

So, if it goes via OpnSense .. the network slows down.

https://www.mayrhofer.eu.org/post/firewall-throughput-opnsense-openwrt/

When IPsec is active - even if the relevant traffic is not part of the IPsec policy - throughput is decreased by nearly 1/3. This seems like a real performance issue / bug in the FreeBSD/HardenedBSD kernel. I will need to try with VTI based IPsec routing to see if the in-kernel policy matching is a problem.

What makes as very sad .. if this is the real issue ..  It is not easy, to test it and disable VPN .. but we will try to build a test scenario ...

Pretty sad things ...

hi,

any news here ? We have the same problem .. with DEC3850 .. and we have around ~2,5 - 3Gb/s. Also for the network, which goes  **not** over the tunnel. What I found:

https://www.mayrhofer.eu.org/post/firewall-throughput-opnsense-openwrt/

When IPsec is active - even if the relevant traffic is not part of the IPsec policy - throughput is decreased by nearly 1/3. This seems like a real performance issue / bug in the FreeBSD/HardenedBSD kernel. I will need to try with VTI based IPsec routing to see if the in-kernel policy matching is a problem.

If we don't go over the applicance / OpenSense .. we hit the 10Gb/s limit.

hi,

if I read all correct, this issue will be resolved in  21.1.3 ?

hi,

we will see, if we have time to do so. In the meanwhile we ordered 2 x DEC3850 to solve this issue.

cu denny

hi,

can you tell me, what for a network card you use ?

Because: https://forum.opnsense.org/index.php?topic=21663.0

I am on 20.7.4-amd64, virtualized on ESXi, Intel NIC passthrough.
Also added a virtual NIC, which shows the sames symptons while other VMs on that ESXi host dont.

we have similar problems: https://forum.opnsense.org/index.php?topic=21663.0

do you have copper or fiber intel cards ?

[through]

Hello,

since the upgrade from 19.7 to a higher version, we notified, that we have often a very high ping latency on our OpnSense Cluster. It happens only, of the packages goes through the OpnSense. We replaced the SFP+ modules, cleaned the fiber but .. since it happens on both physical hosts, we don't think, it's a network hardware issue.

What we have:

• SuperMicro X11SSH-TF
• 64GB DDR4
• Intel X520 (fiber)
• Intel X550 (copper)

I've attached a Grafana picture as you can see, that we have much "noise". These causes, that our MariaDB starts to switch our Write Master.
We have also an nearly identical setup on the other side (both clusters are connected via a darkfiber). I say nearly, because the firewall rules are a bit different (because of the reverse side), but we don't now ... that we configured a thing, that causes the ping latency with a higher version than 19.7.

We red about problems, if the OpnSense is a VM ... and some Pyhton scripts steal the CPU ...but our hosts are physical. We have no idea, where we can find this issue.

Any suggestions ?

cu denny

hi,

die Mellanox haben wir als 100Gb für Ceph Storage im Einsatz. Zwei von den 16XG haben nur drei Kabel: die Darkfiber und OpnSense1 und OpnSense2 :-)

Dummerweise müsste wir bei der Änderung der SFP+ Module auf ein Goodwill des RZs hoffen, wenn die Buchhaltung das OK gibt, denn dann könnten wir auf BiDi umrüsten.

Was ich noch von einem Ex-Kollegen als Tipp erhalten habe: UDLD auf Aggressiv schalten.  Das müssten wir mal probieren.

hi,

BFD kannte ich noch garnicht. Zum Switch kann ich sagen: die Faser hängt an jeweils einem Ubiquity EdgeSwitch 16-XG.

cu denny

hi,

wir hatten gestern einen Ausfall bei der Verbindung zwischen zwei RZs, bei dem der RZ Betreiber versehentlich unsere Darkfiber in der Tür eingeklemmt hat. Das hatte zur Folge, dass wir ziemlich ins schwitzen kamen, bis die Ursache klar war.
Der Grund warum das Auffinden so lange gedauert hat war der, dass laut beiden OpenSense Clustern (19.1.7) das VPN wohl noch auf beiden Standorten "aktiv" war, aber es floss kein Verkehr durch.

Ich vermute, dass das Kabel nicht vollständig durchtrennt wurde, sondern nur soviel, dass entweder RX, oder TX kaputt war. Der Link muss also für die SFP+ (Single Mode 10km) noch "UP" gewesen sein.

Hat jemand schon einmal ein ähnliches Problem gehabt ?  Eigentlich hätte ich erwartet, dass IPSec Heartbeats sendet und beim Ausbleiben eben dieser die Verbindung beendet. Das hätte nämlich schneller  dafür gesorgt, dass Redis / MongoDB und Co darüber Bescheid gewusst und sich reorganisiert hätten. So waren wir gezwungen, am primären Standort den OpenSense Cluster zu rebooten. Erst ab diesem Moment als der OpnSense Cluster wieder da war, konnten wir einen Standort wieder in den regulären Betrieb versetzen.
Als der RZ Betreiber das Kabel ausgetauscht hatte, konnte auch der IPSec tunnel wieder in Betrieb genommen werden, um den zweiten Standort restaurieren.

Ich weiß von einem Kollegen, dass er ein ähnliches Phänomen hatte, aber mit einer Cisco :-)  Er hat darauf hin alle SFP+ Module ausgetauscht gegen welche, die nur eine "Faser" benötigen (also RX / TX  werden über Frequenzen verwaltet).

cu denny

hi,

@mimugmail

wir schauen mal nach, ob dem so ist. Allerdings würde ich auch hier Probleme mit TCP erwarten, sei es wegen Latenz, oder weil Pakete verloren gehen.

Nachtrag:

eben geschaut. Alle interfaces haben "Auto-detect" eingetragen.


cu denny

hi,

@franco

hat sich das irgendwie zwischen 19.1 und 19.4 geändert ? Im spiegelgleichen RZ stellen wir dieses Phänomen nicht fest. Die Gateway Adresse liegt auf einem CARP Interface und hat eine  Fortigate 100D als Ziel IP.

Des weiteren verstehe ich auch nicht, wenn das auch bereits im gleichen Netzwerk passiert (Monitoring - > OpnSense Host). Da käme noch gar kein Gateway zum Einsatz.

cu denny

hi,

ich bin immer der meinung, wenn ich eine neue firewall aufsetze, nutze ich es auch gleich meine FW-Regeln mal zu prüfen ob die noch so sinn machen oder nicht, also mal neu von vorne aufsetzen.

das müssen wir ohnehin immer alle 6 Monate. Aber da die Rechenzentren spiegelverkehrt sind, ist es so einfacher.

cu denny

hi,

question: is it possible to enable " [ x ]Disable reply-to on WAN rules " under Firewall settings ? Just for testing

cu denny