[Sammelthread] pfSense & OPNsense (Firewall- und Routing-Appliance)

  • Ersteller Gelöschtes Mitglied 63700
  • Erstellt am
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ah. Ja passt. Cable... Das ist Puma 7 und Puma ist MaxLinear mit Intel Atom (Kernen). Das ist leider nicht grad das was man Effizient nennt.
Das wird auch anscheinend nicht besser (6670).
 
Hoffe das Ding wie gesagt im nächsten Jahr loszuwerden wenn die endlich Koiax gegen Fiber tauschen, aber solange ist es halt so. Leider gibt es für Kabel ja überhaupt keinen Standalone Modem Markt mehr.
 
Moin, ich bin gerade dabei mein OPNsense setup neu zu machen.
Mein Ziel ist: MultiWAN mit HA. Erstmal das MultiWAN als Failover, gerne später (wenn ich von LTE auf 5G gewechselt bin) als Loadbalancing.
Die primäre Sense läuft virtualisiert, die Backup-Sense ist in Hardware und wird eigentlich nur angeschmissen wenn ich sie brauche - etwaige Loss of Service bis die hochgefahren ist nehme ich in Kauf (Kirche im Dorf lassen und so...).

Das bisherige Setup sieht so aus:
1738490160108.png

Ich hab seid einiger Zeit aber kein Multi-GW mehr am Laufen, da ich damit auf manchen Clients immer wieder auf dem falschen GW landete und bei einigen Clients einfach DNS nicht so wollte. Ich hatte auch immer wieder Probleme mit einem meiner VLANs und zu allem Überfluss nutze ich noch eine .local domain.

Ziele sind also:
  • Dual WAN mit Failover Aufbau
  • Nutzung von 10 VLANs
  • Bereitstellung von 3 VLANS als WLAN
  • DHCP für alle Netze (außer VLAN 10 aka Management LAN)
  • mDNS Repeater für einfachen Airprint Druck
  • DNS im gesamten Netzwerk inklusive der Sense selber nur via Unbound
  • Alles was nicht von selber die Sense als DNS nutzt soll geblockt werden (vergleiche fester google-DNS-Fallback in Android...)
  • Wechsel von domain.local auf domain.lan
Optionale Ziele für später:
  • Aufbau einer DMZ zwischen Fritzbox und OPNsense für Dienste nach Aussen
  • Nutzung von ZFS inkl boot environments für Updates, ZFS Mirror
  • Wechsel der Hardware der physischen sense
  • Multi-Channel LAGG für meine Mikrotiks

Prämisse bei diesem Vorhaben: Netz sollte durchgehend vorhanden sein - mal für 10 Minuten hier oder da ein Schluckauf ist okay, aber dauerhaft weg darfs net sein. Der Einfachheit halber habe ich OPNsense1 ausgemacht und ziehe sie auf einer VM neu hoch.
Ich ignoriere im LAN IPv6 völlig und deaktiviere es wo ich es kann.

So, nun mein teuflischer Plan:

Als erstes wollte ich jetzt einmal meine Firewall-Regeln auf den neuesten Stand bringen und von euch crosschecken lassen, in diesem Zuge des Neuaufsetzens von (im ersten Schritt ohne CARP) OPNsense1 werde ich auch gleich diese unsägliche .local domain los die ich immer noch benutze.
Als nächstes bräuchte ich dann etwas Mikrotik-Hilfe zum Überprüfen meiner VLANs und ob das so passt, und als letztes dann CARP wierder aufbauen - so mein Gedanke.
Wenn das erst einmal ohne HA und ohne MultiGW läuft, wollte ich als nächstes Multi-GW überprüfen - hierfür muss ich dann irgendwie OPNsense2 ausmachen - das wird also tricky. Ideen dazu wie ich das hin- und her Wechseln mache? Wird ja vermutlich nicht alles auf einmal klappen...

