Messages

I do that completely differently: Whatever the outbound IPv6 is, it will always have the same /56 prefix, because I use IA_NA only.

Thus, the lower 68 Bits consist of the interface ID + 64 bits of whatever any client or OpnSense has. In order to make services available, it is best to refrain from privacy addresses (because they change!) and use the (fixed) EUI-64 part. There are many dynamic DNS providers that are capable of chopping off the lower bits and only change the prefix to the incoming connection. I happen to use my own.

Thus, they keep whatever you manually configure the lower bits to be. This makes it possible to have dynamic DNS updates done by OpnSense "in lieu" of any client.

[10.110.0.1/24]

Vergleich mal:

VLAN:
Tag: 50
Name: vlan01
VLAN-Schnittstelle:
Aktiviert
Statische IP: 10.110.0.1/24

Aktiv auf der VLAN-Schnittstelle
Adressbereich: 10.110.1.2 – 10.110.1.254

At least we cannot be sure of that. From time to time we stumble upon another piece of the puzzle.

And for the record: This was a (small) security problem that had been fixed in the other BSD project and ported to FreeBSD, but only in parts (that seemed to matter). It was never clearly communicated which parts where fixed, because the fixes were done incrementally and augmented via several bug reports. Some of those were simply disregarded, because they were not reported on "pure" FreeBSD, but on OpnSense, laying the burden of proof on users.

So, to answer your question, you would have to take the initial fix and compare it across all over the place in FreeBSD. Would you like to volunteer?

All we know is that there were documented missing parts of specific ICMPv6 handling that were left out and led to the exact bug sighting that were to be expected from it, all sidelined with pure denial of these facts and pointing how this must be done - with each of the missing parts tracked down according to the FreeBSD process.

AFAIK, OpnSense itself uses no privacy extensions for its own outbound connections. With IA_NA, it just cannot, because that would be a /128 and even with IA_PD, it does not, which has been criticised in the past.

Thus, I suspect you try to achieve something different? Dynamic DNS is out of the question, because you would rely on the redundant EUI-64 based parts for that, so what is your intention?

You are correct about that there is a certain relation between up- and downstream that must be met in order to allow traffic at all. That is because the ACK stream takes up upstream bandwidth.

However, I measured during the downstream part of the Waveform test and got these results:

You cannot view this attachment.

This shows 4 GByte downstream data and ~130 MByte Upstream, of which 80% was TCP ACKs, so roughly a 3.25% of the downstream needed for upstream. AFAIR, that is about to be expected at a theoretical worst case of ~4% and a more practical 2% (RFC 1122).
AFAIK, that should also explain your rate of 1000/35 Mbps: Your ISP wants you to have full 1000 Mbps downstream, but only the mere neccessity for the upstream with nothing left for server applications. There are some more providers which offer only a small downstream even if there is no technical neccessity to do so, like with DOCSIS.

So, in theory, you should be able to use the full 1000 Mbps downstream, not only 600?

I can imagine two things that may shift the results:

1. With TCP ACKs, you can have pure ACKs and SACKs, so the number of packets used can be severly lower than the number of data packets. That is obviously the case in my test. You did not show the downstream part of your test, you we cannot know if SACK was used, which would be dependend on the client.

2. Regardless of the net data being transferred, pure ACK packets are way shorter than data packets, so they incur a larger overhead, so the net data results may not mirror the real bandwitdhs used.

IDK. If you feel that is a bug, create a bug request on Github.

It does not do that per default. Identity association is the new version of the former "Track Interface". Thus, it depends on how many bits you have in your parent interface's prefix delegation size. AFAIK, you need a shorter than /64 prefix in order to be able to supply a full /64 prefix to any interface.

Maybe your ISP does not give you a /56 (which is pretty much the default) or you did not request as much on your WAN. How many bits is your IA_PD prefix?

Perhaps you should take a look at the official docs: https://docs.opnsense.org/manual/ipv6.html

Or my IPv6 guide (which is still based on track interface): https://forum.opnsense.org/index.php?topic=45822.0

I know. I edited in parallel and now augmented my post.

Sigh. I wish people would actually say if they use Proxmox underneath anything before asking seemingly unrelated questions...

Didn't I write something to that extent? Ah, yes, here, point 16.

While we are at this, also take a look at points 10, 22 and 27.

Also: How exactly did you set up your OpnSense under PVE? Virtio or passthru NICs? Did you use multiqueue on the PVE NICs in the VM definition?

You now answered that - in case you use Realtek physical NICs, you inherit all the problems in point 6 of the READ ME FIRST article.

Maybe it is time to also look at: https://forum.opnsense.org/index.php?topic=44159.0, with a caveat that the "hardware checksumming" on virtio interfaces may be fixed already and can be left enabled. If you disabled it before, maybe that explains why the VM became slower.

Wenn diese Seite TLS verwendet - im Wesentlichen: nein. Du müsstest Traffic Inspection machen, dazu benötigst Du eine TLS-Terminierung in OpnSense. Das geht zwar mit Squid, aber es müssen dazu Zertifikate on-the-fly erzeugt werden von einer eigenen CA, die in Deinem Browser als trusted eingetragen wird.

Siehe https://forum.opnsense.org/index.php?topic=42985.0, Punkt 12.

Yes, I was only talking about x64 as VM, which seems like the obvious choice for self-hosting.

I know you can use a Raspberry, yet I found it to have a high power envelope for what it can do and also, it cannot handle virtualisation for many different applications. The main reason that ARM image is supported seems to be that the UDM line of products is ARM64 as well.

The UNC can even be used as a package under OpnSense itself, it is available from Mimugmail's repository.

That AVX requirement on x64 platforms is mostly irrelevant anyway, because even an N100 has AVX2. Any fairly modern x64 CPU should have it.

It remains difficult and requires skills and experience. That's why I am not dreading to be replaced by AI.

Wise words, Patrick - and you are right.
 

As I said, there are other services that need to be accessible, logging is just one example that is obvious that I can mention. When you think more than a second about the application at hand, you will notice how it cannot be done with inside-out-access only... ;-)
Of course all of those services are themselves not on the LAN, but in separate security zones.

What I want to point out is that even with very strict security requirements, there is no such thing as black and white. I remember dicussing a full fledged firewall setup of this kind back in 1997:

You cannot view this attachment.

Where each of the three firewalls was supposed to be a dual-homed gateway with two routers and an intermediate appication-level gateway:

You cannot view this attachment.

Guess what? This was severly downscaled in reality...

What you define as a DMZ is in reality a "dirty DMZ" with actual devices between two routers. As such, it only benefits from the first router, whereas the LAN is behind both routers.

As explained, two routers of the same kind only bring more complexity, not more security and if you limit yourself to just one firewall, then it is the responsibility of that to separate the DMZ from the LAN.

There are many slight variations on this theme, so you have to explicitely say what you mean - that is what I referred to in my response.

Besides, with any kind of DMZ, you will find that more often than not, this sentence: "the DMZ would never under any circumstances be able to reach the internal net" is not true, either. Having build such setups for e.g. banks, I can tell you that e.g. logging must be able to pass to inside servers, among other things.

I saw that in the past when I over-optimized the shaper by not leaving enough headroom in the pipes' bandwidths in pursuit of maximum bandwidth. You cannot have your cake and still eat it.