Subnetting Heaven mit v7

Hi zusammen,

ich brauche dringend dank eurer (@RolandB s) Hilfe tut mein subnetting wieder.
Im letzten Thread (Migration mit Subnets) war mir klar geworden, dass man das schon verstehen sollte, damit man wenn Not am Mann ist, weiß wo man suchen muss. (Danke: @baumhof, @jochen und @rettich)

struktur soll sein:

  • 10.16.0.0/12 ist das übergeordnete Netz
  • Ich mache lauter kleine /24 Netzwerke daraus (weil so mein Switch konfiguriert wurde)
  • Das Servernetzwerk ist die 10.16.1.0/24, die IP des Servers 10.16.1.1, die IP der OpnSense 10.16.1.254 die IP des L3-Switches: 10.16.1.253 und .254 in dem jeweiligen Subnetz
  • Das Beispiel-Subnetzwerk ist die 10.16.16.0/24
  • Unabhängig davon sind Netzwerke für DMZ/WLAN etc. zu handhaben, die man außerhalb betreiben will.

subnets.csv

Die Konfigurationsdatei dazu sollte wohl so aussehen:

# server subnet definition                                                                            
10.16.1.0/24;10.16.1.253;10.16.1.100;10.16.1.200;SETUP     
10.16.12.0/24;10.16.12.254;10.16.12.100;10.16.12.110;MIGRATION; 
10.16.14.0/24;10.16.14.254;;;MIGRATION;
10.16.16.0/24;10.16.16.254;;;MIGRATION;
10.16.17.0/24;10.16.17.254;10.16.17.100;10.16.17.150;MIGRATION;
10.16.18.0/24;10.16.18.254;10.16.18.100;10.16.18.150;MIGRATION;

Route von einem Client in 10.16.16.0, wie soll die aussehen?

$ netstat -rn
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
0.0.0.0         10.16.16.254    0.0.0.0         UG        0 0          0 enp2s0
10.16.16.0      0.0.0.0         255.255.255.0   U         0 0          0 enp2s0

Route von einem Client im 10.16.1.0 Netzwerk:

$ netstat -rn
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
0.0.0.0         10.16.1.253     0.0.0.0         UG        0 0          0 enp2s0
10.16.1.0       0.0.0.0         255.255.255.0   U         0 0          0 enp2s0

oder muss hier die 10.16.1.253 als GW stehen?

Routing des Servers im eigenen Subnetz

$ netstat -rn
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
0.0.0.0         10.16.1.254     0.0.0.0         UG        0 0          0 eth0
10.16.1.0       0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.16.16.0      10.16.1.253     255.255.255.0   UG        0 0          0 eth0
  • Auf Serverseite ist im Routing nicht erkennbar, dass sich das gesamte Netz über ein 10.16.x.x/12 Bereich erstreckt: Der Server gehört dem 10.16.1.x/24 Netz an.
  • In das 10.16.16.x/24 Netz routet der Server über die IP des L3-Switches.
  • Alle internen Anfragen gehen ohne Routing raus, alles andere an die Firewall.

Die korrespondierende netplan sieht so aus:

network:
  ethernets:
    eth0:
      addresses:
      - 10.16.1.1/24
      dhcp4: false
      dhcp6: false
      gateway4: 10.16.1.254
      nameservers:
        addresses:
        - 10.16.1.1
        - 10.16.1.254
        search:
        - linuxmuster.humboldt-gymnasium.ka.schule-bw.de
      routes:
      - to: 10.16.16.0/24
        via: 10.16.1.253

Routing der Firewall

Hier erstmal die Frage: Welche IP hat das Interface LAN ? https://github.com/linuxmuster/linuxmuster-base7/wiki/Ersteinrichtung-der-Appliances#opnsense-firewall hier hat Thomas ja die 10.16.1.254/12 vergeben. Ich nehme an, das ist richtig. Meine Firewall kommt aber damit noch nicht nach 10.16.16.0/24. So scheint es zu funktionieren:

