Messages

Himmelherrgott ich habe den Fehler. Ich habe ein Windows gepingt. Da hatte ich die Netzwerkerkennung auf öffentlich, und in der Firewall ICMP freigegeben. Aber anscheinend antwortet Ping nur auf Adressen im selben Subnet. Also fix ein Linux aufgesetzt, das antwortet aus dem Labor Subnet. Lag also nicht an der Sense.

Aber danke mal soweit! Hat mich ja nicht x Stunden gekostet.

Also habe block bogon und private IPs auf WAN deaktiviert. Geht immer noch nicht.

Bei den DNS bin ich nicht sicher. Internet geht an allen VLANs mit der DNS und der Allow !RFC_1918 Regel. Habe wie im anderen Thread erwähnt ja KEA als DHCP eingerichtet. Erst habe ich überall Gateway auf das jeweilige Subnet gesetzt, und bei Nameserver zwei öffentliche rein gemacht. Weil hatte unbound DNS deaktiviert. Dann habe ich das alles abgeändert, und bei Gateway das jeweilige Gateway und bei NS jeweils auch die Gateway Adresse rein gemacht, damit unbound DNS richtig arbeitet.

Das sollte ja aber nichts ausmachen, oder? Ping auf IP hat ja nichts mit DNS zu tun.

Also so sieht das aus bei KEA Subnet:

You cannot view this attachment.

Habe jetzt auch mal autocollect Data rein gemacht. Internet geht immer noch in den VLANs, aber pingen immer noch nicht.

Ja sry!

Also die Lab Sense hängt hinter der Produktiv Sense, welche hinter einem Provider Router hängt. Also dreifach NAT. Ohne physische Switches dazwischen.

Von der Lab Sense (um die geht es hier mit "VLANs antworten nicht") fahre ich getagged mit allen VLANs weiter auf einen ESXi, wo ich einen vSwitch habe, mit den jeweiligen Portgruppen. Adressen werden an allen VLAN korrekt per DHCP bezogen. Es gibt auch keine doppelten Adressbereiche. Haben alle VLANs und physischen Netze eigene /24 Subnetze, die auf den anderen Geräten nicht vor kommen.

Du sagst dies sei ein Fehlerbild. Ist dem so? Dann wäre ich schon mal beruhigt, und würde den Fehler suchen, statt da rückwärts was zu beregeln. So müsste es nach mir der Fall sein, bei der Produktiv Sense ist es ja auch so. Die KI beharrt darauf, dass ich den Rückweg von der DMZ (im Screenshot 57 Labor als Beispiel) nach LAN (welche eine allow all Regel drin hat) auch beregeln muss.

Bei WAN habe ich block private Networks und block bogon Networks drin. Das steht auf DHCP und bezieht auch die Adresse. Könnte es daran liegen?

Hi

Auf meiner produktiv Sense habe ich am Beispiel der DMZ nur folgende Regel drin. Auf dem LAN habe ich eine Regel "Allow all". Heisst aus der DMZ komme ich nicht in RFC_1918 Netze, so wie es sein soll. Greife ich aber aus dem LAN auf die DMZ zu, bekomme ich Antwort. Das wäre so gewünscht.

You cannot view this attachment.


Nun habe ich eine Sense im Lab eingerichtet. Da musste ich mehr Regeln erstellen, um überhaupt ins Internet zu kommen, und um im VLAN pingen zu können. Die !RFC_1918 Regel habe ich auch drin, damit ich ins Internet komme. Aber ich bekomme aus der DMZ der Lab Sense keine Antwort aus dem LAN. Selbst wenn ich die !RFC_1918 Regel deaktiviere.

You cannot view this attachment.

KI meint ich müsste da eine Admin bypass Regel in der DMZ zurück ins LAN erstellen. Nach mir verzapft die da wieder mal Unsinn. Will eigentlich gar nichts von der DMZ ins LAN beregeln, das führt das ganze VLAN Konzept ja ad absurdum. Und bei der produktiv Sense funktioniert es ja auch ohne Regel zurück.

