OPNsense in virtueller Maschine

[Gustav G. (gustavgggg)]

Ich suche eine Lösung für folgendes Szenario: Ich habe einen Server mit 
4 Netzwerkkarten woraud debian läuft, ein externen Router + Model 
(Fritzbox). Auf diesem Server soll OPNSense in einer virtuellen Maschine 
(KVM) laufen und ich möchte das mit virt-manager konfigurieren.

OPNSense soll mit der Fritzbox verbunden sein und dem server die 
Internetverbindung geben. An anderen Ports sollen geräte verbunden sein, 
die Wahlweise ins Internet können oder auch nicht. Kennt dazu jemand ein 
Tutorial. Ich verstehe das mit diesen Netzwerkbrücken nicht.

[Εrnst B. (ernst)]

Hatte das (fast) genauso laufen.

Außen, also im debian, für jedes Interface eine Bridge anlegen, das 
eth-device da rein, bei denen die nur für die Firewall sind: keine IP 
konfigurieren, erst recht kein DHCP.

# /etc/network/interfaces(.d/...)
auto enp0s20f2
iface enp0s20f2 inet manual
iface enp0s20f2 inet6 manual

auto br_wan
iface br_wan inet manual
        bridge_ports enp0s20f2
        bridge_maxwait 8
iface br_wan inet6 manual

auto enp0s20f3
iface enp0s20f3 inet manual
iface enp0s20f3 inet6 manual

auto br_office
iface br_office inet manual
        bridge_ports enp0s20f3
        bridge_maxwait 8
iface br_office inet6 manual

# usw.

Geht auch mit VLANS usw.

Bei neueren Distros ohne "if-up":
Netplan-Config, Networkmanager, systemd-networkd etc analog 
konfigurieren.

dann für die libvirt/VirtManager-VM:

<interface type='bridge'>
  <source bridge='br_wan'/>
      <model type='virtio'/>
...

Bzw. im VirtManager entsprechend zusammenklicken.

Tipp: Merk dir die MAC-Adressen, die der VirtManager da vergibt, damit 
findest du die Netzwerk-Devices im OpnSense leichter.

Falls du keine Netzwerkverbindung bekommst: Es kann sein dass die 
Firewall am Host-Debian das unterbindet. Entweder dort entsprechende 
Regeln hinterlegen, oder die Bridge auf "Durchzug" schalten:

#/etc/sysctl.d/20-bridge-allow.conf
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

[Gustav G. (gustavgggg)]

Danke. Ich vergaß noch zu erwähnen, dass auf dem Host nocht andere 
virtuelle Maschinen oder Docker Container laufen sollen. Kann ich dann 
zu denen irgendwie routen?

[Εrnst B. (ernst)]

Gustav G. schrieb:
> Kann ich dann
> zu denen irgendwie routen?

ja, natürlich. Die Bridge für das interne Netz braucht dafür nur eine 
IP. Also einfach in der "/etc/interfaces" Config mit vergeben.

also

auto enp0s20f0
iface enp0s20f0 inet manual
iface enp0s20f0 inet6 manual

iface br_lan inet static # statt "manual"
  bridge_ports enp0s20f0
  address 10.1.2.3
  gateway 10.1.2.1 # IP vom OPNsense auf der bridge
  dns-nameservers 10.1.2.1 # auch OPNsense
...

dann (optional) die docker-container ihre Ports auf die 10.1.2.3 binden 
lassen

Und entsprechende Regeln im OPN-Sense die auf die 10.1.2.3:<port vom 
docker> weiterleiten.

[Gustav G. (gustavgggg)]

Warum gebe ich denn zum Beispiel br_wan keine feste IP?

[Εrnst B. (ernst)]

Gustav G. schrieb:
> Warum gebe ich denn zum Beispiel br_wan keine feste IP?

