Messages

I do not quite understand what your problem is or what you want to achieve - it seems your IPv6 prefix(es) are dynamic, so the most stable you can get is to keep the lower 64 bits the same.

You can use DHCPv6 or (better) SLAAC to distribute those prefix(es) to your LAN(s).

How (or from where) do you want to get "stable" prefixes and why? I mean, other than using ULAs with NATv6, but then I do not see why?

If your aim is to have routable GUAs in your LAN, you can just follow this guide.

If you use wildcard certificates, you do not need internet access to your HTTP(S) services. AFAIK, wildcard certificates work only via the ACME plugin, not via Caddy's own certificate mechanism.

I would always do it like that and also NOT use specific subdomain(s) besides the wildcard domain, which I explained here.

To disable all types of offloading is a recommendation in the official docs, anyway. You can do this globally or for the individual NICs, or, for some drivers, as sysctl parameters. Neither do you have to do that manually in /boot/loader.conf, nor should you do that, because system tunables could overwrite such settings.

The recommendation to disable hardware checksumming is explicitely noted in the Proxmox guide, as well.

Yes, the situation will hopefully get better once the offloading will be implemented per default.

However, as is also explained in the Proxmox guide, for very high speeds > 1 GBit/s, a passthru will give you speed gains.

Those adapters cannot reliably auto-negotiate the intermediate speeds, and they cannot do this on other OSes, either.

This has been the case since 23.1 - potentially because of the underlying FreeBSD version, see https://github.com/opnsense/core/issues/6526

Thus, you can only do as much as advertise the capability on OpnSense and force the 2.5 Gpbs speed from the other side.

See also:

https://forum.opnsense.org/index.php?topic=33154.0

(and other topics in this forum)

Probably the CPU emulation type?

Yes, there is a better solution: Eliminate the hardware dependencies completely by using virtio interfaces, like depicted here: https://forum.opnsense.org/index.php?topic=44159.0

With that approach, you do not even have to save and backup your configuration, you can just backup and restore the whole OpnSense VM.

I do that on cloud-hosted KVM hosts by using a script that clones the main OpnSense VM in case I destroy it via some bone-headed manoeuvre. The clone is kept with startup option = no and otherwise, has the same machine configuration (including MACs).

You could do one of two things:

1. Check, were that VPN traffic is going to and block those IPs / ASN in the cloud. That will work only if there is some fixed couterpart in the cloud where this is headed to.

2. Install a proxy and transparently redirect all traffic that goes to port 443 on outbound connections to that proxy. If the traffic does not adhere to HTTPS standards, it will be blocked. If it does, you can see where it is going to because of SNI and block that site.

If it (half-)works for you with an MTU of 1492, then fine.

The usual remedy for solving the problems that arise from a 1492 MTU on WAN would be to use MSS clamping, such that all LAN clients including your LAN interface can use the default 1500 byte MTU, but the packets are repackaged to the lower WAN MTU.

However, I remember having read several reports to the extent that this clamping functionality is broken with newer OpnSense releases, so YMMV.

The chain is WAN->PPPoE->VLAN, otherwise, it would not work at all.

Yes, IPv6 uses a smaller MTU. mail.yahoo.com does in fact resolve to IPv6, so if you have that configured, it will be used first.

If the script shows 1334 when using 8.8.8.8 as destination, then there is something seriously wrong with your ISP.

Die typischen SFP+-Karten sind Intel X710 und X520-DAx. Letztere ist uralt, bekommt man aber billig als Nachbau oder gebraucht von Dell oder HP.

Does that happen only when (one of) your Proxmox host restarts or also if you only restart the OpnSense VM?
And what do you mean with a "2 PC cluster"? Is that a Proxmox cluster?

Some ISPs do not allow multiple MACs to be seen on their networks - or at least to wait a certain time before the router changes, which could explain the 30 minute timeout before you get a new WAN IP.

Although you have configured your vmbr1 to not have any IP, so it should not communicate, it may be that during PVE bootstrap, it does something on the WAN interface. If you use a Proxmox cluster with both hosts connected to your modem, the second host could be responsible for that.

You could try to use a single connection for enp2s0 and maybe try to do a passthru (normally, I would not recommend that). This would be only to rule out that either Proxmox host would do something to that interface during bootstrap.

Nein, das Telekom Glasfaser Modem 2 ist eine reine Bridge. Die Einwahl erfolgt durch die OpnSense per PPPoE.

Bei den meisten ISPs wäre HA aber auch keine Option, nicht einmal mit DHCP - zumindest nicht ohne Tricks. Die DG beispielsweise akzeptiert keinen (schnellen) Routerwechsel, es darf nur eine DUID aktiv sein, sonst muss man eine Stunde warten. Andere Provider prüfen die MAC. Wenn Du also zwei OpnSensen über einen Switch an den selben ONT anschließt, bekommst Du auch da ein Problem.

Der Cold Standby ist da wohl die beste Variante. Im übrigen: Der ONT ist ja auch ein Single Point of Failure. Hast Du dafür einen Klon parat? Ich schon!

The DNS overrides for DHCP reservations over the subnet defaults currently do not work, at least for Kea, see this.

With VLANs, you can use switches acting like multiple switches in one box - logically, it is the same as having multiple separate interfaces on your router (with different subnets) connected to one switch each. That way, you can keep separate subnets of varying trust. With VLANs, you can have those separate switches combined into one.

If you do not want one switch per subnet, your switch(es) need to be able to handle VLANs, though, so they need to be "managed". With VLANs, you can use just one physical interface to carry all of your VLANs (which are logical interfaces) over one physical port (aka "trunk") to the switch and then fan out each VLAN on specific "access" ports for each client.

Who is berating you in here? I just does not work like that, that is about it. Many people come in here because they come with hopes or beliefs that are technically infeasible or incorrect. Like OpnSense is just a "more secure" consumer router - which it is not.

That set aside, you can use different subnets for different interfaces, yes, but: WLAN = 10.10.10.1/24 and LAN = 10.10.10.2/32. Those overlap, don't they?


Basically, you can set up your ports in one of two ways:

1. Bridged (like a switch), then you have to follow the docs for a bridged setup. That is how many consumer routers do it, when they combine the internal ports like in a switch.

2. Routed, where you have multiple networks on different ports (or VLANs).

You tried to go in-between, which is not possible.

If at all, you would have to separate your 10.10.10.0/24 subnet into two subnets like 10.10.10.0/25 and 10.10.10.128/25. In that case, the interfaces would have 10.10.10.1/25 and 10.10.10.129/25 assigned. I would not do that, because it will become very confusing.