Gruss und danke

Ich mach einen neuen Thread auf, das DHCP Problem ist ja jetzt gelöst.

hmm, ich versteh echt die Welt nicht mehr. Vorhin hat es noch geklappt aus dem LAN zu pingen, wenn ich Block !RFC_1918 inaktiv hatte. Nun habe ich die Regel disable, und ich kann nicht mehr pingen.

Nach mir habe ich rein gar nichts gemacht an den Regeln, ausser die Regel aktiviert und wieder deaktiviert.

Hi

Auf der produktiv Sense musste ich quasi nichts beregeln. Auf der Lab Sense brauchte ich diese Regeln, damit es Adresse bezog und Internet bekam, hier am Beispiel des Labor VLAN:

You cannot view this attachment.

Auf der Produktiv Sense reichte die letzte Regel. Das wär mir auch egal, habe jetzt die Regeln auf allen VLAN erstellt. Wenn ich jetzt aber vom LAN aus (hat die goldene allow all Regel) einen Gast in dem betreffendem VLAN pingen möchte, kommt nichts zurück. Das wird durch die Block !RFC_1918 Regel ausgelöst. Deaktiviere ich die, kommt der Ping durch.

Das Verhalten habe ich bei der Produktiv Sense nicht. Nun gut, ich kann bei der Lab Sense überall eine Rückwärts Regel erstellen, damit man als Admin aus dem LAN überall drauf kommt. Aber es greifen z.T. auch andere VLAN z.B. auf die DMZ zu, da habe ich nicht so gross Lust, alles doppelt und dreifach zu beregeln.

Sprich ist es eingehender Verkehr auf einen Gast/Server, soll dieser Antwort geben, obwohl da die Block !RFC_1918 Regel drin ist.

Auf meiner Produktiv Sense läuft das ohne Probleme, da ist in der DMZ atm die Regel drin:

You cannot view this attachment.

Was mir dabei gerade noch auffällt: müssten auf der Produktiv Sense nicht noch die automatisch erstellten Regeln vom NAT mit angezeigt werden? Früher sah man da immer noch die ganzen NAT Regeln, oder haluziniere ich gerade nur?
 
Gruss und danke

Ah sehr cool, WAN geht, 2 Interfaces und 13 VLAN eingerichtet. Bezieht alles brav die Adressen. Danke mal soweit. Ist ganz schöne Sträflingsarbeit, zum Glück muss ich das nicht jeden Tag machen. Der ESXi mit dem getaggten vSwitch hat mir die Arbeit auch sehr erleichtert. Wenn ich das alles an den physischen Switches mit 1-2 Laptops durchtesten hätte müssen, wär mein Bart noch länger geworden, als er eh schon ist. Das wär ja super mühsam.

Switches einrichten wird dann auch spannend. Bin bislang getagged auf den/die Switches gefahren, aber vom Switch nur untagged weiter. Oder halt direkt getagged von der Sense auf einen ESXi. Aber da mit forbidden Tags oder wie das heisst, um überall nur mit den gewünschten VLANs wieder raus aus dem Switch zu gehen, das habe ich noch nie gemacht. Die Theorie steht schon mal, Praxis wird sich dann zeigen. Ich frag Euch dann wieder, wenn ich am Berg stehe.

Ja, habe drei NICs im Desktop. Vorher hatte ich den Switch an einer unabhängigen parallelen Zywall. Da lief nur noch IPMI und sowas drüber. Die NIC hatte ich im Normalfall deaktiviert. Dann eine 10 Gbit NIC, die hat das LAN von der Sense. Und jetzt habe ich die neue Lab Sense in Betrieb genommen, und von der aus auch eine Strippe zum Desktop gezogen. Also drei Stippen am Desktop: IPMI, LAN Sense1, LAN Sense2. Die Adapter kann ich bei Bedarf zuschalten.