root@firewall:~ # netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            141.xx.yy.gw      UGS         em0
10.16.0.0/12       link#2             U           em1
10.16.1.254        link#2             UHS         lo0
10.16.14.0/24      10.16.1.253        UGS         em1
10.16.16.0/24      10.16.1.253        UGS         em1
127.0.0.1          link#5             UH          lo0
141.xx.yy.net/29   link#1             U           em0
141.xx.yy.zz      link#1             UHS         lo0

Routing des L3-Switches

Hm, schwierig: Der L3-Switch hat ja je eine IP-Adresse im jeweiligen Subnetz. Ich habe auch eine Routing-Regel, die auf 10.16.1.254 zeigt als default-gw, denke ich.
Was das subnetz angeht, gibt es ja eigentlich keine Routing-regel sondern nur eine Zugriffsregel, nämlich dass 1. alle Rechner aus dem subnetz Richtung 10.16.1.1 dürfen und dass 2. allen Rechner die Richtung 10.16.0.0/12 danach verboten wird. Modulo Helper für DHCP und WOL.

Hintergrund des ganzen:

  • Ich habe rebootet und die Clients kommen nicht mehr zur Firewall (für den Proxy z.B. usw.)
  • Wenn ich jetzt linuxmuster-import-subnets aufrufe, dann habe ich mir die Firewall-routing und die des Servers bereits zerschossen. Ein weiterer Aufruf von linuxmuster-import-subnets funktioniert dann nicht mehr.
  • Ich muss also rauskriegen, wie es richtig geht und von Hand setzen.
  • netplan ist bescheuert.

VG, Tobias

Vermeintliche Bugs: Nach dem ganzen Aufschrieb oben, der mir zum Verständnis dient, hier ein paar Nachrichten, warum es bei Reboot bei mir schief geht

  1. Netplan is bescheuert, wenn linuxmuster-import-subnets ausgeführt wird, sieht meine Routingtabelle danach so aus:
# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.16.1.254     0.0.0.0         UG    0      0        0 eth0
10.16.1.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.16.1.0       10.16.1.254     255.255.255.0   UG    0      0        0 eth0
10.16.16.0      10.16.1.253     255.255.255.0   UG    0      0        0 eth0
10.16.16.0      10.16.1.254     255.255.255.0   UG    0      0        0 eth0

und meine netplan/01-netcfg.yaml sieht so aus:

network:
  ethernets:
    eth0:
      addresses:
      - 10.16.1.1/24
      dhcp4: false
      dhcp6: false
      gateway4: 10.16.1.254
      nameservers:
        addresses:
        - 10.16.1.1
        - 10.16.1.254
        search:
        - linuxmuster.humboldt-gymnasium.ka.schule-bw.de
      routes:
      - to: 10.16.1.0/24
        via: 10.16.1.254
      - to: 10.16.16.0/24
        via: 10.16.1.254
  version: 2

Da hat vllt. das Script von Thomas Mist gebaut, oder ich darf einfach kein Server-subnetz einrichten…

  1. Mit dem Skript linuxmuster-import-subnets kommt auch eine Firewall-config auf die Firewall, so dass ich nicht mehr an die Firewall rankomme. Ich muss manuell mal eine Route löschen, dass ich vom Admin-PC auf die Firewall komme um dann diese manuell neu zu konfigurieren. Vielleicht auch hier: geht das immer schief, oder hab ich etwas falsch konfiguriert?

Hier gibt es bei mir mindestens zwei Probleme: 1. die oben genannte Route löschen: root@firewall:~ # route del -net 10.16.1.0/24 und zweitens sie aus dem Konfigurationsinterface noch rausnehmen und drittens ist als GW die 10.16.1.254 selbst eingerichtet. Das geht auch komplett schief. Daher muss ich von Hand auf das GW 253 umstellen.

Hallo Tobias!

Ich habe Routing noch nicht selbst gemacht, habe aber einen tiefen Netzwerkeinblick, wie es funktioniert. Ich schreibe jetzt von diesem Wissen aus und von dem, was in der Subnetting-Anleitung der 6.2 steht.

Client-Seite
Alle Clients müssen das L3-Switch als erste Station eingetragen haben - also 10.16.??.254 bzw. 10.16.1.253 im 1er-Netz. Die Route der Clients sieht also gut aus, außer beim 1er-Client.