Weil du damit dem Sinn der Firewall verlierst:
Jede Bridge im Host-Linux ist dort auch immer ein Netzwerk-Device. 
Sobald die eine IP hat, wäre die auch erreichbar. Ungefiltert, an der 
OPNSense-Firewall vorbei.

[Gustav G. (gustavgggg)]

Εrnst B. schrieb:
> Weil du damit dem Sinn der Firewall verlierst:
> Jede Bridge im Host-Linux ist dort auch immer ein Netzwerk-Device.
> Sobald die eine IP hat, wäre die auch erreichbar. Ungefiltert, an der
> OPNSense-Firewall vorbei.

Aber zur Verbindung mit der Fritzbox, die als Gateway dient braucht das 
ja eine IP oder konfiguriere ich das in opnsense?

Ich will zum Beispiel an einem Port auch unsichere Geräte haben, die 
zwar mit Geräten aus einem Adressbereich Reden dürfen aber nicht ins 
Internet sollen. Irgendwelche Gammel China 3D Drucker eben.

[Εrnst B. (ernst)]

Kommt halt darauf an, was du machen willst.

Entweder Firewall "für alles", dann darf die Fritzbox nur mit der 
Firewall und sonst nix kommunizieren.

Oder Firewall "für manches", dann hängt die Firewall einfach als 
zusätzliches Gerät im Netzwerk der Fritzbox, und kann diverse gefilterte 
Netzwerke verwalten, die vom Fritz-Netzwerk isoliert sind.

in beiden Fällen kannst du hinter dem OPNsense (mehrere) eigene 
Netzwerke z.B. ("China-Gadget", "IOT", "TV und FireStick"), und 
definieren wer mit wem und dem Internet reden darf.

Vielleicht solltest du dir vorher einen Plan machen, was du erreichen 
willst.

[Frank K. (fchk)]

Du solltest Dich mal mit Proxmox beschäftigen. Das hat auch kvm/qemu als 
Basis für virtuelle Maschinen, aber die Verwaltung ist um zwei 
Zehnerpotenzen besser. Backups/Restore gehen viel einfacher 
(ausprobiert). Die haben da inzwischen auch auch Software Defined 
Networking, was ich aber bislang nicht genutzt habe.

https://pve.proxmox.com/pve-docs/chapter-pvesdn.html

Und zu OpenSense: Wenn Deine Netzwerkinterfaces eigene PCI-Devices sind, 
kannst Du zumindest das externe Interface in die OpenSense VM 
ausreichen, so dass selbiges den ausschließlichen Zugriff darauf hat. 
Der Proxmox-Host hat dann überhaupt keinen Zugriff mehr auf das 
Interface, und die Abschottung ist dann auch vollkommener. Die anderen 
Interfaces kannst Du nach Bedarf exportieren.

Manche Leute betreiben auch ein Truenas als VM im Proxmox und 
exportieren den SAS-Controller in die Truenas-VM. Nur mal so als Idee.

fchk

[Gustav G. (gustavgggg)]

Εrnst B. schrieb:
> Entweder Firewall "für alles", dann darf die Fritzbox nur mit der
> Firewall und sonst nix kommunizieren.

Genau sämtlicher Traffic vom Internet und zum Internet soll über 
opnsense gehen ohne Ausnahme.

Ich habe mal das Bild angehängt wie ich es mir vorstelle. PC und Drucker 
sollen ins Internet können (Vielleicht mit bestimmten Sperren) und mit 
den China Gadgets eine TCP Verbindung aufbauen können aber die China 
Gadgets sollen nicht ins Internet können oder von sich aus mit anderen 
Dingen im Netzwerk kommunizieren können.

Die Docker/VM Instanzen sollen variabel entweder ins Internet können 
oder nicht und PCs sollen zu diesen eine Verbindung aufbauen können. Der 
Server selbst soll ins Internet dürfen aber über die Firewall.

Von außen sollen Portfreigaben an Docker/VM Instanzen erlaubt sein.

[Gustav G. (gustavgggg)]

Frank K. schrieb:
> Du solltest Dich mal mit Proxmox beschäftigen.