Damit ich nicht umständlich alles mit dem Laptop konfigurieren muss. Nächstes Ziel ist dann die ganzen VLAN einzurichten an der Lab Sense, sind atm 14. Von der will ich getagged zum Ersatz ESXi fahren, damit ich das ganze Regelwerk austesten kann. Die Switches und all den Plunder habe ich noch nicht da, von daher teste ich das virtuell.

Funktioniert eigentlich ganz gut. Den 10 Gbit Adapter habe ich per Metrik priorisiert. Da kommt sogar mein Mozilla VPN Client mit klar. Weil den brauch ich, um mit meinen Kumpels fliegen zu können auf meinem eigenen Server. Der mag doppelt NAT nicht so.

Man muss natürlich den Haken bei "autocollect option data" raus nehmen, wenn man Dinge individuell einstellen will. Sonst macht die OPNsense alles automatisch - "autocollect" halt.

Ahja, das wars, danke.

Dann habe ich noch eine Frage. Im Moment gehts vom Provider Router zur Produktivsense. Von da weiter zur besagten Labsense. Also dreifach NAT. Nach mir habe ich alles richtig verkabelt.

Am Desktop habe ich drei Strippen. Das IPMI Netz an dem Switch (der hängt getagged an Sense 1), mein LAN von der Sense 1 und mein LAN von Sense 2.

Wenn ich nun die Labsense über den Browser aufrufen will, dann wird manchmal das Interface/Dashboard von Sense 1 angezeigt. Obwohl die IP im Browser stimmt. Die IP ist 192.168.5.1, die Adresse/den Range gibt es sonst gar nirgends. Was hat es damit auf sich?

Okay, also doch besser KEA. Das hatte ich allerdings auf Anhieb nicht zum laufen gekriegt. Bin aber noch in der Findungsphase. Am liebsten wär mir ja der ISC Server gewesen. Schade wird der nicht mehr weiter entwickelt, der ist super simpel zu bedienen.

Hoi

Danke.

Ja, den Schalter hatte ich natürlich umgelegt. Hintergrund ist der, dass ja ISC DHCP nicht mehr weiter entwickelt wird. Aber da brauche ich glaube ich gar nicht KEA DHCP, sondern Dnsmasq, ist das richtig? Den habe ich mal soweit, dass eine IP bezogen wird im LAN. Da habe ich jetzt auch Internet.

Kannst Du mir bitte noch kurz bestätigen, dass Dnsmasq das richtige für mich ist, bevor ich alle VLANs und Interfaces einrichte?

Hoi

Habe nun seit ein paar Monaten eine Sense produktiv in Betrieb. Dort nutze ich noch den ISC DHCPv4, das funktioniert super. Ich will jetzt 3 neue Switches, AP und zwei ESXi getagged anfahren. Zum Glück habe ich eine Ersatz 19" Sense mit 6x 10 Gbit, wo ich alles austesten kann, ohne den produktiv Betrieb zu stören. Habe die jetzt aufgebaut, kann per IPMI drauf zugreifen. Den  Setup Assistent habe ich auch schon ausgeführt. Komme an einem Management Port auch auf die Sense, WAN hat sie auch.

Nun will ich den Kea IPv4 DHCP Server nutzen. Habe den Server enabled, zwei Interfaces hinzugefügt, und ein Subnet eingerichtet. Die KI meint, ich muss bei Subnet Gateway und Nameserver eintragen, aber finde die Optionen nicht, die mir die KI angibt. Ich zitiere mal die KI:

Um schnelle Hilfe zu bekommen, frage am besten konkret nach dem Standort der Optionen 3 (Router) und 6 (DNS) im Kea Subnetz-Konfigurationsformular:

    "Hallo zusammen, ich nutze OPNsense 23.7 mit dem Kea DHCPv4 Server. Im Subnetz-Konfigurationsformular (z.B. für 10.10.10.0/24) finde ich weder die Felder 'Default Gateway'/'Primary DNS Server' noch einen Button zum Hinzufügen generischer Optionen (Codes 3 und 6). Wo in der GUI oder in welchem Feld muss ich die Router- und DNS-Informationen für das Subnetz eintragen?"

Vielleicht war ich auch zu lange am basteln, ich spar mir jetzt den ganzen Werdegang die letzten zwei Tage. Nur soviel: hatte die ganzen IPMI, Notfall vmkernel, Schlafzimmer und bisschen Kleinkram auf dem alten Switch hinter einer parallel laufenden Zywall, der Switch wird auch noch ersetzt. Die Zywall ist mir gestorben, also habe ich den uralt Switch an die produktiv Sense angehängt, und die alten VLANS mitgegeben. Lüppt soweit...

Will aber das Netzwerk total auf den Kopf stellen. Alles neue VLANs und Adress Ranges. Aber vorerst geht es nur mal um den Kea DHCP, da komme ich nicht weiter.

Sy, habe zwar alles in Excel und Visio geplant, will das aber nicht öffentlich machen. Will das ganze Netzwerk Zeug in Zukunft bisschen diskreter behandeln.

Gruss und danke. Ich hau mich jetzt mal ein paar Stunden aus Ohr.

Ah, und das reicht, um ins Jail zu kommen? Habe ganz viele Adressen von Seiten die das Netz abscannen, so z.B. kriminalip.io, die gehen auch nicht ins Jail. Dachte ins Jail kommt man nur, wenn man sich z.B. auf 8443 mehrere Male erfolglos versucht einzuloggen.

Aber danke!

Mal gemini dazu befragt:

Überwachung der Fail2Ban-Logs: Im Gegensatz zu anderen Jails überwacht das recidive-Jail nicht normale Dienst-Logs (z. B. sshd oder plesk-panel), sondern die eigenen Protokolle von Fail2Ban (/var/log/fail2ban.log).

• Zählmechanismus: Es zählt, wie oft eine IP-Adresse innerhalb einer bestimmten Zeitspanne (z.B. 1 Tag) von irgendeinem anderen Fail2Ban-Jail gesperrt wurde.
• Langzeit-Sperre: Erreicht die Anzahl der Sperren den konfigurierten Schwellenwert (maxretry), wird die IP-Adresse als "rückfällig" eingestuft und für eine sehr lange Dauer gesperrt (standardmäßig oft 1 Woche, kann aber auch Monate oder "permanent" sein).
• Kurz gesagt: Wenn ein Angreifer nach seiner ersten kurzen Sperre (z.B. 10 Minuten) sofort wiederholt scheitert und erneut gesperrt wird, greift das recidive-Jail und verhängt eine harte Langzeitstrafe.

Wusste nicht, dass es da eine Art globaler Liste gibt. Dachte F2B bezieht sich nur auf das eigene System.

Hoi

Hat nicht direkt was mit OPNsense zu tun. Aber hier sitzt sicher Jemand, der da Licht in die Sache bringen kann.

Und zwar habe in einem VLAN (DMZ) neben diversen anderen Windows und Linux ein Plesk auf Debian. Auf das Plesk sind nur TCP 80 und 443, sowie UDP 443 weiter gereicht. DNS mache ich extern. Trotzdem war da gestern wer im Plesk Jail (F2B), und zwar von einer IP Adresse von Microsoft (130.131.162.253). Frage mich, wie das sein kann. Einziges was ich mir vorstellen könnte, ist dass da von innen angegriffen wird, also direkt aus der DMZ. Aber dann würde ja wohl eine private Adresse im Jail sitzen. Oder kann es sein, dass jemand wegen 80/443 ins Jail kommt? Wüsste nicht warum.

Gruss und danke