Routing beim Server
Der Server muss zwingend ins /24-Netz. Ansonsten versucht er, die Clients direkt zu erreichen, was fehl schlägt. Die Route muss dann wie bei den 1er-Clients auf den L3-Switch (zu 10.16.1.253). Der Server muss zwingend Pakete an die Subnetze schicken, die sind aber nur vom L3-Switch zugänglich! (VLANs trennen die Netze, als ob diese über separate Switche verbunden sind)

Routing der Firewall
Hier sind aus meiner Sicht die wenigsten Änderungen notwendig. Das Netzwerk muss wie der Server auf /24 geändert werden (also 10.16.1.254/24). Nach meinem Verständnis fehlt dann nur noch für den Adapter im grünen Netz dass das richtige Gateway 10.16.1.253 eingetragen wird. Routingregeln in Subnetze sind hier nicht zu machen - der Zugang zu den Subnetzen geht nur über das L3-Switch!

Routing im L3-Switch
Hier ist der aufwändigste Teil und der, der am ehesten schief gehen kann. Zwischen allen Subnetzen (VLANs), die miteinander kommunizieren sollen, müssen Regeln eingerichtet werden. Grundsätzlich kennt das Switch ja die Netze muss aber wissen, welche Pakete in welcher Richtung zugelassen (ALLOW-Regeln) sind und welche nicht (DENY). Da schaue am besten in die v6.2-Anleitung. Diese Einstellungen sind unabhängig von der Linuxmuster-Version

Viel Erfolg!
Roland

2 Like

hallo Roland, du bist mein Held,

super! Vielen Dank. Das gibt mir die Zuversicht, dass es bei mir richtig aussieht. Wie du vllt. im letzten Post siehst, funktioniert dann - wenn du und ich hier recht haben mit dem Servernetz - der Befehl linuxmsuter-import-subnets überhaupt nicht so, wie er tun sollte. Aber vllt. ist der Befehl nur darauf getrimmt, die Subnetze zu verteilen und nicht das serversubnetz selbst.
Ich habe jedenfalls versucht, die subnetze 10.16.1.0/12, 10.16.1.0/24 und gar kein subnetz in devices.csv einzutragen. Irgendwie kommt bei meiner Firewall immer das falsche GW an.

Dass die 10.16.1.x -er Clients das falsche GW haben, das kläre ich noch, evtl hatte ich das von Hand eingetragen.

Ok. Davon gehe ich jetzt auch aus. Ich schreibe den TOP-Post nachher um als „so funktionierts“, auch wenn das import-skript nicht tut.

Das traueich mich jetzt nicht mehr. Ich lasse mal 10.16.1.254/12. DAmit hat es jetzt grade geklappt.

Das hat scheinbar immer funktioniert. Toitoitoi. Das hat auch jemand externes eingerichtet.

VG, Tobias

1 Like

Hallo.
An dieser Stelle hänge ich auch gerade – und genau wie bei @Tobias ging nach dem import-linuxmuster-subnets zunächst mal gar nichts mehr.
Hier ist es auch so, dass der Aufbau genauso aussehen muss wie zu 6.xer-Zeiten – also mit der do-it-like-babo-Option. Das Serversubnet lautet bei mir 10.16.1.0/24, alle anderen Subnetze haben ebenfalls /24er Masken und überschneiden sich nicht.

Ich habe mir daraufhin (auch genauso wie Tobias) die Datei /etc/netplan/01-netcfg.yaml angesehen.
Dort ist im Server nun eingetragen:


[root@server:/etc/netplan]$ cat 01-netcfg.yaml 
network:
  ethernets:
    ens18:
      addresses:
      - 10.16.1.1/12
      dhcp4: false
      dhcp6: false
      gateway4: 10.16.1.254
      nameservers:
        addresses:
        - 10.16.1.1
        - 10.16.1.254
        search:
        - linux.meine-schule.de
      routes:
      - to: 10.16.1.0/24
        via: 10.16.1.254
      - to: 10.20.100.0/24
        via: 10.16.1.254
      - to: 10.20.200.0/24
        via: 10.16.1.254
      - to: 10.30.10.0/24
        via: 10.16.1.254
      - to: 10.30.20.0/24
        via: 10.16.1.254
      - to: 10.16.2.0/24
        via: 10.16.1.254
      - to: 10.30.51.0/24
        via: 10.16.1.254
      - to: 10.30.52.0/24
        via: 10.16.1.254
      - to: 10.30.53.0/24
        via: 10.16.1.254
  version: 2

Sehe ich das richtig – das ist so alles falsch? Der erste Eintrag muss doch eigentlich

gateway4: 10.16.1.253

lauten und alle anderen Einträge hinter „via“ müssen doch auf 10.x.y.253 enden, oder?
Sonst würde der gesamte Traffic doch immer zunächst über die Firewall und nicht zuerst über den L3-Router laufen, oder?
Danke nochmal,
Michael

Hallo Michael,

nicht ganz: ja, alle einträge sollten „via 10.16.1.253“ gehen. Wenn sie über 10.16.1.254 gehen hat man keinen großen Gewinn, aber es sollte wenigstens auch funktionieren.

DAs gateway dagegen ist richtig: die 10.16.1.254 ist für alle anderen Routen zuständig, so z.B. ins Internet, in die WLAN und DMZ oder zu anderen IPs im roten Bereich.

VG, Tobias

Hallo Michael,

Hier ist es auch so, dass der Aufbau genauso aussehen muss wie zu
6.xer-Zeiten – also mit der |do-it-like-babo|-Option. Das Serversubnet
lautet bei mir |10.16.1.0/24|, alle anderen Subnetze haben ebenfalls
/24er Masken und überschneiden sich nicht.

in meiner subnets.cfg steht drin:

10.16.0.0/12;10.16.1.253;10.16.1.100;10.16.1.200;SETUP

Ich habe mir daraufhin (auch genauso wie Tobias) die Datei

/etc/netplan/01-netcfg.yaml| angesehen.
Dort ist im Server nun eingetragen:

[root@server:/etc/netplan]$ cat 01-netcfg.yaml network: ethernets:
ens18: addresses: - 10.16.1.1/12 dhcp4: false dhcp6: false gateway4:
10.16.1.254 nameservers: addresses: - 10.16.1.1 - 10.16.1.254 search: -
linux.meine-schule.de routes: - to: 10.16.1.0/24 via: 10.16.1.254 - to:
10.20.100.0/24 via: 10.16.1.254 - to: 10.20.200.0/24 via: 10.16.1.254 -
to: 10.30.10.0/24 via: 10.16.1.254 - to: 10.30.20.0/24 via: 10.16.1.254

  • to: 10.16.2.0/24 via: 10.16.1.254 - to: 10.30.51.0/24 via: 10.16.1.254
  • to: 10.30.52.0/24 via: 10.16.1.254 - to: 10.30.53.0/24 via:
    10.16.1.254 version: 2|

genau so sieht meine 01-netcfg.yaml im oberen Bereich auch aus.
… bei mir funktioniert seit 3 Wochen aber alles produktiv.

Sehe ich das richtig – das ist so alles falsch? Der erste Eintrag muss
doch eigentlich

gateway4: 10.16.1.253

nein.
Die Firewall ist der Router für das Internet.
Wenn du den L3 dort hin schreibst (also 10.16.1.253) dann wäre die Route
zwar für die anderen Subnets korrekt, aber nicht für alle nicht ins
Schulnetz gehenden Anfragen (Internet).

lauten und alle anderen Einträge hinter „via“ müssen doch auf 10.x.y.253
enden, oder?

nein, es müßte immer (bei jedem Subnet) folgendes stehen:
via: 10.16.1.253
und das tut es bei mir auch:
network:
ethernets:
eth0:
addresses:
- 10.16.1.1/12
dhcp4: false
dhcp6: false
gateway4: 10.16.1.254
nameservers:
addresses:
- 10.16.1.1
- 10.16.1.254
search:
- bzpf.lan
routes:
- to: 10.16.0.0/12
via: 10.16.1.253
- to: 10.17.100.0/24
via: 10.16.1.253
- to: 10.17.101.0/24
via: 10.16.1.253
- to: 10.17.102.0/24
via: 10.16.1.253
version: 2