Das hatte ich mir angesehen aber ich würde reines Debian bevorzugen, 
auch wenn das auf Debian basiert.

[Frank K. (fchk)]

Gustav G. schrieb:
> Frank K. schrieb:
>> Du solltest Dich mal mit Proxmox beschäftigen.
>
> Das hatte ich mir angesehen aber ich würde reines Debian bevorzugen,
> auch wenn das auf Debian basiert.

wieso?

fchk

[Gustav G. (gustavgggg)]

Frank K. schrieb:
> wieso?
>
> fchk

Weil der Preis dafür pro Jahr einfach da ist. Ich will das jetzt einmal 
einrichten ohne laufende Lizenzkosten. Habe dazu einen HPE DL380 recht 
günstig gebraucht bekommen.

[Thomas W. (dbstw)]

Gustav G. schrieb:
> Frank K. schrieb:
>> wieso?
>>
>> fchk
>
> Weil der Preis dafür pro Jahr einfach da ist. Ich will das jetzt einmal
> einrichten ohne laufende Lizenzkosten. Habe dazu einen HPE DL380 recht
> günstig gebraucht bekommen.

Noe. Du gekommst zwar eine Warnung, wenn Du die kostenpflichtigen 
Archive benutzen willst, aber trotzdem funktioniert alles. Update gibt 
es natuerlich nicht, nur Update des zugrundeliegenden Debians bekommst 
(fuer umsonst).

Zudem ist der Preis von ca. 110EUR/Jahr mehr symbolisch zu sehen (Einmal 
Essen gehen mit zwei Personen sind z.z. 60 - 80 EUR in Berlin).

[Frank K. (fchk)]

Gustav G. schrieb:
> Frank K. schrieb:
>> wieso?
>>
>> fchk
>
> Weil der Preis dafür pro Jahr einfach da ist. Ich will das jetzt einmal
> einrichten ohne laufende Lizenzkosten. Habe dazu einen HPE DL380 recht
> günstig gebraucht bekommen.

Du weißt aber schon, dass Du NICHT unbedingt eine Subscription kaufen 
musst, auch wenn das Proxmox freuen würde? Du darfst das auch ohne 
Subscription verwenden.

Das einzige ist das Repos für Updates. Da musst Du dann eben das 
No-Subscription Repo nehmen.

deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

fchk

[Gustav G. (gustavgggg)]

Frank K. schrieb:
> Das einzige ist das Repos für Updates. Da musst Du dann eben das
> No-Subscription Repo nehmen.

Das weiß ich dennoch möchte ich auch aktuellste Updates haben.

[Frank K. (fchk)]

Gustav G. schrieb:
> Frank K. schrieb:
>> Das einzige ist das Repos für Updates. Da musst Du dann eben das
>> No-Subscription Repo nehmen.
>
> Das weiß ich dennoch möchte ich auch aktuellste Updates haben.

Das sind aktuelle Updates. Die sind noch neuer als die im 
Subscription-Repo, weil die nicht so gut getestet wurden.

fchk

[Εrnst B. (ernst)]

Gustav G. schrieb:
> Genau sämtlicher Traffic vom Internet und zum Internet soll über
> opnsense gehen ohne Ausnahme.

Anmerkungen zu deinem Plan:
eth0 sollte am Debian keine IP haben, um zu verhindern dass da Docker 
oder sonstwas dran bindet, Routen darauf gelegt werden usw.

br_lan mit eth1 braucht eine passende IP aus deinem Heim/LAN-Netz.

Für eth2 brauchst du auch eine Bridge, um das Device an OPNsense zu 
verbinden. Hab die mal einfach "br_gadget" genannt.

OPNsense kommuniziert über die br_lan und dessen IP mit den 
Docker-Containern. Deine zusätzlich eingezeichneten Direktverbindungen 
lässt du lieber bleiben.
Auch die Verbindungen zwischen Docker und br_lan würde ich erstmal nicht 
als bridge-membership der virtuellen Interfaces im Docker-Container 
machen, sondern klassisch über exposed ports und routing.

