Messages

Yeah, the difference in firewall logic of pf and Linux's way of doing it is one of the reasons why OpnSense and pfSense cannot easily be migrated to Linux (which would be beneficial in terms of driver support). Got me as well a while back and I still have got some reservations about FreeBSD...

As for IN and OUT rules: Once you get accustomed to it, they are easy to handle (i.e.: forget about OUT rules).

I do not think it would change anything in the latency, since offloading only shifts that processing from the CPU to the NIC, which only reduces CPU load.

Instead, let me point you to this: https://docs.opnsense.org/manual/interfaces_settings.html, see the section about hardware CRC. From my own experience, I would keep the defaults, because whenever I enabled the hardware offloading of ANYTHING, I got into trouble sooner or later. Later is especially bad, because you cannot connect the dots and it takes ages to actually find what you did wrong a while before the problem pops up.

[how]

You are splitting hairs, Marc. You said you cannot turn off the logging and I showed how it is possible (I am not recommending to do it either way). Now you discuss why you do not want to do it.

Actually, if you want to have the benefit of the defaults, you will have to accept what comes along with them or make a change request on Github and see if the developers think that is a good idea.

There is a wide range of people. Some (not including me, see this, #24) do not want the automatic rules altogether. It takes a fine balance between full flexibility and reasonable defaults to fit everybody's needs. Matter-of-fact, the very feature to disable automatic rules has only been introduced recently because of that discussion.

No doubt you had your reasons to use tabulator. What is unclear to me is: Is there a technical restriction to tabulator that forces it to have a fixed lower part (the one with the "apply" button)? I think any other page that has a list of lines displays however many lines/items are selected, like ... oh, I see.

I just wanted to point at "Kea DHCP: reservations", but now I find the same behaviour once I choose 50 items instead of my former setting of 20. And I cannot even switch back to that, because the increments have changed, too.

Playing around a bit with it, I found that the main problem comes into play when the lower part does not fit into the window size, because then, the "window" scroll bar shows up.

For many people with a window size < 1400 this is a problem. With my screen height of 1600, the apply button could be positioned even further down.

The question is if one can make the lower part appear at the lower bound of the visible area instead at a fixed offset from above.

+1

".local" wird der DNS-Suchanfrage hinzugefügt, das macht Windows per Default so. Woher es kommt, kann unterschiedlich sein. Man kann die DNS-Domain und die DNS-Searchlist per DHCP verteilen lassen, man kann das aber auch in den Netzwerkeinstellungen in Windows setzen.

Es kann sein, dass es bei Dir aus "System: Settings: General -> Domain" stammt.

Ich nehme dafür typischerweise eine eigene Domain und trage die Namen im DNS auch mit dieser Domain ein, damit sie gefunden werden.

First, Proxmox changes its scheme to name network interfaces once in a while - this is mainly because of Debian / systemd releases changing it.

If you want to have predictable names, you can follow the advice given here:

https://systemd.io/PREDICTABLE_INTERFACE_NAMES/

I always use net.ifnames=0 on the kernel commandline. With a Proxmox server, you rarely get into trouble with that, unless your network devices really change (like with USB adapters or when you switch hardware). Then, I only have to set eth0-X in /etc/network/interfaces. This has no effect on the VMs, because their MACs are assigned in the VM configuration and the device type is determined by the NIC emulation type, which does not change when you do that.


Second: When you use OpnSense as a VM, the virtual NICs are contained in the VM definition - actually, upon creation, a random MAC is being assigned to the interface. These MACs may change when you backup & restore a VM, especially, if you restore a "unique" instance. This is true regardless on which emulation you use for the NICs. It is different with PCIE passthru, since then, the MAC address is the physical adapter's MAC.

Besides: IDK if it is possible to use the "change MAC" feature from within an OpnSense VM - I would not even try that, but leave the control to Proxmox.


Also, FreeBSD sometimes renames drivers for NICs with a new release. That may mess up the interface assigments for the logical interfaces (say if em0 becomes igb0). The assignment will not switch without a new OpnSense release, however.


So, the chain is:

1. physical NIC. This has a name which depends on Proxmox / Debian / systemd versions. Best to fixate it.
2. Mapping of VM virtual NIC to Proxmox bridge interface - this determines what MAC is used and which emulation type of adapter is presented to the VM.
3. "physical" NIC in OpnSense: its name is dependend on the type of emulation and thus, the selected driver. The MAC is determined from outside and should not be changed from within OpnSense.

As for your "secondary" MAC question: As I said, I never tried to change a VM MAC from within. I do not even get in which situation you would have multiple MACs on the same interface (unless it is a bridge, but that does not directly map to a "physical" NIC).

About the panics, see if this: https://forum.opnsense.org/index.php?topic=42985.0, #23, applies to you.

IDK if the panic already has corrupted anything on your filesystem (it should not have if you use ZFS).

[And to be crystal clear what I mean by "survivorship bias":]

You are obviously wrong. See this for an example: https://forum.opnsense.org/index.php?topic=49509.msg251434#msg251434

And to be crystal clear what I mean by "survivorship bias": For a long time, I was under the false impression that this forum is a means to have discussions among experts about advanced networking topics. I found out that this was actually the smaller part of posts. When I discussed with a friend, that I was disappointed that people coming into the forum asking questions that could have been answered by using a quick forum search, he said: "That is because of survivorship bias. What you see in most forums is people who were neither capable of doing Google searches nor ask ChatGPT for an answer, but rather think they are entitled to be held by the hand and led through tough technical topics - all along complaining why the product does not do everything by itself.

Thus, I conclude that there are:

10% of experts who can actually help with problems because they have an understanding of how networking works.
80% of "survivors" that - after they have got nowhere else to go, come in here and ask questions that are already answered in the docs and/or tutorials.
10% of people who think they are smarter than the experts and do everything "their own way" or question everything without good reason.

I do not mean: Do your own testing, like you seem to imply. What I do say is: It is anybody's choice to take advice from anybody. The problem is that there is no way to tell for the 80% to tell who can offer good advice (the first 10%) and who is the last 10%. This was easier when we had a rating system, where you could easily tell when somebody had 3000 posts and 1500 thanks and somebody else who had 1000 posts and only 10 thanks.

Also, note that I do not point out who belongs to which category. Just my 2 cents. I will not argue any further on this topic.

[I]

I did not state that anywhere, did I? Initially, I responded to a question that asked to something that was quite obvious (to me) from the context, then the thread went on to discuss what most people try to achieve with traffic shaping and how it is done these days. If you do not need it (maybe because your ISP does fine without it), do not use it.

I simply object to people stating: TS cannot work because "this is the way I understand it", when several other people say that it helped in their situation. And I see why that is - but I ain't gonna argue about this topic any more.

Anyone can take anyone's advice or leave it be - frankly, I do not care all that much.

P.S.: I am less concerned about convincing anybody since I learned what survivorship bias is. I think the fact that the rating system the forum once had are now gone is a bad thing (tm), because now people have to find out themselves whose advice is good, but whatever... a great mind in this forum often puts it this way: "You do you".

I'm especially fascinated by replacing the suffix of the IPv6 address for all devices on LAN by some random address using Outbound NAT.
For now i have created ~20 random suffixes and loaded these in an alias. These are used round-robin (sticky).

Why bother? IPv6 privacy extensions do that for free when you use SLAAC.

[Also, please create your own thread for this specific question, because I know for a fact that OpnSense can handle VLANs under Proxmox just fine.]

First: The successful ping does only show connectivity, it might go over a gateway, so this is no absolute proof that your VLAN configuration works. Please show the content of /etc/network/interfaces, too.

It also begs the question: In order to make those VLANs work without the OpnSense VM, you probably have another router, likely a Unifi dreambox or their likes. Could it be that this interferes with the addition of OpnSense, resulting in the "leaks" (which you did not describe exactly what you mean by it).

Second: any configuration involving tagged and untagged packets on the same OpnSense interface is discouraged, because FreeBSD is not particularly good at discriminating between a parent and a VLAN interface. I.e.: the parent interface should not be configured with a subnet.

This rules out Architecture 1, but also: You say you used vlan01 and vlan02, whereas the connection from your physical network to Proxmox has only one (tagged) VLAN and an untagged LAN. So how would you map the untagged LAN to your OpnSense over the interface other than using no tag in the vtnet1 definition?

Note that you still can a standard Unifi environment, where the default LAN is untagged, but other VLANs can exist. Preferably, would then delegate the VLAN handling to Proxmox. This means that you create two vtnet interfaces, one with a VLAN tag and one with your respective VLAN. On OpnSense, both vtnet interfaces are UNTAGGED, because Proxmox handles the tagging in this situation.

Alternatively, you can also use vtnet0 as untagged and have vtnet1 also untagged in Proxmox and then create VLANs on vtnet1 inside OpnSense as needed. That way, vtnet0 only uses untagged frames, whereas vtnet1 only uses tagged VLANs, which also satifies the above condition.

Third: you give vtnet1 with Architecture 1, which implies another interface vtnet0 still being present, potentially causing problems. Same goes for Architecture 2, where net4 and net5 show up, potentially leaving net0-3 as being problematic.

Fourth: Did you follow the guide w/r to tuneables to make vtnet interfaces work?

Also, please create your own thread for this specific question, because I know for a fact that OpnSense can handle VLANs under Proxmox just fine.

Das letzte Posting im Thread ist zwei Jahre her. Der VMG3006 wurde inzwischen durch den neueren VMG4005 ersetzt.

What did you finish setting up in your router? Some kind of transparent proxy? Crowdsec, suricata, zenarmor or any other kind of blocking or traffic inspection?

If the certificate is not being trusted, it can be either of: you are being transferred to the wrong site because your DNS is malfunctioning or the certificate is manipulated by some kind of man-in-the-middle, like a transparent proxy and you have not installed their CA certificate in your browser.

You could see that by inspecting the certificate and see if it matches the domain you wanted to call. The error message suggests that it is a different domain, so the interesting question is: which is it and why did your DNS request return its IP instead of the correct one?

I assumed OpnSense is the central router that connects all VLANs and the WAN. So, I you say you cannot access anything at times without specifying what exactly works and what does not, it might be that it stops working altogether or that only the LAN interface goes down. From your connected workstation, both would look the same.

Therefore, I suggest you find out what works and what does not. Is it the OpnSense that fails completely because of a panic, a system freeze or because one of its interfaces goes down? Is the WAN working, but the switch or the cable linking to that is bad?

You will have to check to narrow down your problem - currently you only know that your "network seems to go down".