So, Plan haben ist toll, setzen wir gleich mal den ersten Punkt um, DNS + Firewallregeln - sollte ja auch das wichtigste sein.
Ich werde einen Alias "All VLANs" benutzen, einen "All Networks" (also All VLANS + LAN), einen "Print Networks" und einen "Media Networks" . die letzten beiden sollten Selbsterklärend sein.
Ich möchte die Regeln die mehrere Netzwerke betreffen gerne als Floating Rules einbauen, damit ich sie nur einmal pflegen muss.
Das erste was stimmen muss ist also das DNS. Grundsätzlich nutze ich die IP der sense jeweils als ihren eigenen DNS, mit der jeweils anderen als sekundärem DNS:
1738492210637.png

Dann leite ich jeden DNS-Verkehr in jedem Netz auf die Sense selber um, das ist meine zweite und dritte floating Rule, frei nach https://homenetworkguy.com/how-to/configure-opnsense-firewall-rules/:
1738497186272.png

Passt das erst mal soweit? Gehe ich so in die richtige Richtung? Ich hatte das bisher als Rule pro Interface, mit Destination "Interface Address" statt "This firewall"
Ich stolperte dann auch noch hier über diesen Teil im cheatsheet:

Redirect DNS requests on LAN to Unbound DNS using NAT port forwarding​

Das würde ich auch gerne umsetzen, das kann ich ja ohne Probleme zusätzlich zur Floating Rule oben einbauen, oder?


Sodele, sorry für die Wall of Text, aber ich wills halt diesmal von Grund auf sauber aufbauen damit ich am Ende nicht wieder in einem Zustand lande in dm es zwar einigermaßen funktioniert, ich aber die Dinge die nicht funktionieren nicht verstehe...
 
Das würde ich auch gerne umsetzen, das kann ich ja ohne Probleme zusätzlich zur Floating Rule oben einbauen, oder?
Klar. Ich nutze Floating aber kaum, es stört mir die Übersichtlichkeit.
Bei der NAT-Regel müsstest Du in pfSense Gruppen bilden, in OPNsense kannst Du mehrere Interface direkt in der NAT-Regel abhandeln.
Screenshot 2025-02-03 111056.png

Screenshot 2025-02-03 112837.png
 
Zuletzt bearbeitet:
Cool, danke. Kleine Frage: Warum stören dich floating rules bei der Übersichtlichkeit?
 
Warum stören dich floating rules bei der Übersichtlichkeit?
Weil Du nicht direkt sehen kannst, worauf sie sich eigentlich beziehen. Das Problem hat man bei der DNS-NAT-Geschichte aber eh, von daher macht es an der Stelle den Braten wohl nicht fett.
 
Ich wollte mir gerade ein neues VLan auf meiner unter Proxmox virtualisierten OPNsense anlegen, aber irgendwo ist da nen Bug in meiner Konfiguration.
Vielleicht weiß jemand was ich übersehen habe.
Ich habe eine Bridge vmbr3305 als zusätzliche Netzwerkkarte vtnet4 in die Sense gehangen konfiguriert. vtnet4 hat eine IP bekommen. DHCP ist konfiguriert und die Firewall ist auf allow all zu einer Test VM in einem anderen Netzwerk konfiguriert. Rückweg in der Firewall ist aufgrund der Probleme auf allow all mit Logging als erste Regel konfiguriert.
Eine neue VM hinter der vtnet4 bekommt per DHCP eine IP, das Gateway und einen DNS Server, wobei GW auch DNS Server ist.
Die VM kann weder erfolgreich DNS Auflösungen durchführen, noch das eigene Gateway oder die VM in anderen Subnetz anpingen.
Der DNS ist ein Adguard auf der Sense und protokolliert die Anfrage. tcpdump zeigt auf der vtnet4 alle ICMP und DNS Requests an, Antworten kommen aber nicht zurück.
Das Interface im anderen Netz sieht sowohl die ICMP requests als auch die responses.

Es scheint also kein Traffic aus dem neuen Interface vtnet4 zu kommen, abgesehen vom DHCP response.
 
Rückweg in der Firewall ist aufgrund der Probleme auf allow all mit Logging als erste Regel konfiguriert.
Einen Rückweg regelt man generell nicht. Und hast Du nun ein VLAN oder ein LAN angelegt... Eine zusätzliche Netzwerkkarte in der Sense brauchst Du für gewöhnlich auch nicht, wenn du eh schon VLANs einsetzt.
 