Wenn die China-Gadgets irgendwas direkt am Debian-Server/Docker 
erreichen sollen, braucht die br_gadget Bridge auch eine IP, diesmal aus 
dem "Gadget"-Netzwerk.
Ohne br_gadget IP müssen die über OPNsense gehen, das kann dann die 
Verbindungen auf die IP am br_lan um-NAT-en.

[Gustav G. (gustavgggg)]

Danke für deine Anmerkungen. Ich habe das jetzt einmal überarbeitet mit 
Adressen, die ich dann innerhalb von opnsense vergebe.

Fritzbox bekommt eine statische IP und ist das Gateway zum Internet, was 
ich auch so in opnsense konfigurieren kann. Innerhalb der opnsense 
Maschine bekommt der Port dann eben die 192.168.1.2 als Adresse.

Für die drei anderen Ports setze ich eben im virt-manager die verbindung 
zu den anderen Brücken und vergebe in opnsense dann auch eine feste 
Adresse.

Innerhalb der firewall kann ich dann Regeln erstellen (sofern das so 
einfach geht), damit ich die Kommunikation bestimmen kann. Erster 
schritt wäre einfach mal DHCP, docker und einen Zugriff der PCs zum 
Internet zu ermöglichen.

Ein erreichbarer SSH Server wäre noch sinnvoll. Da muss ich openssh dann 
nur mitteilen, dass es auf z.B. 192.168.2.1 horchen soll, oder?

[Gustav G. (gustavgggg)]

Ich habe zu dem letzten Diagramm noch eine Frage. Kann ich denn zum 
Beispiel den Docker container docker0 von PC1 aus erreichen? eth1 muss 
dazu noch eine ip haben, oder?

[Εrnst B. (ernst)]

Gustav G. schrieb:
> Kann ich denn zum
> Beispiel den Docker container docker0 von PC1 aus erreichen? eth1 muss
> dazu noch eine ip haben, oder?

Deswegen meinte ich: Lass das Docker "normal" laufen, also ohne dass du 
da irgendwelche Super-Sonder-Spezial-Netzwerkconfigs anwendest, und 
direkt die Bridges da reinverbindest.
Kann man zwar machen, wenn man sich da reinfuchst, aber ist eher nix für 
Anfänger.


Standard-Config von Docker wäre: Die Container innen kriegen eine 
Adresse aus dem 172.16.0.0/12-Bereich, vergeben von Docker.
Docker verbindet Ports von Außen (z.B. 192.168.2.1:80) in den 
Docker-Container hinein, und kümmert sich selber um die dafür nötigen 
Netzwerk/NAT/Firewall-Geschichten.
Allerdings: Wenn du's nicht explizit angibst, bindet Docker den 
"äußeren" Port an 0.0.0.0:80, das wäre dann auch aus "unsafe" und "wifi" 
erreichbar.

[Gustav G. (gustavgggg)]

Εrnst B. schrieb:
> Standard-Config von Docker wäre: Die Container innen kriegen eine
> Adresse aus dem 172.16.0.0/12-Bereich, vergeben von Docker.
> Docker verbindet Ports von Außen (z.B. 192.168.2.1:80) in den
> Docker-Container hinein, und kümmert sich selber um die dafür nötigen
> Netzwerk/NAT/Firewall-Geschichten.
> Allerdings: Wenn du's nicht explizit angibst, bindet Docker den
> "äußeren" Port an 0.0.0.0:80, das wäre dann auch aus "unsafe" und "wifi"
> erreichbar.

Es kann ja folgendes Szenario sein, dass mehrere Docker Container einen 
Webserver laufen haben, der auf Port 80 hört. Das würde doch kollidieren 
wenn ich den Server von PC1 erreichen möchte.

[Εrnst B. (ernst)]

