Hallo zusammen,
anbei ein Netzplan (Attachement), den ich einfach nicht zum Laufen zu bekommen.
Was ist der Hintergrund:
Zwei Standorte sind über VPN mit der Zentrale verbunden. In jedem Standort gibt es ein internes Netz. User aus Standort 1 müssen auf Ziele im Standort 2 zugreifen. Es darf aber kein unkontrollierter Zugriff möglich sein. Dies bedeutet. Jedes Paket muss über die Firewall und darf nicht vom Lancom direkt von Tunnel zu Tunnel verschoben werden. Hierzu soll im Lancom ein entsprechendes Routing über Routing Tags verwendet werden.
Zum Problem:
Das Datenpaket kommt vom Standort 1 bekommt im Lancom 7100 den WanTag 150 und wird im richtigen VLan (150) auf die Firewall geroutet. Die Firewall Routet es auf das Lancom Interface 172.16.219.10 durch das richtige VLan (151). Bei diesem Routing bekommt das Paket aber den Routing Tag 150 und nicht wie erwartet 151. Somit dreht sich das Paket im Kreis. Wenn die Firewall hinter der 172.16.219.9 nattet, bekommt das Paket den Tag 151 und es funktioniert.
Vermutung:
Der Lancom vergibt den Tag nicht nach der Schnittstelle über die das Paket kommt sondern nach dem Netz.
Frage:
Wie bekomme ich den Lancom dazu, dass er den richtigen Tag bei einem gerouteten Paket vergibt?
Wie kann ich jedem Paket, dass über das Gateway 172.16.219.10 kommt einen Schnittstellen Tag zuweisen?
Schon einmal Danke.
Fehlerhafte Routing / SChnittstellen Tags
Moderator: Lancom-Systems Moderatoren
Fehlerhafte Routing / SChnittstellen Tags
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Hallo,
wäre es möglich im Detail zu erfahren was du wo konfiguriert hast.
Auf dem ersten Blick verstehe ich auf dem Netzplan nicht warum die zwei Interface auf dem 7100 zur Firewall mit VLAN getrennt werden, und sich die IP Adressen aber alle im selben Subnetz befinden.
Hier könnte evtl. auch das Problem liegen da du im Lancom ja bei den IP Netzwerken die VLAN ID für das netz hinterlegst.
Grüße
Tom
wäre es möglich im Detail zu erfahren was du wo konfiguriert hast.
Auf dem ersten Blick verstehe ich auf dem Netzplan nicht warum die zwei Interface auf dem 7100 zur Firewall mit VLAN getrennt werden, und sich die IP Adressen aber alle im selben Subnetz befinden.
Hier könnte evtl. auch das Problem liegen da du im Lancom ja bei den IP Netzwerken die VLAN ID für das netz hinterlegst.
Grüße
Tom
Sorry,
habe gerade erst gesehen, dass mir beim Subnetz ein Fehler unterlaufen ist.
Es handelt sich um eine 29 Bit Maske (In der Konfig ist es richtig). Im Netz befinden sich also nur 8 IPs. Die beiden Netze werden als Routingnetze eingesetzt.
Leider habe ich noch keine Möglichkeit gefunden für VLans ein SchnittstellenTag (wie das WANTag) zu vergeben. Gibt es da eine Möglichkeit? Ich habe den Eindruck der Tag kommt beim VLan durchs Netz und nicht durch die Schnittstelle.
Danke
Stefan
habe gerade erst gesehen, dass mir beim Subnetz ein Fehler unterlaufen ist.
Es handelt sich um eine 29 Bit Maske (In der Konfig ist es richtig). Im Netz befinden sich also nur 8 IPs. Die beiden Netze werden als Routingnetze eingesetzt.
Leider habe ich noch keine Möglichkeit gefunden für VLans ein SchnittstellenTag (wie das WANTag) zu vergeben. Gibt es da eine Möglichkeit? Ich habe den Eindruck der Tag kommt beim VLan durchs Netz und nicht durch die Schnittstelle.
Danke
Stefan
Hallo,
ja genau die Tag werden in den IP-Netzwerken Definiert, und hören dort auf den Namen Schnittstellen-Tag
Allerdings haben diese Schnittstellen-Tag nicht nur Auswirkungen auf das Routing sondern trennen auch die Netze auf dem Lancom gegeneinander ab.
Hier der Auszug aus dem Handbuch zu dem Thema Schnittstellen-Tag:
Unterschiede zwischen Routing-Tags und Schnittstellen-Tags
Routing-Tags, die über die Firewall zugewiesen werden, und die über IP-Netzwerke definierten Schnittstellen-
Tags haben einiges gemeinsam, es gibt aber auch wichtige Unterschiede:
• Der Router wertet beide Tags gleich aus. Für die Pakete mit dem Schnittstell en-Tag '2' gelten also alle Routen
mit Routing-Tag '2' in der Routing-Tabelle (und alle Routen mit Default-Routing-Tag '0'). Die gleichen Routen
gelten auch für Pakete, denen die Firewall das Routing-Tag '2' zugewiesen hat.
Das heißt, beim Routing wird das Schnitt stellen-Tag wie ein Routing-Tag verwendet!
• Schnittstellen-Tags schränken aber darüber hinaus noch die Sichtbarkeit (oder Erreichbarkeit) der Netzwerke
Untereinander ein:
o Grundsätzlich können sich nur Netzwerke mit gleichem Schnittstellen-Tag untereinander „sehen“, also
Verbindungen in das jeweils andere Netz aufbauen.
o Netzwerke mit dem Schnittstellen-Tag '0' haben eine besondere Bedeutung – sie sind quasi Supervisor-
Netze. Diese Netze können alle an deren Netze sehen, also Verbindu ngen in andere Netze aufbauen.
Netze mit Schnittstellen-Tag unglei ch '0' können hingegen keine Verb indungen in die Supervisor-Netze
aufbauen.
o Netzwerke vom Typ 'DMZ' sind unabhängig vom Schni ttstellen-Tag für alle an deren Netzwerke sichtbar
– das ist auch sinnvoll, da in der DMZ oft öffentlich zugängliche Server wie Webserver etc. stehen. Die
DMZ- Netze selbst sehen aber nur die Netze mit gleich em Schnittstellen-Tag (und natürlich alle anderen
DMZ-Netze).
o Einen Sonderfalls stellen Netze vom Typ 'DMZ' mit de m Schnittstellen-Tag '0' dar: diese Netze können als
„Supervisor-Netz“ selbst alle ande ren Netze sehen, werden aber auch gleichzeitig von allen anderen
Netze gesehen.
Grüße
Tom
ja genau die Tag werden in den IP-Netzwerken Definiert, und hören dort auf den Namen Schnittstellen-Tag
Allerdings haben diese Schnittstellen-Tag nicht nur Auswirkungen auf das Routing sondern trennen auch die Netze auf dem Lancom gegeneinander ab.
Hier der Auszug aus dem Handbuch zu dem Thema Schnittstellen-Tag:
Unterschiede zwischen Routing-Tags und Schnittstellen-Tags
Routing-Tags, die über die Firewall zugewiesen werden, und die über IP-Netzwerke definierten Schnittstellen-
Tags haben einiges gemeinsam, es gibt aber auch wichtige Unterschiede:
• Der Router wertet beide Tags gleich aus. Für die Pakete mit dem Schnittstell en-Tag '2' gelten also alle Routen
mit Routing-Tag '2' in der Routing-Tabelle (und alle Routen mit Default-Routing-Tag '0'). Die gleichen Routen
gelten auch für Pakete, denen die Firewall das Routing-Tag '2' zugewiesen hat.
Das heißt, beim Routing wird das Schnitt stellen-Tag wie ein Routing-Tag verwendet!
• Schnittstellen-Tags schränken aber darüber hinaus noch die Sichtbarkeit (oder Erreichbarkeit) der Netzwerke
Untereinander ein:
o Grundsätzlich können sich nur Netzwerke mit gleichem Schnittstellen-Tag untereinander „sehen“, also
Verbindungen in das jeweils andere Netz aufbauen.
o Netzwerke mit dem Schnittstellen-Tag '0' haben eine besondere Bedeutung – sie sind quasi Supervisor-
Netze. Diese Netze können alle an deren Netze sehen, also Verbindu ngen in andere Netze aufbauen.
Netze mit Schnittstellen-Tag unglei ch '0' können hingegen keine Verb indungen in die Supervisor-Netze
aufbauen.
o Netzwerke vom Typ 'DMZ' sind unabhängig vom Schni ttstellen-Tag für alle an deren Netzwerke sichtbar
– das ist auch sinnvoll, da in der DMZ oft öffentlich zugängliche Server wie Webserver etc. stehen. Die
DMZ- Netze selbst sehen aber nur die Netze mit gleich em Schnittstellen-Tag (und natürlich alle anderen
DMZ-Netze).
o Einen Sonderfalls stellen Netze vom Typ 'DMZ' mit de m Schnittstellen-Tag '0' dar: diese Netze können als
„Supervisor-Netz“ selbst alle ande ren Netze sehen, werden aber auch gleichzeitig von allen anderen
Netze gesehen.
Grüße
Tom
Hallo,
ich habs wie beschrieben in der NetzConfig eingetragen. Zumindest meine ich das (siehe Bild).
Es funktioniert ja auch, wenn die Daten aus dem Netz kommen.
Probleme gibt es wenn die Daten auf das Interface (172.16.219.10) geroutet werden. Dann bekommen sie nicht den Tag des Routingnetzes sondern den Tag der Gegenstelle in deren Konfig das Netz ebenfalls steht (VPN_1).
Danke
Stefan
ich habs wie beschrieben in der NetzConfig eingetragen. Zumindest meine ich das (siehe Bild).
Es funktioniert ja auch, wenn die Daten aus dem Netz kommen.
Probleme gibt es wenn die Daten auf das Interface (172.16.219.10) geroutet werden. Dann bekommen sie nicht den Tag des Routingnetzes sondern den Tag der Gegenstelle in deren Konfig das Netz ebenfalls steht (VPN_1).
Danke
Stefan
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Hallo,
eine Firewall Regel die zum Netz passt gibt es (zum erstellen der IPSec Regeln). Da habe ich den Routing Tag 0 gesetzt. Nach Manual und ausprobieren überschreibt ein Tag 0 nicht den Tag der durch "Andere" gesetzt wurde.
Auch mit der Reihenfolge von Firewall-Regeln habe ich schon gespielt. Die perfekte Reihenfolge scheint es nicht zu geben.
Ich vermute, dass der Lancom den Tag nicht am Interface fest macht (auch wenn es ein Schnittstellen Tag ist), sondern an den Adressbereichen die über das Interface erreichbar sind.
Wenn dem so ist schade. Dann muss ich mir was neues überlegen.
Habe mal den Support kontaktiert. Hat aber auch keine neuen Informationen gebracht.
Ist das nun ein Bug?
Bis dann
Stefan
eine Firewall Regel die zum Netz passt gibt es (zum erstellen der IPSec Regeln). Da habe ich den Routing Tag 0 gesetzt. Nach Manual und ausprobieren überschreibt ein Tag 0 nicht den Tag der durch "Andere" gesetzt wurde.
Auch mit der Reihenfolge von Firewall-Regeln habe ich schon gespielt. Die perfekte Reihenfolge scheint es nicht zu geben.
Ich vermute, dass der Lancom den Tag nicht am Interface fest macht (auch wenn es ein Schnittstellen Tag ist), sondern an den Adressbereichen die über das Interface erreichbar sind.
Wenn dem so ist schade. Dann muss ich mir was neues überlegen.
Habe mal den Support kontaktiert. Hat aber auch keine neuen Informationen gebracht.
Ist das nun ein Bug?
Bis dann
Stefan
Hi Nerd123
das Problem dürfte hier sein, daß das LANCOM nur eine Session-Liste in der Firewall mitführt - und da kommt nunmal als erstes der Eintrag rein, daß ein Paket von Netz1 nach Netz2 über die 172.16.219.1 geroutet werden soll. Schickt die Firewall das unveränderte Paket wieder zum LANCOM macht das LANCOM einen Session-Lookup und findet die existierende Session...
Die Frage ist nun, ist das ein Bug oder ist dieser Betrieb einfach nicht vorgesehen... Lösen ließe sich das Problem vermutlich nur, wenn das LANCOM pro Interface eine Sessionliste führen würde - da das eine grundlegende Änderung des Verhaltens darstellt, kann daraus geschlossen werden, daß das Ganze kein Bug sondern eher ein Featurewunsch ist...
Gruß
Backslsh
das Problem dürfte hier sein, daß das LANCOM nur eine Session-Liste in der Firewall mitführt - und da kommt nunmal als erstes der Eintrag rein, daß ein Paket von Netz1 nach Netz2 über die 172.16.219.1 geroutet werden soll. Schickt die Firewall das unveränderte Paket wieder zum LANCOM macht das LANCOM einen Session-Lookup und findet die existierende Session...
Die Frage ist nun, ist das ein Bug oder ist dieser Betrieb einfach nicht vorgesehen... Lösen ließe sich das Problem vermutlich nur, wenn das LANCOM pro Interface eine Sessionliste führen würde - da das eine grundlegende Änderung des Verhaltens darstellt, kann daraus geschlossen werden, daß das Ganze kein Bug sondern eher ein Featurewunsch ist...
Gruß
Backslsh
Hallo Backslash,
da bin ich mir auch nicht sicher ob das ein Bug ist. Auf die Idee, dass er das in der Session-Liste sucht bin ich noch gar nicht gekommen.
Ich war davon ausgegangen, dass er das in den Routen / Gegenstellen sucht und daher der Tag kommt. Ich hatte halt gedacht das Problem sei zu fixen, wenn man es schafft ein richtiges Tag zu bekommen.
p.s. Ich habe einen Kurztest gemacht. Hierzu habe ich ein Lan-Interface als DSL-Port definiert. Dem einen Wan-Tag gegeben. Das Ganze für jedes Routing Netz. Also statt VLan nutze ich DSL-Ports. In dieser Konfiguration scheint es nach den aktuellen Tests zu funktionieren. Hat leider einen Haken. Mir gehen die physikalischen Ports aus. Ist also leider keine Alternative. Bedeutet dies wir sind wieder beim Thema Routing Tag?
Gibt es einen „offizielle“ Vorschlag, wenn ich X-Standorte über VPN anbinde und der Lancom nicht gleichzeitig Firewall sein soll (mal abgesehen von X-Lancoms)?
Siehe auch: http://www.LANCOM-Forum.de/viewtopic.php?p=62346#62346
Danke
Stefan
da bin ich mir auch nicht sicher ob das ein Bug ist. Auf die Idee, dass er das in der Session-Liste sucht bin ich noch gar nicht gekommen.
Ich war davon ausgegangen, dass er das in den Routen / Gegenstellen sucht und daher der Tag kommt. Ich hatte halt gedacht das Problem sei zu fixen, wenn man es schafft ein richtiges Tag zu bekommen.
p.s. Ich habe einen Kurztest gemacht. Hierzu habe ich ein Lan-Interface als DSL-Port definiert. Dem einen Wan-Tag gegeben. Das Ganze für jedes Routing Netz. Also statt VLan nutze ich DSL-Ports. In dieser Konfiguration scheint es nach den aktuellen Tests zu funktionieren. Hat leider einen Haken. Mir gehen die physikalischen Ports aus. Ist also leider keine Alternative. Bedeutet dies wir sind wieder beim Thema Routing Tag?
Gibt es einen „offizielle“ Vorschlag, wenn ich X-Standorte über VPN anbinde und der Lancom nicht gleichzeitig Firewall sein soll (mal abgesehen von X-Lancoms)?
Siehe auch: http://www.LANCOM-Forum.de/viewtopic.php?p=62346#62346
Danke
Stefan
Hi Nerd123
Das einzige Problem dabei ist, daß sämtliche Netze plötzlich virzuell andere IP-Adressen bekommen, denn die werden ja durch das N:N-NAT umgesetzt...
Gruß
Backslash
das macht das LANCOM ja auch, aber nur beim ersten Paket einer Session... Das Problem ist hier, daß das LANCOM für dein Szenario zwei Sessions anlegen müßte...Ich war davon ausgegangen, dass er das in den Routen / Gegenstellen sucht und daher der Tag kommt.
irgendwie kann ich mir das nicht vorstellen - es sei denn das LANCOM würde auf dem DSL-Interface maskieren oder N:N-NAT machen... Denn dann ändert sich ja die Absenderadresse (genauso, wie sie sich ändert, wenn deine Firewall maskiert) wodurch das LANCOM dann auch zwei Sessions anlegen kannp.s. Ich habe einen Kurztest gemacht. Hierzu habe ich ein Lan-Interface als DSL-Port definiert. Dem einen Wan-Tag gegeben. Das Ganze für jedes Routing Netz.
nun ja, du könntest *einen* transparenten DSL-Port in Richting Firewall einrichten, und auf diesem N:N-NAT für jedes der X Netze machen, wodurch das LANCOM wiederum zwei Sessions anlegen könnte... Dafür würden 4 Ethernet-Ports ausreichen (einer als LAN-Port im LAN, einer als LAN-Port an der Firewall, einer als DSL-Port an der Firewall und ein DSL-Port zum WAN). Das N:N-NAT müßtest dann du an dem Port machen, auf dem der Traffic zwischen Firewall und WAN-Port läuft.Gibt es einen „offizielle“ Vorschlag, wenn ich X-Standorte über VPN anbinde und der Lancom nicht gleichzeitig Firewall sein soll (mal abgesehen von X-Lancoms)?
Das einzige Problem dabei ist, daß sämtliche Netze plötzlich virzuell andere IP-Adressen bekommen, denn die werden ja durch das N:N-NAT umgesetzt...
Gruß
Backslash
Hallo Backslash,
danke für die Info, auch wenn sie leider nicht den erhofften Durchbruch bringt.
Das mit dem DSL-Port und WAN-Tag werde ich nochmal genau prüfen.
N:N-Nat ist leider keine Option für mich, das hängt die User ab.
Trotzdem danke. Vielleicht kommt die Funktion ja irgendwann.
Bis dann
Stefan
danke für die Info, auch wenn sie leider nicht den erhofften Durchbruch bringt.
Das mit dem DSL-Port und WAN-Tag werde ich nochmal genau prüfen.
N:N-Nat ist leider keine Option für mich, das hängt die User ab.
Trotzdem danke. Vielleicht kommt die Funktion ja irgendwann.
Bis dann
Stefan