(eigentlich sind es noch ein paar mehr subnets …)

LG

Holger

Hallo Holger.
Ok, ergibt Sinn … ich frage nur „aus akademischen Gründen“: wäre es nicht sinnvoller, dort jeweils die Router-IP des betreffenden Subnetzes einzutragen? Der Server erreicht den L3 ja auf allen IP-Adressen, daher müsste bei dir z.B. auch möglich sein:

  • to: 10.17.101.0/24
    via: 10.17.101.254

Oder?
Ich werde den Server gleich mal umstellen. Für alle weiteren Tests benötige ich nun aber einen L3-Switch … den hatte ich im bisherigen Test-Setup (ohne Subnetze/VLANs) nicht drin…

Mir fällt gerade noch etwas auf: die anderen Hosts im Servernetz müssen ja auch umgestellt werden. Beim docker-Host sah die netplan-Datei fast genauso aus wie beim Server – da war der Eintrag „via …“ schnell geändert. Aber der OPSI-Host hat eine andere netplan-Datei (auch mit anderer Syntax!). Den Eintrag „via …“ gibt es da nicht… Daher taucht unter „route -n“ auch weiterhin .254 als Gateway auf! Bug???

Schöne Grüße,
Michael

Hallo Michael,

Ok, ergibt Sinn … ich frage nur „aus akademischen Gründen“: wäre es
nicht sinnvoller, dort jeweils die Router-IP des betreffenden
Subnetzes
einzutragen? Der Server erreicht den L3 ja auf allen
IP-Adressen, daher müsste bei dir z.B. auch möglich sein:

  * to: 10.17.101.0/24
    via: 10.*17.101.254*

Oder?

nein, das halte ich für falsch.
In der .yaml steht ja das routing „aus Sicht des Servers“ und von dort
aus ist es korrekt, dass er über 10.16.1.253 in das Netz 10.17.5.0/24 kommt.

Ich werde den Server gleich mal umstellen. Für alle weiteren Tests
benötige ich nun aber einen L3-Switch … den hatte ich im bisherigen
Test-Setup (ohne Subnetze/VLANs) nicht drin…

Ich gehe aber schon richtig in der Annahme, dass du nicht selber in der
netplan yaml editierst, oder?
Ich halte mich da immer an die Mechanismen: also das import-subnets und
leg ungern selber Hand an: bisher hab ich damit gute Erfahrungen gemacht.

LG

Holger

Hi.

Ok – nur ist es ja so, dass der Server in allen Subnetzen steckt und somit auch Zugriff auf alle Router-IPs hat. Daher die Frage, ob die Route aus dem Subnetz 10.17.101.0 nicht dann logischerweise über die entsprechende IP .101.254 laufen sollte. Es kann auch sein, dass beides funktioniert, oder?

Eigentlich wollte ich die netplan yaml-Datei selbst editieren – und zwar deshalb, weil der Befehl linuxmuster-import-subnets da ja Quatsch eingetragen hat. Wenn ich den Befehl also ein zweites Mal starte, dürfte das nicht besser werden, oder?

Schönen Gruß,
Michael

Hallo Michael,

Das ist definitiv falsch: bei mir geht das gar nicht, denn der Server soll nur im 10.16.1.1-er Netz sein und er kommt eben nicht direkt an ein Gateway in einem anderen NEtz. Die 10.17.5.254 steht in einem anderen Netz und wenn du eine route einträgst, dann muss der Server auch an die IP-Adresse des Router/gateways kommen.

Ich habe aufgrund des Zeitmangels es noch nicht geschafft einen Bugreport an Thomas zu schreiben, aber ich bin mir ziemlich sicher, dass zumindest die wiederholte ausführung von linuxmuster-import-subnets nicht so funktioniert wie gewollt (siehe anderer Thread). Ich habe definitiv in meiner netplan und meiner Firewall rumgepfuscht, damit es läuft.