Das man den Rückweg nicht anlegt ist mir grundsätzlich bewusst. Wollte nur auf Nummer sicher gehen und auch mit ping die gegenrichtung versuchen. Bekomme dann "Destination Host anreachable".

Ich nutze bei mir auf der Hardware zwar VLANs, aber ab Proxmox ist alle untagges mit Bridges. Entsprechend bekommt die Sense auch nur echte NICs, siehe Screenshots.

1739212697576.png


1739212721910.png

1739212768217.png
 
@Sannyboy111985 So würde ich es nicht machen. Bin mir nicht mal sicher, ob dein Setup so überhaupt Sinn macht.

Davon ab, wenn es für dich bis jetzt funktioniert hat, dann vergleiche die Einstellungen der VM mit denen der "Test VM in einem anderen Netzwerk".
Regeln solltest Du erst mal mit "eingehend alles erlauben" konfigurieren. Damit kannst Du die Konfiguration der OPNsense selbst schon mal ausschließen. Und dann wäre es ein Proxmox-Problem.
Wie viele VMs hast Du so bisher in betrieb?
 
Zuletzt bearbeitet:
@BobbyD: Warum sollte das Setup so keinen Sinn machen und wie würdest du es machen?
Auf Proxmox kann ich direkt meine Netzwerke als Netzwerkkarte aussuchen und muss nicht individuell das VLAN in der Netzwerkkarte manuell eingeben. Finde ich etwas einfacher. Die Logik habe ich damals auch im VMWare mit den vSwichtes so gelernt.

Die andere VM ist im Netz vmbr0/vtnet0 192.168.40.0/24 . Die neue VM funktioniert in den Netzen problemlos und kann DNS als auch ping zu einer VM in vmbr0/vtnet0 druchführen. Nur im neuen vmbr3305/vtnet5 funktioniert es nicht.
In allen Netzen laufen verschiede VMs und Container.
Die Interfaces sind im Proxmox und unter OPNsene gleich konfiguriert. Pinge ich aus dem neuen Netz in ein andere Netz kann ich den Traffic verfolgen: von VM --> vtnet5 -> vtnet1 --> VM --> vtnet1 , aber auf vtnet5 taucht das Packet nicht mehr auf.
Für das Interface vtnet5 habe ich eine IN und OUT Allow all konfiguriert, inkl. Logging. Es gibt keine Events im Log.

Ein Ping sieht so aus.
Code:
root@OPNsense:~ # tcpdump -npi vtnet5 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vtnet5, link-type EN10MB (Ethernet), snapshot length 262144 bytes
07:51:28.044244 IP 10.33.5.50 > 192.168.40.20: ICMP echo request, id 1221, seq 3, length 64
07:51:29.044361 IP 10.33.5.50 > 192.168.40.20: ICMP echo request, id 1221, seq 4, length 64
07:51:30.044276 IP 10.33.5.50 > 192.168.40.20: ICMP echo request, id 1221, seq 5, length 64

root@OPNsense:~ # tcpdump -npi vtnet1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vtnet1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
07:55:01.069677 IP 10.33.5.50 > 192.168.40.20: ICMP echo request, id 1221, seq 216, length 64
07:55:01.069866 IP 192.168.40.20 > 10.33.5.50: ICMP echo reply, id 1221, seq 216, length 64
07:55:01.069882 IP 192.168.40.1 > 192.168.40.20: ICMP host 10.33.5.50 unreachable, length 92
 
und wie würdest du es machen?
Zuerst einmal die ganzen VLANs in der Sense terminieren und nicht davor. Dann würde ich die ganzen Bridges weglöschen, möglicherweise brauchst Du nur eine.
Also kurz, alles abbrennen. 😉
 