Gustav G. schrieb:
> Es kann ja folgendes Szenario sein, dass mehrere Docker Container einen
> Webserver laufen haben, der auf Port 80 hört. Das würde doch kollidieren
> wenn ich den Server von PC1 erreichen möchte.

Die Ports innerhalb und ausserhalb vom Docker-Container müssen nicht 
gleich sein.
Du kannst 10 Webserver-Docker-Container starten, und die z.B. auf
192.168.2.1:80, :81, :82 ... :90 verteilen.

Oder du kannst AM br_office Alias-IPs vergeben, und die Webserver über
192.168.2.1:80, 192.168.2.2:80, 192.168.2.3:80 usw. erreichbar machen.
Oder du kannst beides mischen.

Aber: Dabei ist nie eine 192.168.2er IP IM Docker-Container. Die 
sind immer Außerhalb.

[Tobias P. (hubertus)]

Ich habe das bei mir exakt so am laufen, allerdings mit 4 VLANs, da ich 
nur 1 Netzwerkkarte mit 1 Kabel haben will.

Über das Glasfaserkabel kommt auf VLAN 10 das WAN rein. Dort ist eine 
Linux Bridge, br10. Diese ist auf die opnsense Firewall durchgereicht 
und erscheint in der VM wie eine echte Netzwerkkarte.

Dann habe ich noch br20, br30 und br100 für Gästenetz, DMZ und LAN. Jede 
dieser Bridges ist zur opnsense VM durchgereicht und erscheint genauso 
wie WAN als Netzwerkkarte.

Wenn ich einen Container oder VM anlege, dann muss ich entsprechend 
diesen mit br20, br30 oder br100 verbinden und der landet dann im 
richtigen Netz.

Die Bridges dürfen, wie weiter oben gesagt wurde, ausser dem Namen 
überhaupt nichts konfiguriert haben, damit durch diese der Host nicht 
erreichbar ist!

Es gibt eine Ausnahme, auf br100 habe ich eine IP konfiguriert auf dem 
Host, dadurch wird dieser über VLAN 100 ansprechbar.

Bei dir dementsprechend auf dem zugehörigen Netzwerkport, da du ja 
mehrere Ports hast. Einfach für jeden Port eine Bridge anlegen und diese 
sowohl mit der opnsense als auch mit dem physikalischen Port verbinden!

Gruss

[Gustav G. (gustavgggg)]

Εrnst B. schrieb:
> Oder du kannst AM br_office Alias-IPs vergeben, und die Webserver über
> 192.168.2.1:80, 192.168.2.2:80, 192.168.2.3:80 usw. erreichbar machen.
> Oder du kannst beides mischen.

Wenn ich in einem Docker compose file einfach nichts für network 
konfiguriere wie erreiche ich diesen Container dann und wie kenne ich 
dessen IP Adresse? Mit ip address sehe ich die Bridges, die Docker 
anlegt mit den Adressen 172.x.x.1. Das mit dem Alias verstehe ich 
überhaupt nicht.

Tobias P. schrieb:
> Bei dir dementsprechend auf dem zugehörigen Netzwerkport, da du ja
> mehrere Ports hast. Einfach für jeden Port eine Bridge anlegen und diese
> sowohl mit der opnsense als auch mit dem physikalischen Port verbinden!

Die bridge mit dem physikalischen Port verbinden heißt, dass ich in 
/etc/network/interfaces die bridge anlege? Muss eth0-eth4 denn nun eine 
IP Adresse haben?

[Tobias P. (hubertus)]

Gustav G. schrieb:
> Die bridge mit dem physikalischen Port verbinden heißt, dass ich in
> /etc/network/interfaces die bridge anlege? Muss eth0-eth4 denn nun eine
> IP Adresse haben?

du musst bei "bridge-ports" den physikalischen Port angeben, zb so

auto vmbr_100
iface vmbr_100 inet manual
        bridge-ports ens1f0.100
        bridge-stp off
        bridge-fd 0
        post-up echo 1 > /proc/sys/net/ipv6/conf/vmbr_100/disable_ipv6