VG, Tobias

Hi Tobias.
Da widersprechen wir uns jetzt aber. Bei mir geht es unter v6.x vom Servernetz aus sehr wohl, dass ich auch die anderen IPs des L3-Routers anpingen kann (also jeweils die .254). Und ich denke auch, dass das so richtig ist, denn der Server muss ja aufgrund der ganzen Netzwerke und -masken, die in der workstations/devices.csv-Datei angegeben sind, auch in allen Subnetzen vertreten sein. Das gegenseitige Aussperren erledigt ja erst der L3-Router. Aus Sicht des Servers sind es einfach Subnetze, die aber aus seiner Sicht noch nicht getrennt sind, denke ich?!
Michael

Ja, pingen kannst du schon. Weil es über den OpnSense geht.
Aber ich glaube nicht, dass du die IPs als gateway eintragen kannst.
Wenn du das default gateway 10.16.1.254 wegnehmen würdest, dann solltest du weiterhin deine Subnetze erreichen können - und zwar über die 10.16.1.253, aber höchstwahrscheinlich auch bei dir nicht über die 10.17.5.254.
Evtl. lieg ich auch falsch…

VG, Tobias

Hi.
Hm – das wiederspricht folgender Beobachtung: Unter v6 wollte ich das Routing irgendwann mal verstehen (was evtl nicht vollständig gelungen ist :wink: ) – daher habe ich den IPFire heruntergefahren und konnte im grünen Netz trotzdem munter „alles“ machen, was nix mit dem Internet zu tun hatte. Macht ja auch Sinn, wenn man sich nochmal diese Grafik ansieht:

http://docs.linuxmuster.net/de/latest/systemadministration/network/subnetting-basics/

Der ganze Traffic in grün soll/muss ja gar nicht über die FW, sondern das kann der L3-Router viel besser und schneller vorher alles regeln … daher denke ich auch, dass der o.g. ping nicht über die Firewall (jetzt OPNSense) läuft … kann mich aber ebenfalls täuschen :interrobang:

Da wir ja nun unterschiedliche Einträge für das Serversubnetz in der Datei subnets.csv gemacht haben, könnte ich mir vorstellen, dass einige unterschiedliche Feststellungen auch daher kommen. Ich habe das kleine Servernetz 10.16.1.0 /24 gewählt (weil es groß genug ist und oben so erwähnt wird). Andere haben das /16er-Netz genommen und wieder andere das /12er-Netz.

Noch eine Frage @Tobias : Ich gelange (auch aufgrund der falschen Routen, die linuxmuster-import-subnets angelegt hat) im Moment nicht auf die OPNSense-FW. Ich nehme an, dass der Rückweg nicht funktioniert, da der L3-Router da ja noch nicht eingetragen ist.
Der Befehl für die Route (route -del …) ist ja oben angegeben … aber wie hast du das GW eingetragen?

… und direkt noch eine Frage: Kann man eigentlich das root-Passwort, das man bei der Installation gesetzt hat, und das anschließend für alle Hosts im Servernetz übernommen wurde, nochmal genauso zentral und elegant für alle in einem Rutsch ändern?

Schöne Grüße,
Michael

schau dir den top-post in dem thread hier an, ich habe die firewall ,manuell so eingerichtet wie dort in den screenshots: du brauchst halt einen Rechner in 10.16.1.x, der direkt auf 10.16.1.254:443 die firewall erreicht, dafür ist das routing noch in ordnung.
VG, Tobias

kann ich leider nicht bestätigen. Kein ping, kein ssh, kein http/https auf die Firewall möglich. Aber wenn ich mich direkt auf der VM unter Proxmox einlogge, klappt ein Ping nach draußen ins Internet. Ein ping zurück auf 10.16.1.1 oder 10.16.1.253 klappt nicht – falsches GW, nehme ich an. Daher kann ich auch nicht auf das Webinterface gelangen … und müsste wissen wie es per CLI geht.


Schöne Grüße,
Michael

