Messages

Two things come to mind:

1. UFS installation gone awry? Reinstall on ZFS and restore your config.
2. Hardware defect? Replace it.

IDK anything about SDN in Proxmox, sorry. Never saw the need for that.

All I can tell you is that with your previous setup, where you had your LAN on VLAN 20 access ports and the Proxmox host as trunk, you can do it with the setup I posted, such that the Proxmox host IP map also to the LAN on VLAN 20.

You can then configure the vtnet0 on OpnSense to vmbr0 and set up the LAN on VLAN 20 as well to access all of that LAN and deliver DHCP and DNS services to it. vtnet1 would then be exclusively used for WAN.

There are some things missing:

1. You do not specify VLAN awareness and which VLANs can be used, so your OpnSense cannot access VLAN 20.
2. Use a netmask or /24, not both.
3. Other things are missing, like bridge-mcsnoop, which is also in this guide: https://forum.opnsense.org/index.php?topic=44159.0

Details matter.

From what I get is that your LAN NIC is attached to one of the ports 13-18 on your switch?

In that case, if you change the vtnet0 on OpnSense to VLAN 20, what you get is a VLAN 20 in a VLAN 20 (QinQ), which certainly will not work.

You should connect the LAN NIC to port 23 (trunked) when you use LAN as VLAN 20 on OpnSense.

W/r to Proxmox, you would then have to use VLAN 20 there, too. It can be done like so:

Code Select Expand

auto eth0
iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
        bridge-ports eth0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        bridge-mcsnoop 0
#Network bridge

auto vmbr0.20
iface vmbr0.20 inet static
        address 192.168.2.5/24
        gateway 192.168.2.1
        dns-nameservers 192.168.2.1
#Proxmox LAN interface


[/12]

Ich weiß nicht, ob 172.16 so geschickt ist...

1. Es ist 172.16.0.0/12, nicht 172.16.0.0/8 - Eine 1:1-Übertragung von 10/8 ist also per se problematisch.
2. 172.16/12 wird u.a. von Docker et.al. für internes Networking genutzt - ich habe nie probiert, was dann passiert, wenn das LAN auch Adressen darauf verwendet.
3. Schau mal hier und überleg' Dir, ob nicht unter dem Gesichtspunkt einer aktuellen oder späteren Segmentierung mehrere 192.168.x/24-Netze sinnvoller sind.

Wenn Dein LTE-Modem im Bridge-Modus ist und Du wirklich die jeweils aktuelle IPv4 auf dem WAN0-Interface siehst, dann solltest Du nicht noip-ipv4, sondern "Interface [IPv4]" als Prüfmethode nehmen. Damit wird die Veränderung der Interface-IP als Anlass zum Aktualisieren genommen.

It is a known fact that Unbound takes up DHCP names for dynamic leases only dynamically. If you create a reservation, it will take an Unbound restart to pick it up.

I do not exactly know how Unbound works with DHCP services other than ISC, like Kea or DNSmasq for dynamic leases, but I assume it works the same.

But how can it be a firewall issue when the traffic is local on the LAN and never passes OpnSense?

If you want that, you could use a VPN and hide your outbound traffic behind it. A transparent proxy could only be used in order to keep your children from using websites you do not want them to - however, that could be done with a locked-down PC as well.

Then again, most tracking and tracing happens via cookies and browser fingerprinting anyway, and if you use several websites, you will undoubtedly leave traces regardless of using a proxy or a VPN.

Also, think about if you use Google DNS (or any other, for that matter). Or the Firefox "safe browsing" feature. The latter presumable only transmits "metadata" (i.e. hashes) or the URLs you browse to. That way, nobody could ever know what URLs you have visited, right?

Wrong: If you had an index of all websites and URLs together with their hashes, you could just look the URL up from the hash. And how could anyone have such a list? Well, Google comes to mind... and guess who provides that service (for "free")?

In short: While you can provide full anonymity for specific purposes with an anonymizing browser over a VPN (even TOR has been compromised already), but do not even think about using the same browser for all your needs and expect not to be tracked. And BTW: you paid anonymously for that VPN, didn't you?

No.

That should not be the problem.

First, Patrick is right: Any local IPv6 subnet should be /64 in order for SLAAC to work.

Second, the prefixes are different in your case, because of the use of IA_NA for the WAN IPv6 (which is a /128), but IA_PD, which is a /56 prefix that must be split up into several /64 addresses for each (V)LAN.

You can also check "Request prefix only" on your WAN and omit IA_NA for the WAN to use one of the IA_PD prefixes as well. In that case, WAN and LAN both use a /64 IPv6 within the same /56 prefix.

Where everything gets routed is determined by your IPv6 gateway, which should be provided by the ISP. Both variants should work, but I prefer the latter.

I refer you to look at this to better understand this.

You only need a VIP if the interface itself needs other IP ranges for WAN connectivity. With PPPoE, the underlying physical interface normally needs no IP, so you can just configure it directly on the interface. With a pure static or DHCP connection on WAN without any VLAN, you must use a VIP, because in that case, the WAN IP plus the modem access IP will be needed.

Wenn das Endgerät eine IPsec-Verbindung aufbauen will, kann es sein, dass dort ein Netzwerk-Kill-Switch wirkt, der ausschließlich Kommunikation über ein VPN-Gateway zulässt? Bei manchen VPNs muss man das lokale LAN-Subnetz explizit davon ausnehmen, und wenn sich Dein Netzwerk geändert hat, kann die Client-Konfiguration eventuell nicht mehr passen.

Was allerdings komisch ist, ist, dass der Client von anderen Clients aus funktioniert. Obwohl, Ping ist nicht gleich Ping - das hängt vom OS ab.

P.S.: Patrick meinte die Netzmaske am Client, das war schon klar, oder?

You said you did not carry over the configuration. I would try to do that and just reassign the interfaces. That way, you would be sure that there is no setting that you once had and now forgot.

[a lot]

When you open the website with a browser and turn on developer tools and look what URLs are being accessed, you will find a multitude of URLs, including:

discordapp.com
discord.gg

and maybe others. Any of those URLs / domains can enforce certificate pinning or CAA, so you would have to add all of those domains to your SSL bump sites.

You can also use the developer mode console to see which URLs cannot be loaded and add those step-by-step.

You see why I said that transparent proxying takes a lot of work, now, do you? Imagine doing that for any website you want to use....