Messages

Solange der Rechner im LAN ist, kann er dort alles erreichen, daran kann OpnSense erst einmal nichts ändern.

Der normale weg wäre also, den Rechner in ein eigenes (V)LAN zu tun, mit einem eigenen Subnetz - das kann im Extremfall auch nur ein einzelnes, direkt mit dem Rechner verbundenes Interface sein. OpnSense würde dann als Router fungieren und kann somit den gesamten Verkehr filtern.

Der Rechner hat dann allerdings keine IP im LAN mehr, sondern eine in dem neuen (V)LAN.

Ansonsten gäbe es theoretisch die Möglichkeit, eine transparente Bridge einzurichten, siehe OpnSense Dokumentation. Die Topologie ist die selbe, ich weiß allerdings nicht, ob ein Mischbetrieb möglich ist, also OpnSense als Hauptrouter und gleichzeitig transparente Bridge für ein einzelnes Interface. Und OpnSense ausschließlich für einen einzelnen Rechner zu verwenden, klingt ein wenig nach Overkill.

Es spricht ja nichts dagegen, die Block-Regeln für manche Blacklists auch auf internen Interfaces zu machen - das geht bei Floating Rules ja sehr einfach. Man muss aber bedenken, dass manche Listen auch RFC1918 umfassen, z.B. FireHol 1 oder dass man eventuell bei GeoIPs China und Russland eventuell nur inbound (d.h. auf dem WAN) blocken will.

That depends on your OS and/or network configuration method.

Essentially, you do not configure IP/26, but IP/32. The problem is that now your gateway IP lies outside of your subnet.

In Linux, you can set up an interface with the option "pointopoint", such that it can be a far gateway. You only specify the interface over which it is to be reached.


Hetzner now documents exactly that here for /etc/network/interfaces and also for netplan setups.

For OpnSense, you define the WAN interface IP with a netmask of /32 and set the "IPv4 gateway rules" to your gateway, in which you check both "Upstream Gateway" and "Far Gateway" and select the WAN interface and gateway IP.

It seems you have not set up DHCP on your LAN. This looks like if you configured your LAN client statically and forgot to add 192.168.1.1 as default gateway. The gateway should be provided if you use DHCP, as well as the DNS server.

Otherwise, all looks fine, although you do not need that WAN rule.

If you try a random IPv6, the Query Forwarding will not kick in. I actually tried a specific IPv6 within a delegated prefix. Then I pinged from that prefix and looked at the live firewall logs. Before I had the query forward, there was a reverse name, after, there was none - but still immediate.

You must get the ip6.arpa domain right, filling up the zeros and not set "forward first".

Yes. There are links in the original article, pointing to instructions on enabling RSS.

Please disable the traffic shaper to test if that has any impact, regardless of having set the correct limits. Same goes for any type of IDS.

Have you tried creating a "Query Forwarding" entry with the same reverse domain and 127.0.0.1 / 53 as the Server IP / Port? Works like a charm for me. I think this may even deliver the correct names if you used DHCPv6, but IDK.

Hier sind meine typischen Interface-Regeln (wie gesagt, abgesehen vom Management-VLAN):

You cannot view this attachment.

Wie Du siehst, nutze ich anstelle von RFC1918 "LOCAL_VLANS net", wobei das die Gruppe aller lokalen Interfaces ist.

So sieht es bei den Floating Rules aus:

You cannot view this attachment.

(Dabei kommen oben drüber übrigens noch Block-Regeln für Emerging Threats, Firehol usw., aber nur für das WAN, weil die Floating-Regeln vor NAT-Regeln mit implizitem "PASS" gezogen werden und sonst Port-Forwards weit offen stünden.)

An sich stehen da aber wie gesagt zunächst Dinge, die "jeder braucht", wie DNS, dann die einzelnen Dienste. Was man in der Übersicht nicht sieht, sind die erlaubten Interfaces, meist steht es im Kommentar. RESTRICTED sind die niedriger privilegierten VLANs.

Und nein, ausgehend filtere ich nichts. In den weniger privilegierten Netzen ohnehin nicht - soll ich mit jemand, der mein Gast-Netz diskutieren, warum irgendwas nicht funktioniert? Oder bei IoT: Der Punkt ist doch, dass ich dort sowieso nicht kontrollieren kann, was die Cloud-Devices tun (nimm an, sie nutzen die "Phone-Home"-Verbindung auf dem "legalen Port 443", um rückwärts einen Proxy in das lokale Netz aufzubauen). Das ist ja gerade der Grund, warum diese VLANs isoliert sind. Auf keinen Fall will ich da jeder Anwendung hinterher turnen und dann nur das öffnen, was die jeweils braucht.

Im Grunde gilt das selbe im LAN: Aufgrund der Tatsache, dass ich den Verkehr im Tunnel nicht kontrollieren kann, ohne ihn aufzubrechen, könnte Malware potentiell sowieso alles unbeobachtet tun. Ich könnte höchstens verhindern, dass bestimmte Command&Control-Server kontaktiert werden.

Adblocking mache ich anders und Kinder oder Angestellte, die ich reglementieren will, habe ich nicht.

All das kann man natürlich on top noch tun, bei mir sind es nur die zusätzlichen Inbound-Regeln, wie gesagt.

Hmm. Ich habe hier zwei Fragen:

1. Was heißt "OPNsense blockiert ausgehend, so Bedarf das eigentlich ein Umdenken."? Das ist eigentlich nicht so vorgesehen. Normalerweise blockt oder erlaubt man bei OpnSense nur mit "in" Rules. Oder wie meinst Du das?

2. Wenn Du nur 3 VLANs hast, dann helfen Dir die "Bereiche" oder "sortingnetze" doch nichts, weil innerhalb eines VLANs jeder mit jedem frei kommunizieren kann? D.h. "sonst wenn sich Rule in einem Netz befindet" ist doch irrelevant? Es läuft darauf hinaus, dass Du keine Regeln innerhalb eines VLANs brauchst, bzw. diese unwirksam wären.

Ich mache das eigentlich so, dass ich zunächst jedes VLAN mal gegen RFC1918 abschotte (außer den höher privilegierten VLANs, also z.B: Management) - die dürfen alles. Abgesehen davon dürfen die aber auch jedes Ziel, also ins Internet. An sich ist es ziemlich egal, ob wir über ein IoT-VLAN sprechen, ein normales Client-VLAN oder ein Gast-VLAN - ohne Internet geht meist sowieso nichts.

Danach muss ich mir nur noch überlegen, welche Dienste ich habe, die trotzdem geöffnet werden müssen, dass mache ich mit PASS-Regeln davor. Sofern es zentrale Dienste wie DNS, NTP o.ä. sind, richten die sich sowieso an "This Firewall" und können für alle Netze oder Gruppen (ich habe eine für die "weniger privilegierten VLANs") in den Floating Rules freigegeben werden.

Sind es spezielle Services, wie z.B: Zugriff auf einen Fileserver im LAN, definiere ich einen Alias für die erlaubten Clients und einen für die zum Service gehörigen Ports und erlaube es per Floating PASS-Regel. In den Interface-Regeln sind eigentlich nur die Block-RFC1918 und die Pass-Any-Regeln, abgesehen natürlich von WAN-Regeln.

Zur Organisation kann man Categories nutzen, danach lässt sich die Anzeige auch filtern, wenn das zu viele Regeln werden.

Neuerdings gibt es auch die "Automation"-Sektion, das habe ich aber noch nicht genutzt.


Mehr VLANs habe ich nur in einem Kontext: Wenn ich tatsächlich Services auf einem Hosting-Server (innerhalb Proxmox) trenne, weil diese aus dem Internet erreichbar sind und isoliert sein sollen. Dann nutze ich auf Proxmox eine "VLAN-aware" Bridge, auf dem für jeden Server ein VLAN aufliegt. Aber selbst dort brauche ich nur Gruppenregeln, weil diese Server untereinander keine Berziehung haben und von der Firewall aus (wo der Reverse Proxy läuft) ist sowieso jeder erreichbar - die Anzahl der Regeln dort ist also auch überschaubar. Es ist allerdings pro Server ein VLAN in OpnSense - Proxmox "kennt" diese aber natürlich nicht.

Do you actually see blocked websites or are these just random log entries? One that you posted is from Google and it has a FIN-ACK state.

Therefore, potentially, you see artifacts from QUIC traffic - I see those, too.

You can test if you allow HTTP3/QUIC traffic and see if the test triggers those log entries. Wait a bit, it may be that the TCP stream must be closed to cause a log entry.

Yes, #10 regarding the CPU speed? I tried an updated Xeon E3-1260LV5 CPU with no change. Or did I miss something in that post?

So, did you actually try the tips in the link I posted in #1?

No. follow this link and look in point 10 in the first posting. There is more than one tip w/r to low speeds.

Yup! I use LXCs or VMs on Proxmox, which can both be placed on VLANs that are separate from Proxmox's control plane. By strictly using reverse proxies, the default route is mostly irrelevant, because the caller is always the internal IP of the reverse proxy. You have to take steps to pass the remote caller IP via HTTP headers, in order to be able to know who the original caller was in the backends.

And my Docker installation is in a separate VM. To be exact, I have two Docker VMs, one for containers reachable from outside and one internal only.

Damn. Than I need to create a VM. (I wanted to skip this part since its one more thing to learn from zero, when the only goal is to get my website server up and running again 😅)

What I do not quite understand then is how you separated your docker containers in VLANs, like you said you did? Patrick says that is not possible when running containers under Truenas?

Have I summarized it correctly? 🤔 (I write like this to see if I understand it or if I have broken logic)

Yes. With the "other" approach I described in my first answer (i.e. the usual OpnSense one, not the one involving Cloudflare), you would install the reverse proxy on OpnSense itself and then direct the backends to different webservers on isolated VLANs. You would not use a separate Nginx reverse proxy, but one on OpnSense itself, like Caddy or HAproxy (both have HOWTOs in the tutorial section of the forum).

Logically, both do the same thing: You terminate the TLS traffic in a reverse proxy (your own or using cloudflare), then the traffic is passed to an isolated webserver that can do no harm if hacked. Cloudflare just happens to provide these topics:

1. Certificate issuance.
2. "Finding" your backend (which would otherwise be done via dynamic DNS)
3. Reverse proxying and tunneling the traffic to your end.

That looks fine. You do not need to separate cloudflared from nginx, but it does not hurt, either.

IDK if TN directly supports docker containers, if so, keep in mind that true VMs provide a better isolation than lightweight containers, like Docker, LXC or their likings.