Ok, einen kleinen Schritt weiter:
die Konfiguration auf der OPNSense-FW liegt unter /conf/config.xml und kann mit dem vi eingesehen werden.
Dort hatte ich den Eintrag für das Gateway auf .253 geändert.

Wenn ich aber (nun wieder im Webinterface) die Netzmaske für die Schnittstelle LAN auf /24 ändern will, erhalte ich dies:


Ich nehme an, dass die statische Route, an der er sich stört, diese ist:

Die 10.16.0.0/12 ist aber nicht editierbar.
Die anderen Einträge hat linuxmuster-import-subnets übrigens fehlerfrei angelegt!

@Tobias Ich kann jetzt 1:1 das bestätigen, was du oben schreibst: Das per default eingetragene Gateway „GW_LAN“ macht Ärger bzw ist durch linuxmuster-import-subnets auch falsch konfiguriert worden. Wenn es deaktiviert (!!) ist, kann ich alle Hosts im Servernetz erreichen, wenn es aber aktiviert wird, klappt es nicht mehr!

Also ich habe jetzt keine Lust mehr … @Tobias könntest du mir evtl deine /conf/conf.xml schicken? (Crypto-Zeug kannst du ja raus löschen…)
Das Gateway lässt sich einfach nicht einrichten :frowning_face:
Ich habe mit route -del zunächst wie bei dir das Servernetz rausgenommen … kann aber weiterhin die Netzmaske nicht auf /24 ändern, weil das mit einer statischen Route kollidiert, was mir unklar ist. Zudem ist es so, dass alles funktioniert, solange das Gateway deaktiviert ist (ping auf alle Hosts im Servernetz klappt !) – sobald es aber aktiviert ist und auf .253 als default-GW zeigt, geht kein PING mehr durch. Auf der OPNSense-Konsole erhalte ich dann sogar seltsamerweise das hier:

root@firewall:~ # ping 10.16.1.1
PING 10.16.1.1 (10.16.1.1): 56 data bytes
ping: sendto: Invalid argument

Sobald das Gateway wieder deaktiviert ist, kommt auch der ping wieder durch … alles höchst seltsam… wer hat einen brauchbaren Tipp?

Es gibt offensichtlich weiterhin widersprüchliche Aussagen, wie der Eintrag auf dem Server in der subnets.csv auszusehen hat. Was ist denn nun richtig?

Holger hat: 10.16.0.0/12;10.16.1.253;10.16.1.100;10.16.1.200;SETUP
Tobias aber: 10.16.1.0/24;10.16.1.253;10.16.1.100;10.16.1.200;SETUP
Roland meint ebenfalls, dass es ein /24er Netz sein muss …

Wer hat denn nun Recht :question::question:

Hallo Michael,

Es gibt offensichtlich weiterhin widersprüchliche Aussagen, wie der
Eintrag auf dem Server in der subnets.csv auszusehen hat. Was ist denn
nun richtig?

Holger hat: |10.16.0.0/12;10.16.1.253;10.16.1.100;10.16.1.200;SETUP|
Tobias aber: |10.16.1.0/24;10.16.1.253;10.16.1.100;10.16.1.200;SETUP|
Roland meint ebenfalls, dass es ein /24er Netz sein muss …

Wer hat denn nun Recht :question::question:

der bei dem es funktioniert: der hat recht … bis der Entwickler sagt,
dass es so oder so sein muß: und das ist noch nicht geschehen: bis
dahin, haben alle Recht, bei denen es funktioniert.

Vom Verständnis her würde ich sagen, dass Tobias es richtig hat: aber
ich werde an mein produktives System keine Hand anlegen, solange es
funktioniert und ich keinerlei Probleme damit habe.

Ich verstehe eh deine Unruhe nicht: es wirkt alles etwas Hektisch.

Dass du bei dir alle möglichen Clients anpingen kannst obwohl das GW
falsch ist überrascht mich nicht: wer soll das den verhindern, wenn du
noch gar keinen L3 Router dazwischen hast … so hab ich das zumindest
aus deinem einen Post herausgelesen.
Ich verstehe auch nicht, wie du tests mit subnetting ohne L3 Router
machen kannst und dich dann wunderst, dass die Dinge nicht so
funktionieren, wie sie sollten …

Viele Grüße

Holger

Hi Holger,

Ja, dein Eindruck mag daher kommen, dass ich zZ versuche, hier alles möglichst kleinschrittig aufzuschreiben – auch um Fehler zu dokumentieren. Und davon gibt es nicht wenige, wie ich seit Tagen immer wieder feststelle. v7 hat ganz sicher nicht ohne Grund noch Beta-Status; es gibt noch sehr viele Stolpersteine beim Setup (und ich mache das auch alles nicht zum ersten Mal…)

Das v7-Setup wie es jetzt läuft, wurde beim „Nordländer-Treffen“ bei uns aufgesetzt. Da gingen auch gleich einige Probleme los, von denen mittlerweile viele abgefangen/gelöst wurden. Es war „beruhigend“ zu sehen, dass die einzelnen Gruppen die gleichen Probleme hatten; daher konnten wir fast sicher sein, dass es nicht an der einen Installation lag sondern ein generelles Problem oder Fehler sein musste.
Auch nach dem Treffen ging es in kleinen Etappen weiter, wobei viele der folgenden Schritte leider ebenfalls nicht fehlerfrei durchliefen, was ich dokumentieren wollte.
Ich frage mich aber schon länger, ob das überhaupt sinnvoll ist, denn ich weiß weiterhin nicht, ob das

  • überhaupt für die Allgemeinheit „interessant“/aufschlussreich ist
  • irgendein Entwickler von den ganzen Fehlern, die ich hier zu posten versuche, überhaupt Kenntnis nimmt?

Aber ich kann dich beruhigen – dein Eindruck der Hektik täuscht. Ich habe es überhaupt nicht eilig, die v7 bei uns an den Start zu bringen. Das v7-Setup läuft in einer Testumgebung neben dem Produktivsystem. Wann der Zeitpunkt der Umstellung kommt, ist dabei erstmal nebensächlich. Es ist aber noch ein weiter Weg … soviel ist klar.

Nein, es war so: Ich habe den vi verwendet, um auf der FW die Datei /config/config.xml zu editieren. Einmal ist es dabei versehenlich geschehen, dass ich die IP-Adresse auf einen unmöglichen Wert geändert hatte, nämlich 10.16.1.2345.
Damit fuhr OPNSense dann hoch und ich konnte alle Clients anpingen. Das hatte mich gewundert.

Da hast du mich falsch verstanden. Ich hatte linuxmuster-import-subnets laufen lassen und kam danach natürlich ohne den L3 nicht mehr weiter. Der nächste Schritt war dann aber sofort, einen L3-Switch (Cisco SG300) anzuschließen, um zu sehen, wie es weiterläuft. Der Befehl hatte aber trotzdem nicht richtig funktioniert und die Konfigurationsdateien auf der FW falsch angelegt – ganz unabhängig davon, ob der L3 schon da war oder nicht.

Mittlerweile scheint es übrigens zu funktionieren. Ich musste (genau wie @Tobias) die Route für das 10.16.1.0/24-Netz auf der FW wieder löschen. Die nächsten Tests werden es dann zeigen, ob die Subnetze wirklich wieder getrennt voneinander laufen…
Das Thema Subnetting/VLAN-Umstellung ist nunmal leider ziemlich komplex… aber ich bleibe dran :+1:

Schöne Grüße,
Michael

P.S.:
Noch eine interessante Beobachtung auf der Firewall:

root@firewall:/ # netstat -rn4
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
10.16.0.0/12       link#1             U        vtnet0
10.16.1.254        link#1             UHS         lo0
10.16.2.0/24       10.16.1.253        UGS      vtnet0
10.20.100.0/24     10.16.1.253        UGS      vtnet0
10.20.200.0/24     10.16.1.253        UGS      vtnet0
10.30.10.0/24      10.16.1.253        UGS      vtnet0
10.30.20.0/24      10.16.1.253        UGS      vtnet0
10.30.51.0/24      10.16.1.253        UGS      vtnet0
...

Und zur Erklärung, was das „link#1“ soll:

1 Like