das würde eine Linux bridge anlegen namens vmbr_100 und würde diese mit 
dem physikalischen Port ens1f0, VLAN 100, verbinden.

Die Bridge funktioniert dann wie ein Switch, alle VMs, die du mit dieser 
Bridge verbindest, können einander "sehen".

Du hast kein VLAN, dann würde es bei dir zb. so aussehen

auto myfancybridge
iface myfancybridge inet manual
        bridge-ports eno3
        bridge-stp off
        bridge-fd 0
        post-up echo 1 > /proc/sys/net/ipv6/conf/myfancybridge/disable_ipv6

wenn du mit eno3 verbinden willst.

Wichtig ist auch der Teil mit dem disable IPv6: wenn du einen Router 
betreibst, der IPv6 Router Advertisements herum schickt, dann wird dein 
Host diese empfangen, auswerten und sich mit IPv6 konfigurieren. Das 
möchtest du für das WAN Interface AUF KEINEN FALL, weil dann sonst dein 
Host per IPv6 aus dem WAN direkt ansprechbar wäre, unter Umgehung der 
Firewall!

Ob deine Bridge richtig konfiguriert ist, musst du unbedingt überprüfen, 
zb mit idconfig oder ip a. Die bridge selbst darf nur eine MAC Adresse 
aufgelistet haben, keine IPv4, keine IPv4, keine Netzmasken, keine 
Routen, einfach nichts. Andernfalls kann der Host über diese Adresse 
erreicht werden, wie gesagt, beim WAN Port wäre das fahrlässig.

[Gustav G. (gustavgggg)]

Alles klar das habe ich verstanden. Eine Bridge ist im Grunde ein 
virtueller Switch, womit ich alles verbinden kann. Wo ist jetzt der 
Unterschied dieser Brige eine IP zu geben oder nicht? Wenn ich zum 
Beispiel eine Bridge mit eth0 verbinde und der Brücke eine Adresse gebe, 
sagen wir 192.168.1.1/24, kann sich dann eth1 mit etwas in diesem 
Adressbereich verbinden? Ich denke nicht, denn dazu bräuchte es eine 
Route.

Die Frage ist aber dennoch wie ich Docker container im host erreichbar 
mache und wie diese für PCs erreichbar sind, wenn die alle einen 
Webserver laufen haben.

[Tobias P. (hubertus)]

Gustav G. schrieb:
> Wo ist jetzt der Unterschied dieser Brige eine IP zu geben oder nicht?
> Wenn ich zum Beispiel eine Bridge mit eth0 verbinde und der Brücke eine
> Adresse gebe, sagen wir 192.168.1.1/24, kann sich dann eth1 mit etwas in
> diesem Adressbereich verbinden? Ich denke nicht, denn dazu bräuchte es
> eine Route.

im Prinzip ja. Aber ich würde es trotzdem nicht machen. Wenn einer in 
dein Netzwerk einbricht und da irgend was rum fummelt, kann er dann 
vielleicht doch dein Interface ansprechen.
Es genügt ja, wenn man die IP kennt, dann kann man auch ohne Route 
kommunizieren, wenn man im selben Subnet ist.
Ausserdem möchtest du genau definieren, auf welchem Interface dein Host 
erreichbar ist - wenn jede Bridge eine IP hat, erreichst du den selben 
Host mit mit mehreren IPs, das kann erwünscht sein, kann aber auch eine 
Sicherheitslücke sein - zB aus dem DMZ Netz soll man ausser dem Internet 
gar nichts erreichen können. ZB dein Webserver läuft im DMZ Netz; wenn 
ein Scriptkiddie in deinen Webserver einbricht, dann könnte er deinen 
Host ansprechen. Das möchte man u.U. nicht. Deshalb den Bridges keine IP 
geben, AUSSER man will da auch den Host drüber erreichen.