Messages

If Twitter.com and Tiktok.com work while others like Facebook.com do not, this would lead me to believe that IPv6 connectivity is broken while IPv4 works.

Why? Twitter and Tiktok rely solely on IPv4, while many others also use IPv6. IPv6 having the higher priority, this could mean that the IPv6 DNS addresses are resolved (possibly via IPv4) but cannot be reached for one reason or the other.

This can easily be checked by "ping -4 facebook.com" and "ping -6 facebook.com". Should IPv6 really be the culprit, one can then check every single building block (i.e. DNS, routing, firewall) and see what is the root cause - or disable IPv6 altogether.

My DEC750 was shipped with ZFS.

It did not have TRIM enabled either (as shown by "zpool get autotrim") - "tunefs" is only applicable to UFS.
I enabled TRIM via "zpool set autotrim=on zroot", started the trim manually by "zpool trim zroot".

You can check the trim status via "zpool status -t" for ZFS.

It works when you enter 192.168.7.1-8, but not for 192.168.7.1-192.168.7.8.

You should open an issue on github.

When you look at the automatically generated floating firewall rules, you will find exactly the one you see. I think it has just been renamed from the older "Default deny".

Two comments:

1. Just one observation: The negotiated features differ in RX offloading:

Code Select Expand


-dev.virtio_pci.3.negotiated_features: 0x3087bbe7 <RingEventIdx,RingIndirectDesc,CtrlMacAddr,CtrlRxMode,CtrlVq,Status,MrgRxBuf,TxTSOECN,TxTSOv6,TxTSOv4,RxLROECN,RxLROv6,RxLROv4,TxGSO,MAC,CtrlRxOffloads,RxChecksum,TxChecksum>
+dev.virtio_pci.3.negotiated_features: 0x30c7b865 <RingEventIdx,RingIndirectDesc,CtrlMacAddr,Multiqueue,CtrlRxMode,CtrlVq,Status,MrgRxBuf,TxTSOECN,TxTSOv6,TxTSOv4,TxGSO,MAC,CtrlRxOffloads,TxChecksum>


2. By limiting the diff to driver-specific aspects, you miss any other performance-related things, like memory protection, threading settings or circumvention of CPU flaws (e.g. hw.ibrs_disable or hw.spec_store_bypass_disable or net.isr.bindthreads). However, I actually have no clue as to what might be the performance impact of any setting.

Oh, I just saw that I misread the OpenBSD column for OpnSense in that comparison...

I know, I have another J4125-based system.

Matter-of-fact this is meant more as a warning to the extent that:

1. N5105 hash more 30% performance, but uses 40% more power than a J4125 (despite the TDP claims showing similar values). This makes it difficult to suggest for a passive system of that size.

2. The Topton box has massive production flaws w/r to cooling as of now, set aside the abysmal quality of the power supply.

Subscribed. I see the bad performance on my DEC750 as well.

Did you compare the sysctl -a outputs to see if there is just a random parameter that limits the OpnSense kernel?

Although there seems to be a lot more than just parameter differences when I look at this comparison: https://hardenedbsd.org/content/easy-feature-comparison

Just my quick findings about this Topton system which seems quite interesting considering it is kind of in-between readily available J4125-based and non-available so far Elkheart Ridge-based x64 boxes. It is ~30% faster than a J4125.

The system has some flaws that CAN be fixed. You can read about this here (unter the second heading).

I think the hairpinning (aka NAT reflection) in itself does work, but not between different interfaces. For me, it is the firewall that is blocking the traffic from getting through.

I can see that from the fact that every port forward with enabled reflection that originates from my LAN works fine (even if the destination machine is in the IoT network), but not the other way around. My LAN is allowed to access the IoT network, but the opposite is not true.

If I want to keep that logic, I have to allow access selectively to the reflected IPs and ports from the IoT network.

That Teklager device is just a rebranded (and IMHO overpriced) Supermicro E302-9D, which is the passive counterpart to the E300-9D-4CN8TP I mentioned. It will consume almost the same as my system (i.e. 75 Watts, less 3 internal fans) and most probably get a lot warmer (mine reached ~60°C at idle).

You can check this here: https://www.supermicro.com/en/products/system/Mini-ITX/SYS-E302-9D.cfm.

You can buy the original for a lot cheaper, but without a preinstalled firewall. The RAM and SSD will cost you ~200€ on top of the price of the barebone.

The Xeon D2123-IT is a 2018 CPU model which is inherently much more power-hungry considering its performance than current breeds which is why I switched.

In 22.1.4 gibt es dann auch echten QinQ Support.  ;)

Ja, gerade gesehen: https://github.com/opnsense/core/issues/5560

Wenn Dein Ziel ist, VLAN7 in VLAN99 zu verschachteln und zwar auf der OpnSense selbt, dann geht das nicht - bei der Definition von VLANs musst Du ein "Parent Interface" angeben, dort sind nur "physische" Interfaces auswählbar.

Damit ist in OpnSense nur eine Ebene VLAN definierbar.

Am Rande: Wenn Deine Interfaces 1 GBit/s können, würde sich der maximale Durchsatz durch die Zusammenfassung auf 500 MBit/s halbieren - je nach Zugangsart kann das eine Einschränkung darstellen.

Ich nehme an, Du willst mit nur einem physischen Port sowohl die GUI des Modems erreichen als auch auf VLAN7 PPPoE machen.

Dazu könntest Du entweder das Modem selbst das Telekom-VLAN7 taggen lassen oder im Proxmox etwas anderes als "Guest configured VLAN" nutzen. Dann könnten sich die Server und die OpnSense z.B. das Bridge-Interface für VLAN1 teilen, während Du ein dediziertes Interface für WAN und PPPoE nutzt, das nur der OpnSense gehört. Damit umgehst Du auch den Switch für WAN-Traffic an den beiden Servern.

Ich habe früher für interne IPv6-Verbindungen mal ULAs benutzt, habe das aber mit OpnSense noch nicht probiert.

I use a DEC750 now and can say it can support 10G via SFP+ ports, but anything serious like IDS will not work at full 10 Gbit/s speeds (see the discussion under this video: https://www.youtube.com/watch?v=853y4ShbpZg). Also, with only one TCP stream, you will be limited by single-thread performance which is around 1.5 GBit/s.

I also have a HUNSN R34g mentioned in the STH video, which also has 4 cores, but no hyperthreading. The CPU is ~66% the speed of the DEC750 and also the power requirements are at ~66%. In this thread: https://forum.opnsense.org/index.php?topic=26705 we discussed a Topton system with an N6005 at slightly higher power draw (much like the DEC750, cheaper, but without SFP+).

Before the DEC750, I had an E300-9D-4CN8TP (there is a video for that by ServeTheHome as well), that is much faster, but uses 75 Watts at idle under OpnSense (I sold it for this reason).

There are new boxes coming out with the Elkhart Lake CPU which should be even faster than the DEC750, I saw this one: https://www.bcmcom.com/bcm_product_BI270-6412J.html and Compulab's Fitlet3, but neither has 10G SFP+ ports. Also, they become available only slowly.


It all boils down to what you expect from the system - if you only want 1 GBe firewalling, all of them will do. If you want IDS, you need more CPU power. If you need 10 GBit/s speed for inter-VLAN routing, you will have higher power draw. 2.5 GBit/s is a nice upgrade, but you cannot use power-efficient DAC cabling to your switch in that case.