Messages

Eine Hürde für jedes zusätzliche (V)LAN ist, dass dort zu Beginn keine "Allow any -> any" existiert, die standardmäßig für das LAN angelegt wird.
Eventuell reagiert deswegen die OpnSense auf den zusätzlichen Interfaces nicht auf den Ping.

Seltsam, dass Du Port nicht als Trunk konfigurieren kannst.

If reducing the MTU size on your Windows client does not fix the problem, them maybe the MTU size is not the problem after all?

Did you try the ping to your OpnSense instance itself, too?

For modern Windows versions, I think they automagically set the MTU size - IDK how they do that exactly, however. I do not have the problem, as both my WAN and LAN MTUs are 1500 bytes.

I would probably first try to make sure that the problematic downstream devices also use an MTU of 1492 bytes.

Ich wiederhole es: Diese Systeme (mit I226V) haben normalerweise keine Probleme mit Handshakes o.ä. - abgesehen davon würden die unter allen OSen auftreten. Am Rande: Meine Hardware ist ganz ähnlich. Es geht hier nur darum, wie der Provider mit gepufferten Daten umgeht und wie groß diese Puffer sind. Bei anderen Router-OSen ist oft schon intern ein Traffic-Shaping aktiv, steht alles auf der verlinkten Seite.

Die Tatsache. dass Du vom Client zur OpnSense das volle Gigabit bekommst, illustriert dies: keine Hardwareprobleme.

Die angeführten Tuneables ändern nichts daran, weil beispielsweise die aufgeführten TCP-Parameter ausschließlich für TCP-Verbindungen von der OpnSense selbst wirken, nicht für geroutete TCP-Pakete von angeschlossenen Clients.

Das ist genau der Bereich, den Du mit Traffic-Shaping beeinflussen kannst. Bezeichnenderweise wird genau das auf der von Zapad verlinkten Seite auch gezeigt, nämlich: https://github.com/nightcomdev/opnsense/blob/main/QoS/README.md

Ich höre aber jetzt hier auf. Alles ist gesagt: Test (mit OpnSense) für Bufferbloat durchführen - meine Erwartung: schlechte Ergebnisse. Dann die verlinkten TS-Einstellungen vornehmen, sehen ob es hilft.

Wie ein Router auf die Schwankungen reagiert, hängt vom Router ab. Tatsache ist, dass große Puffer eher mehr Schwierigkeiten machen. Ich habe  keine Ahnung von Sophos und weiß nicht, was die tun. Das hat mit Sicherheit nichts mit der I226V oder FreeBSD zu tun, sondern eher mit der Verwaltung der Puffergrößen.

Tatsache ist, dass Dein Test mit Sophos nicht zeigt, dass kein Bufferbloat-Problem mit OpnSense existiert. Du hast gefragt, was Du bei etwaigen Problemen mit OpnSense tun kannst (die Du hast) und das war mein Tipp.

Wenn Du es nicht glaubst, schön. Hier sind die Fakten nochmals erklärt:

https://www.bufferbloat.net/projects/

Deine Hardware ist nicht das Problem, soviel ist klar, aber das hast Du ja selbst schon gesehen.

Zum einen ist TV-Kabel ein shared medium, bei dem Du keine wirklich garantierte Geschwindigkeit bekommst. Wenn andere Nutzer auf Deinem Segment Traffic machen, bekommst Du weniger Bandbreite. Siehe auch hier.

Diese kurzen Geschwindigkeitsschwankungen, gepaart mit Pufferungseffekten, kann massive Auswirkungen auf die gefühlte Geschwindigkeit haben.

Was Du versuchen kannst, ist Traffic Shaping. Konkret meine ich Maßnahmen gegen Bufferbloat. Du kannst auch vorab testen, ob das Dein Problem ist:

https://www.waveform.com/tools/bufferbloat

https://speed.cloudflare.com/

I cannot test this, because I neither have the OpnSense VM on PVE nor an MTU of 1492, sorry.

Thank you for taking the time to document your experience in detail. It is clear you have invested significant effort into troubleshooting, and the level of detail is appreciated.

That said, in its current form this report does not describe a demonstrable software defect in OPNsense, Kea, or dnsmasq, but rather a set of symptoms that are most commonly associated with layer-2 topology or virtualization configuration issues—particularly in Proxmox environments.

A few observations that are important to clarify:

OPNsense does not require IPv6 to be enabled for IPv4 DHCP to function correctly. IPv4-only deployments with multiple LAN interfaces are widely deployed and fully supported.

If a DHCP client briefly receives a gateway address belonging to a different interface, that almost always indicates that the interfaces are not properly isolated at layer-2 (for example, multiple interfaces attached to the same Proxmox bridge, shared subnets across interfaces, or unintended bridging).