Zuletzt bearbeitet:
Keine Frage, aber muss ein bisschen modern über die OPNsense: und zwar hatte ich für einen Server ein paar Ports in den Aliasen eingerichtet. Da habe ich dann einige gelöscht, weil ich dachte, wird schon nicht nötig sein. Die Ports/den Alias hatte ich in NAT verwendet. Einige Tage lief das ganz gut so. Heute hatten wir übelste Verbindungsprobleme. Hatte alle möglichen Handstände gemacht, Modem/Router neu gestertet, FW neu gestartet, Server neu gestartet. Irgendwann kam ich dann auf die Idee, die Ports wieder hinzuzufügen. Lief aber immer noch nicht. Erst als ich NAT auf einen anderen Server zeigen liess, ging es wieder. Ich so "himmelherrgottzack" muss an meinem selbstgebastelten Linux Server (Wine) liegen. Pustekuchen, NAT darauf zurück gebogen, jetzt läuft das wieder top. Wieso zum Teufel wird das nicht direkt übernommen?
 
Moin, ich baue gerade HA neu und stolpere über folgendes Thema (aus: https://docs.opnsense.org/manual/how-tos/carp.html):
Warning
When using different network drivers on both machines, like running a HAsetup with one physical machine as master and a virtual machine as slave,states can not be synced as interface names differ. The only workaroundwould be to set up a LAGG.
Mein Ziel für HA war eigentlich OPNsense1 als VM auf proxmox, OPNsense2 als Baremetall auf einem alten Server. So hatte ich das auch eine ganze Zeit im Einsatz, aber hatte immer mal wieder Zicken mit MultiWAN - HA hat eigentlich genau getan was es sollte.
Meine Frage dann dazu: Worauf genau bezieht sich "as interface names differ" - auf die tatsächlichen physischen Namen? Oder auf den IDentifier? OdDer gar die Description?
So siehts in OPNsense aus:

Identifierlan
The internal configuration identifier of this interface.
Deviceigb2
The assigned network device name of this interface.
DescriptionLAN
 
las die Interfaces anstatt auf die NIC auf ein LAGG zeigen. Im LAGG enthalten ist dann nur Deine eine NIC.
Die Interfaces zeigen dann auf beiden Hosts (BareMetal und VM) jeweils auf des gleiche Interface.

Oder sehe ich das falsch?
 
Das sind die Identifier

Also lan, wan, opt1 usw.
Die müssen gleich sein. Der reale Interface Name (ix0, igb1, re0 und wie sie alle heißen) sind dann egal.
Wichtig ist auch die Reihenfolge der opt Interfaces
Erst wenn beide Listen (also das was unter Interfaces - Overview zu sehen ist) übereinstimmen funktioniert der State-Sync
 
@Shihatsu Danke für diese Ehre.
Was soll man da präzisieren? Ich habe Dir in 2..3 Sätzen "übersetzt", was opnsense Dir als Workaround vorgeschlagen hat.
Welchen Weg Du nun einschlägst und wie Du weiter machst, ist Deine Entscheidung.
 
Hi,
ich komm eigentlich aus der "FW selbst mit nftables bauen" Welt stricken, würde mich aber gern in die opnsense Welt einarbeiten.
Es gibt 1 Mio Guides dafür, und natürlich ist einfach mal loslegen der Weg.
Nur hat wer aus der Erfahrung her einen guten Guide, den man auf jeden Fall kennen sollte dazu?
 
@Mac_leod Wenn als Guide auch Video gilt.
Hier hat sich *hust* jemand zum Thema *Sense für Einsteiger versucht.
Grundsätzlich sind die Sensen recht logisch aufgebaut und wenn gewisse Netzwerk-Kenntnisse vorhanden sind, sollte es kein Problem sein.
 
Zuletzt bearbeitet:
Hi,
ich komm eigentlich aus der "FW selbst mit nftables bauen" Welt stricken, würde mich aber gern in die opnsense Welt einarbeiten.
Es gibt 1 Mio Guides dafür, und natürlich ist einfach mal loslegen der Weg.
Nur hat wer aus der Erfahrung her einen guten Guide, den man auf jeden Fall kennen sollte dazu?
Sehr gute Guides für den Einstieg.
 
Ihr seid Klasse, danke dafür :coffee3::cool:
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh