Hi.
Ok, das kann es auch noch sein.
Ist die per default so eingestellt, dass alles (aus anderen Subnetzen) gedropped wird? Sonst müsste ja irgendeine Meldung im Browser erscheinen??
(Kann aber gerade nicht selbst genauer nachsehen – bin unterwegs…)
Schöne Grüße,
Michael
Hi.
Gerade habe ich die Windows-Firewall (kompletten Dienst unter Win10) abgeschaltet, um zu schauen, ob es das war. Leider komme ich weiterhin nicht durch. Fehlt da nicht doch noch irgendeine (statische) Route vom einen zum anderen Netz? Bei den ACE/ACL stelle ich ja nur die “Erlaubnis” ein aber nicht die Routen selbst?!?
Weiterhin danke für’s Mitdenken.
Michael
Hallo @morpweb
Ok, jetzt bin ich etwas schlauer aber immernoch nicht am Ziel.
Ich habe zum Testen eine neue ACE erstellt, die alles zulässt (Protokoll beliebig, Quelle beliebig, Ziel beliebig) und habe diese Regel an meine beiden VLANs 50 und 60 gebunden. Und siehe da: Sie können sich pingen! Es muss also offenbar keine weitere Route her. Das Prinzip funktkioniert.
Daher ist jetzt klar, dass es an meinen ACE-Regeln liegen muss, die im Moment eingetragen sind. Ich sehe den Fehler aber weiterhin nicht – wahrscheinlich mittlerweile Betriebsblindheit 
Es ist ja hoffentlich nicht so, dass die Prioritäten in beiden VLANs die gleichen Nummern haben müssen oder sowas?!?
Hier nochmal die beiden Screenshots.
Das ist VLAN.60, das zusätzlich auf die IP 10.30.10.100 zugreifen können soll:
… und das ist VLAN.50 das die umgekehrte Regel ebenfalls eingetragen hat:
Wo steckt da der Fehler 
Michael
Hallo Michael,
sehe da auch keinen Fehler. Regel 91 und 11 sind meiner Meinung nach nicht notwendig. Ich würde versuchen, für Regel 95 und 20 die Protokollierung zu aktivieren, um die abgelehnten Pakete zu sehen.
Grüße
Bertram
Hi,
Ok, das kann ich machen. Regel 91 und 11 hatte ich reingenommen, damit das Subnet auch untereinander andere Clients sehen kann. Meiner Meinung nach ging das ohne diese Regeln vorher nicht.
Ich berichte weiter … und hoffe, dass sich das noch klärt.
Michael
Ok, ich habe in dieser Sache nicht locker gelassen und habe die ACE/ACL Regeln hin- und hergewälzt. Nachdem ich damit partout nicht weitergekommen bin, habe ich im Nachbarforum nochmal genauer nachgefragt und siehe da: Es kann auch am Hypervisor liegen. Die (vermutete) Lösung des Problems kommt aber in einen neuen Thread, damit das mehr ins Auge fällt 
… das Problem haben vermutlich noch andere, die Proxmox einsetzen.
Der Fehler liegt darin, das die Regeleinträge für beide VLANs vertauscht gehören.
Gruß von WeitDahinten
Wie meinst du das? Laut Anleitung soll es so sein, dass die kleinste Nummer zuerst abgearbeitet wird und dann “first match wins”?!
Genau. Das ist eine der Regeln nach denen Switch ACLs verarbeitet werden. Eine weitere ist die Bindung einer ACL an eine Schnittstelle. Die Doku sagt:
ACL-Bindung
Wenn eine ACL an eine Schnittstelle gebunden ist (Port, LAG oder VLAN), werden ihre ACE-Regeln auf Pakete angewendet, die an dieser Schnittstelle ankommen.
d. h. Switch ACLs können nur in eingehender Richtung (inbound/ingress) an eine Schnittstelle gebunden werden (im Gegensatz dazu können Router ACLs sowohl eingehend als auch ausgehend gebunden werden).
Wenn also Daten von VLAN A nach VLAN B erlaubt werden sollen dann muß VLAN B das erlauben.
VLAN 60 muß also einen Eintrag enthalten, das alle Daten von 10.30.10.100/32 (Quelle) nach 10.30.20.0/24 (Ziel) erlaubt werden. Im Beispiel steht es aber genau umgekehrt (Quelle und Ziel sind vertauscht). Dasselbe gilt für VLAN 50. Auch hier sind Quelle und Ziel vertauscht.
Folglich gibt es zwei Möglichkeiten das Problem zu lösen.
Die 2. Lösungsmöglichkeit habe ich in meinem Beitrag gemeint.
Gruß von WeitDahinten
OK, danke für die Klärung. (Ich hatte gedacht, dass du die Reihenfolge von oben nach unten meintest – die scheint ja zu stimmen)
Ich werde das nochmal testen. Im Moment habe ich alles wieder auf den ursprünglichen Zustand zurück gesetzt (getrennte Subnetze/VLANs). Dazu noch ein Firmware Upgrade und einen Neustart. Kann gerade nicht weiter testen aber ich melde mich später nochmal…
Michael
kleiner Nachtrag:
Lösungsvariante 2 ist aufwendiger als Variante 1. Daher ist Variante 1 die sinnvollere.
Hallo WeitDahinten,
Der SG300 kann m.E. grundsätzlich nur inbound filtern, egal ob Layer 2 oder 3 ACLs. Das Kommando dazu lautet:
service-acl input ... im Interface Conf Mode …
und
show interfaces access-lists ...
Grüße
Muss der SG300 neu gestartet werden, wenn man an den ACL-Regeln und vor allem an der VLAN-Bindung etwas ändert? Im Moment kommt mir das so vor??!
Ein Neustart hat noch nie geschadet.
Gruß
Roland
Nein, das ist bei dieser Konfigänderung nicht nötig. Bei Moduswechsel (L2/L3), Firmware-Aktualisierung oder Jumbo-Frame Unterstützung ist ein Neustart nötig.
Kann bitte jemand, der VLAN & Subnetting aktiviert hat, auf dem Server den Befehl
route -nloslassen? Bei mir liefert das:
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.16.1.254 0.0.0.0 UG 100 0 0 eth0
10.16.0.0 10.16.1.253 255.240.0.0 UG 0 0 0 eth0
10.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0Da taucht also noch die alte Netzmaske .240. von vor der Umstellung auf – scheint falsch zu sein, doch woran liegt es bzw welche Servereinstellung stimmt da nicht?
Gerade gesehen: Auch auf dem IP-Fire steckt noch eine alte Route von vor der Umstellung (2. Zeile) – warum/woher?
20:03/0 ipfire ~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.10.1 0.0.0.0 UG 0 0 0 red0
10.16.0.0 10.16.1.253 255.240.0.0 UG 0 0 0 green0
10.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 green0
172.16.16.0 0.0.0.0 255.255.255.0 U 0 0 0 blue0
172.16.17.0 0.0.0.0 255.255.255.0 U 0 0 0 orange0
172.16.18.0 172.16.18.2 255.255.255.0 UG 0 0 0 tun0
172.16.18.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 red0
Schöne Grüße,
Michael
Lieber Michael,
ich habe die 6.2, die von einer 5.x über 6.1 upgedatet wurde.
Bei mir sieht die Routingtabelle des Servers so aus:
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.16.1.254 0.0.0.0 UG 100 0 0 eth0
10.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 eth0
Ich glaube, wenn man kein subnetting hat, ist das so korrekt. Das müsste ich aber auch nachsehen.
Auf dem IpFire sieht die Tabelle so aus:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.12.1 0.0.0.0 UG 0 0 0 red0
10.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 green0
172.16.16.0 0.0.0.0 255.255.255.0 U 0 0 0 blue0
172.16.18.0 172.16.18.2 255.255.255.0 UG 0 0 0 tun0
172.16.18.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.12.0 0.0.0.0 255.255.255.0 U 0 0 0 red0
192.168.12.1 0.0.0.0 255.255.255.255 UH 0 0 0 red0
L.G.,
Christoph G.
Hallo.
Ja, ohne Subnetting ist das so richtig wie bei dir.
Meine Frage ist eher, warum ich den alten Eintrag trotz Umstellung noch habe bzw welche Einstellung fehlt, damit alles so ist, wie es mit Subnetting sein sollte.
Ich bin damals bei der Umstellung dem Wiki Artikel gefolgt.
Schöne Grüße
Michael
Hallo Michael,
Kann bitte jemand, der VLAN & Subnetting aktiviert hat, auf dem Server
den Befehlroute -n|
loslassen? Bei mir liefert das:
Kernel-IP-Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.16.1.254 0.0.0.0 UG 100 0 0 eth0 10.16.0.0 10.16.1.253
255.240.0.0 UG 0 0 0 eth0 10.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0|Da taucht also noch die alte Netzmaske .240. von vor der Umstellung auf
– scheint falsch zu sein,
nein: ist richtig.
Du hast ja das alte 255.240.0.0 Netz „gesubnettet“ also unterteilt.
Die Netzwerkmaske ist also schon richtig: dein Netz (das gesammte) ist
255.240.0.0 „groß“.
doch woran liegt es bzw welche
Servereinstellung stimmt da nicht?
ich denke, es ist alles OK.
Be mir sieht es auch so aus:
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use
Iface
0.0.0.0 10.16.1.254 0.0.0.0 UG 100 0 0 eth0
10.16.0.0 10.16.1.253 255.240.0.0 UG 0 0 0 eth0
10.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Das ist ja auch korrekt: die Default Route (0.0.0.0) ist auf den IPFire
gerichtet: willst du also irgenwohin, was nicht in deinem Netz ist, mußt
du über den IPFire raus.
Willst du in dein Netz: und hier steht korrekterweise die 255.240.0.0,
dann mußt du dich an 10.16.1.253 wenden: das ist die IP des L3 Switches
in deinem Servernetz: also die „route“ für den internen Verkehr.
Sieht gut aus.
LG
Holger
Hi Holger. Das ist ja beruhigend.
Hätte mich auch gewundert, wenn das hier nicht stimmt.
Was ich jetzt von verschiedenen Stellen gehört habe: die Regeln im L3 für den Zugriff von einem Subnetz in das gleiche Subnetz sollen angeblich überflüssig sein (oben die Regeln 91 und 11). Aber ich habe keinen Zugriff auf andere Clients im gleichen Segment, wenn ich diese Regeln lösche. Das sollte so nicht sein, da das eigentlich auf Layer2 Ebene läuft und gar nicht über den L3-Router müsste…
Ich suche weiter…
Michael