DHCP servers do not "forward" router addresses between interfaces. If a client sees an address from another interface, it is responding to a broadcast originating from the same L2 domain.

To move this forward constructively, the following information would be required before this can be treated as a potential bug:

• Interface assignments and IP/subnet configuration for all OPNsense interfaces
• Proxmox bridge configuration (vmbr layout, VLAN awareness, and NIC attachment or in the case off passthru, physical hardware type)
• Confirmation that each LAN interface is in a unique IPv4 subnet
• DHCP logs from Kea or dnsmasq during a failed lease attempt
• A packet capture (tcpdump) on the affected interface showing the DHCP exchange

Without this information, it is not possible to distinguish between a software defect and a topology issue. To date, there is no known regression in OPNsense 24.x–25.x that prevents IPv4 DHCP from functioning on secondary interfaces in correctly isolated networks.

If you are willing to provide the above details, the community will be better positioned to help identify the root cause.


That being said, you have chosen to use one of the most advanced setups with OpnSense there is (i.e. OpnSense under Proxmox). I assume you have read all the helpful hints to this (like this) or have tried to get a setup running on bare metal first?

Try this.

There are multiple purposes for VLANs, it seems you misunderstood the concept.

Basically, a VLAN, as its names suggests, is a vitual network that is created on top of an existing physical network connection, but logically separated from it.

This can be used in order to separate the logical WAN internet connection over a VLAN (potentially with PPPoE) from the connection to the media converter (DSL modem or ONT) web interface. That is the reason why many ISPs choose to use internet connections via a VLAN, like Odido with VLAN 300.

On the other hand, with a local manageable switch, you can connect to your router via a "trunk" port that carries multiple (tagged or untagged) VLANs. The switch can then be configured to split these (V)LANs out to different untagged ports that are set to one specific VLAN. That way, the switch can act like mutiple switches, one for each VLAN, effectively separating multiple local networks.

The latter is what you probably wanted, but you may see right now why it cannot be done when you create new VLANs on the WAN port - they must be set on the LAN port. There is no additonal VLAN on WAN, because your only got two:

a. VLAN 300 for your internet connection
b. The untagged WAN to access your media converter

You would not connect anything else to your WAN port, would you?

You can look at the actual NVME temps with "smartctl -a /dev/nvme0ns1" after having installed the os-smart plugin.

These things tend to get very hot, especially with high usage. You might suffer the "hostwatch" write problem discussed here.

Thanks for reporting this was a small oversight

https://github.com/opnsense/core/pull/9642

Code Select Expand

opnsense-patch 67668828146e80de49bc6b607db06acb12da8a61
configctl webgui restart

Works for me.

Some of this was already discussed here. There are a few more glitches with the migration...

Another one: When I imported the rules after the patches, I got one "new style" rule that is not editable after importing (pressing edit just does nothing).

The imported rule was:

Code Select Expand

0b229e23-b728-4a32-85fc-4226bda46771,1,keep,,61,pass,1,0,"lan,opt1,opt2,VLANS,wireguard",in,inet46,TCP/UDP,,,,,0,0,0,0,0,,,,,,,,,,,,,,,,,,"LAN Rules",,,,,"Allow DNS to firewall",0,any,,0,(self),53

where VLANS is a group of VLAN interfaces.

I see an error in the browser console when pressing edit on that rule:

Code Select Expand

Uncaught Error: Syntax error, unrecognized expression: .protocol_tcp/udp:not(div)
    jQuery 7
    <anonymous> https://opnsense.localhost:488/ui/firewall/filter/:2327
    jQuery 8
    setFormData https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:217
    each jQuery
    setFormData https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:140
    jQuery 2
    setFormData https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:132
    mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:142
    jQuery 2
    mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:139
    complete https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:312
    jQuery 6
    ajaxGet https://opnsense.localhost:488/ui/js/opnsense.js?v=72f71a09251c25b5:304
    mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:137
    each jQuery
    mapDataToFormUI https://opnsense.localhost:488/ui/js/opnsense_ui.js?v=72f71a09251c25b5:136
    show_edit_dialog https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:1743
    show_edit_dialog https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:1737
    command_edit https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:1902
    _linkCellCommand https://opnsense.localhost:488/ui/js/opnsense_bootgrid.js?v=72f71a09251c25b5:947
    jQuery 2

P.S.: The old rule is editable....

[were]

The edit really should be re-enabled: The lack of editing of associated rules was fine as long as they were associated, IMHO - if they become disassociated, they should gain "full freedom" during upgrade (i.e. become editable) and not stay around like they were still associated.

By not being able to edit them or see their details, it would be error-prone, because everyone used to the old scheme (like me) would assume they are still linked to and controlled by their respective NAT rule - which they are not.