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 - meyergru

#1
So your problem is that your OpnSense has LAN on vmbr3 aka enp90s0 and it should act as a DHCP server (which it does according to your packet traces) but your clients attached to that NIC (via a switch?) do not get DHCP IPs assigned?

If the NIC is not attached directly to a client, but via a Unifi switch or the dream machine itself, you should know that there are settings in Unifi to block non-legit DHCP servers. Maybe your Dream Machine is the only allowed DHCP server. In order to verify, try to attach a client directly to that NIC (make sure to use the correct one).

Also, since your PVE host is already attached via some bonded SFP+ NICs, I would rather use those instead of another NIC. You can distribute VLANs over that NIC(s) to do that. Besides that, I am not a huge fan of bonding except for reliability. With Unifi equipment, you will gain no more throughput via bonding, because most Unifi hardware does not support "real" load-balancing. I think that balance-rr would not work in the way you think it does.
#2
Two basic things:

1. In order for passthru to work, you must have exclusive access in the VM, so configuring the NIC on the PVE host is a no-go. There are lots of prerequisites to do this. It cannot be successful if you do not see the NIC in the OpnSense VM.

2. This worked under Proxmox with a virtio adapter? Then Linux is fine handling your Realtek device. How do I know it is Realtek? Because your MAC OUI tells me so. See this, point 6.

I generally do not recommend using passthru unless strictly neccessary, see: https://forum.opnsense.org/index.php?topic=44159.0. bridge-mcsnoop is explained there, too. And as a general rule: Do not use AI or YT videos to learn about OpnSense. There is plenty of ggod documentation and also the tutorial section of this forum.
#3
I have never seen any such big MTUs. With 1.1.1.1, I did not get any conclusive results. Try 8.8.8.8.
#4
There is no automatic migration. You can set up your new DHCP server of choice (Kea or DNSmasp) according to the documentation.

The only thing that warrants non-manual setup is the static reversations IMHO, and those you can export as CSV and import to either Kea or DNSmasq.
#5
25.7, 25.10 Series / Re: New site PPPoE PMTU woes
January 17, 2026, 09:33:12 AM
I would first try if the MTU size is the culprit first (it may also be HTTP/2 over UDP). Use the utility from this post: https://forum.opnsense.org/index.php?topic=45658.0 to find if the 1500 byte MTU is valid from your OpnSenses.

P.S.: I skip all of the obvious problems, like Realtek adapters, Proxmox underneath with mini jumbo frames, etc. Most of that is covered in the linked article and this one: https://forum.opnsense.org/index.php?topic=44159.0
#7
Das ist sowieso der Default, wenn Du nichts einstellst.
#8
Die MSS ergibt sich aus der MTU, muss man normalerweise nicht einstellen.
#9
MSS <> MTU. Berechnete Werte stimmen oft nicht. Probieren geht über studieren. Wie groß die von der OpnSense aus nutzbare MTU ist, gibt Dir das Skript konkret aus, wenn Du es mit dem Ziel 8.8.8.8 aufrufst - egal, was Du eingestellt hast, es zeigt, was aktuell funktioniert.

Entsprechend stellst Du die MTU dann im LAN ein (oder Du belässt diese bei 1500 Bytes und machst MSS-Clamping.
#10
Exklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann. Das steht im Guide im P.P.S.. Und das betrifft neben der Bridge auch den zugrundeliegenden physischen Adapter.

Im LAN dürfte das egal sein, weil man da ja nicht über die üblichen 1500 Bytes gehen muss, für das WAN aber schon. Die Alternative wäre passthru, dann kann das alles die OpnSense selbst machen. In den obigen Screendumps läuft das WAN aber über vtnetX.



Am Rande bemerkt: Die DG hat normalerweise kein PPPoE, wenn sie selbst ausbaut, sondern direkt DHCPv4. Falls also PPPoE und ausgerechnet VLAN 7 eingsetzt werden, gehe ich von einem Telekom-Reseller-Anschluss aus, für den selbstverständlich Telekom-Rahmenbedingungen gelten. Siehe dazu den prominenten Disclaimer im HOWTO, der im Wesentlichen sagt, dass die Telekom keine Mini-Jumbo-Frames unterstützt - ich unterstelle, dass das auch für Glasfaser gilt.

Ergo: Es gehen wahrscheinlich nur die üblichen 1492 Bytes MTU. Die müsste man dann auch im LAN nehmen oder MSS Clamping nutzen.
#11
Unifi officially supports 802.1x in some switches, however, beware of this (still unfixed) bug, which effectively makes it unusable on some of the newer Unifi switches (it seems to be a chipset bug that lies somewhat outside their control):

https://forum.opnsense.org/index.php?topic=45429.0
#12
Läuft bei mir ohne Probleme, auch mit den aktuellen Versionen. Allerdings gab es da schon vor einigen Versionen mal Änderungen.

Man kann im Backend aktuell folgende Mechanismen setzen:

Forwarded header (RFC7239)
Forwarded header parameters (z.B. host und proto)
X-Forwarded-For header

Ich nutze dann im echten Server (nginx) etwa so etwas:

# Because of reverse proxy
set_real_ip_from        192.168.173.1;
real_ip_header          X-Forwarded-For;
real_ip_recursive       on;
#13
What you are looking for is outside the scope of OpnSense, because it has to happen on the network access layer. The only thing OpnSense can provide is the VLANs themselves and a FreeRADIUS inventory for your devices.

The standard is IEEE 802.1x, but you need to have a switch or AP that conforms to it. Also, you need either certificates on all of your clients in order to be able to identify them or you rely on their MACs to sort them into different VLANs. As you already know, MACs can be spoofed.
#14
Quote from: Lu on January 16, 2026, 02:54:44 AMDoesn't 'floating' allow DNS requests from the WAN side?

Not if you do not include WAN in the applicable interfaces. I cannot see anything in the packet captures, but they do not show if anything gets blocked.
#15
Du bekommst bei Amazon solche Mini-Firewalls als Barebones zwar für < 200€. Leider sind inzwischen die Preise für RAM stark gestiegen, weshalb Modelle mit RAM und SSD meist bei > 300€ landen. Der billigste 8 GByte SODIMM DDR5 kostet schon ca. 100€, eine 256 GByte SSD ca. 50€ - unter 300€ wirst Du wohl nur noch gebraucht landen.

Es gibt aber manche Modelle mit N100 (kaum langsamer), die noch DDR4 einsetzen, dann wird es etwas billiger:

https://www.amazon.de/dp/B0F5GJ2JHP
https://www.amazon.de/dp/B09F4CT8LV
https://www.amazon.de/dp/B07BL2WXB9

Ich habe auch einen mit N150 gefunden: https://www.amazon.de/dp/B0FCY3CFW7, allerdings sieht die Kühlung da schlechter aus.

Ich würde immer die Selbstaufrüstung vorziehen, weil Du dann keine No-Name-Bauteile bekommst.