Hallo Zusammen,
ich Teste gerade VRRP mit 2 x 1900EF, 10.12.0382 RU9 Firmware, die wie folgt konfiguriert sind.
Es gibt 3 Netze:
Netz1 192.168.10.0/24, VLAN 10, Routing Tag 10
Netz2 192.168.20.0/23, VLAN 20, Routing Tag 20
Netz3 192.168.30.0/24, VLAN 30, Routing Tag 30
Router1 – 192.168.10.2, 192.168.20.2, 192.168.30.2
Router2 – 192.168.10.3, 192.168.20.3, 192.168.30.3
Virtuelle IPs - 192.168.10.1, 192.168.20.1, 192.168.30.1
Der Router1 ist normal der Master.
Wenn ich von der IP z.B. 192.168.20.50 aus Netz2 die Virtuelle IP im Netz1 oder die IP von Master Router anpinge, kommt der Ping nicht zurück, pinge ich die IP von Standby Router oder sonstige Geräte im Netz1 habe ich keine Probleme und der ping kommt zurück.
Das gleiche Problem habe ich bei Ping aus Netz2 -> Netz3.
Netz2 -> Netz2 kann ich alle 3 IPs (Virtuelle, Master und Standby IPs) anpingen.
Das Problem betrifft nur die Virtuelle und die Master IP in anderen Netzen.
Wenn ich mich über VPN Verbinde kann ich alle IPs anpingen (Virtuelle, Master und Standby IPs) in allen Netzen.
Jetzt meine Frage dazu: Ist das beim Einsatz von VRRP normal das die Virtuelle und Master IP nicht pingbar sind oder habe irgendwo was vegessen oder ein Routing Problem?
Ich habe das ganze nach der Anleitung: https://www2.lancom.de/kb.nsf/1275/4926 ... enDocument Konfiguriert.
Und noch eine Frage:
Die beiden Router ersetzen einen 1781EF+ auf dem außer UNITYMEDIA auch noch CompanyConnect mit 8 IP-Adressen konfiguriert sind und dem Netzwerk DMZ zugeordnet, darüber laufen nur Mails. Muss ich hierbei auch noch was an der Konfiguration anpassen (wegen VRRP)?
Ich frage deshalb, da ich in der Testumgebung kein CompanyConnect mit 8 IP-Adressen habe und das nicht Testen kann.
Vielen Dank im Voraus
Manni
VRRP - Ping auf Virtuelle und Master IP
Moderator: Lancom-Systems Moderatoren
Re: VRRP - Ping auf Virtuelle und Master IP
Hi manni4,
du rennst hier in ein Problem, das mit der 10.20 gelöst ist... In der 10.12 antwortet das LANCOM zwar auf das ping, setzt als Absenderadresse aber die virtuelle IP des Netzes ein, auf dem das ping empfangen wurde, bei dir also die 192.168.20.1 statt der von dir erwarteten 192.168.10.1 - damit verwirft dein PC die Antwort und zeigt einen Timeout beim ping an.
Bis zur 10.12 kannst du die virtuellen IPs nur direkt aus dem LAN anpingen, auf das sie gebunden sind.
Daß du sie aus dem VPN anpingen kannst liegt daran, daß der (Standby-) Router das Ping ganz normal auf das LAN sendet wo es dann der Master empfängt und auch beantwortet... (es sei denn das Gerät, das den VPN-Tunnel hält ist selbst der Master, dann beantwortet es das Ping auch selbst)
Gruß
Backslash
du rennst hier in ein Problem, das mit der 10.20 gelöst ist... In der 10.12 antwortet das LANCOM zwar auf das ping, setzt als Absenderadresse aber die virtuelle IP des Netzes ein, auf dem das ping empfangen wurde, bei dir also die 192.168.20.1 statt der von dir erwarteten 192.168.10.1 - damit verwirft dein PC die Antwort und zeigt einen Timeout beim ping an.
Bis zur 10.12 kannst du die virtuellen IPs nur direkt aus dem LAN anpingen, auf das sie gebunden sind.
Daß du sie aus dem VPN anpingen kannst liegt daran, daß der (Standby-) Router das Ping ganz normal auf das LAN sendet wo es dann der Master empfängt und auch beantwortet... (es sei denn das Gerät, das den VPN-Tunnel hält ist selbst der Master, dann beantwortet es das Ping auch selbst)
Gruß
Backslash
Re: VRRP - Ping auf Virtuelle und Master IP
Hi Backslash,
vielen Dank für die prompte Antwort und die Erklärung!
Gibt schon ein Termin wann die 10.20 als Release erscheint?
Kannst du noch was zu meine 2 Frage sagen?
Vielen Dank im Voraus
Manni
vielen Dank für die prompte Antwort und die Erklärung!
Gibt schon ein Termin wann die 10.20 als Release erscheint?
Kannst du noch was zu meine 2 Frage sagen?
Vielen Dank im Voraus
Manni
Re: VRRP - Ping auf Virtuelle und Master IP
Hi manni4,
Desweiteren kommt es darauf an, wie die CompanyConnect -Verbindung aufgebaut wird.... Wird sie über PPPoE aufgebaut, ist alles getan. Wird sie aber als IPoE-Verbindung zu einem vorgestellten Abschluß-Router aufgebaut, dann mußt du zusätzlich dafür sorgen, daß beide CompanyConnect -Verbindungen die selbe(!) MAC-Adresse verwenden - da sonst die Verbindungen in die DMZ abreissen, sobald die Router wechseln...
Gruß
Backslash
demnächst... Du kannst aber bereits mit den Betas "rumspielen"...Gibt schon ein Termin wann die 10.20 als Release erscheint?
solange beide Router den CompanyConnect und die DMZ gleich konfiguriert haben und dieser zusammen mit dem VRRP-Status wechselt, ist das kein Problem. Dazu muß der VRRP-Router, der an die DMZ gbunden ist, mit den CompanyConnect verknüpft werden. Das führt dann dazu, daß CompanyConnect abgebaut wird und bleibt, solange das VRRP im Standby ist... Du mußt aber in jedem Fall verhindern, daß beide Router die CompanyConnect -Verbindung gleichzeitig aufbauen.Kannst du noch was zu meine 2 Frage sagen?
Desweiteren kommt es darauf an, wie die CompanyConnect -Verbindung aufgebaut wird.... Wird sie über PPPoE aufgebaut, ist alles getan. Wird sie aber als IPoE-Verbindung zu einem vorgestellten Abschluß-Router aufgebaut, dann mußt du zusätzlich dafür sorgen, daß beide CompanyConnect -Verbindungen die selbe(!) MAC-Adresse verwenden - da sonst die Verbindungen in die DMZ abreissen, sobald die Router wechseln...
Gruß
Backslash
Re: VRRP - Ping auf Virtuelle und Master IP
Hi Backslash,
vielen Dank für deine Antwort!
Auf den beiden Router ist CompanyConnect und DMZ gleich Konfiguriert und die Öffentliche IP-Adressen von der DMZ werden über Transfernetz auf den Router bereitgestellt. Das hat damals Lancom-Support Konfiguriert, das ist bestimmt mind. 10 Jahre her.
Ich hoffe ich habe alles verstanden was du geschrieben hast und habe das entsprechend umgesetzt.
Hier meine Konfiguration (die Öffentliche IP-Adressen auf den Bildern habe ich leicht verändert
)
Router1
Router2 nur die Unterschiede zum Router1
Was ich erreichen möchte – Router Redundanz und das abfangen eines Ausfalls von den Vorgeschalteten Switch auf der Master-Seite. Die beiden Switche sind miteinander verbunden. Sollte der Switch auf der Masterseite ausfallen wird der Standby Router zum Master und das Internet funktioniert weiter über die andere Leitung. Das muss ich noch irgendwie Skripten
Und wenn der Switch auf der Standby-Seite ausfällt muss halt händisch auf den anderen Switch um gestöpselt werden.
Ich denke mit dieser Konfiguration sollte mein Vorhaben funktionieren und auch das umswitchen der CompanyConnect Leitung, wenn der Master-Router sich verabschiedet, oder habe ich noch was vergessen?
Vielen Dank im Voraus und Viele Grüße
Manni
vielen Dank für deine Antwort!
Leider fehlt mir die Zeit zum rumspielen…Du kannst aber bereits mit den Betas "rumspielen"...
Auf den beiden Router ist CompanyConnect und DMZ gleich Konfiguriert und die Öffentliche IP-Adressen von der DMZ werden über Transfernetz auf den Router bereitgestellt. Das hat damals Lancom-Support Konfiguriert, das ist bestimmt mind. 10 Jahre her.
Ich hoffe ich habe alles verstanden was du geschrieben hast und habe das entsprechend umgesetzt.
Hier meine Konfiguration (die Öffentliche IP-Adressen auf den Bildern habe ich leicht verändert
)Router1
Router2 nur die Unterschiede zum Router1
Was ich erreichen möchte – Router Redundanz und das abfangen eines Ausfalls von den Vorgeschalteten Switch auf der Master-Seite. Die beiden Switche sind miteinander verbunden. Sollte der Switch auf der Masterseite ausfallen wird der Standby Router zum Master und das Internet funktioniert weiter über die andere Leitung. Das muss ich noch irgendwie Skripten
Und wenn der Switch auf der Standby-Seite ausfällt muss halt händisch auf den anderen Switch um gestöpselt werden.
Ich denke mit dieser Konfiguration sollte mein Vorhaben funktionieren und auch das umswitchen der CompanyConnect Leitung, wenn der Master-Router sich verabschiedet, oder habe ich noch was vergessen?
Vielen Dank im Voraus und Viele Grüße
Manni
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Re: VRRP - Ping auf Virtuelle und Master IP
Hi manni4
- Switch nicht pingbar, switcht aber noch
- Switch nicht pingbar, switcht auch nicht mehr
- Switch noch pingbar, switcht aber nicht mehr
Im ersten Fall hättest du einen Fehlalarm und im dritten Fall den Fehler erst gar nicht erkannt... Für die Internet-Redundanz reicht es aus, die Internet-Verbindungen zu ünberwachen...
Gruß0
Bakslash
den Ausfall des Switches erkennst du aber nicht daran, daß du ihn nicht mehr anpingen kannst... Es gibt letztendlich drei Fehlermöglichkeiten:Was ich erreichen möchte – Router Redundanz und das abfangen eines Ausfalls von den Vorgeschalteten Switch auf der Master-Seite. Die beiden Switche sind miteinander verbunden. Sollte der Switch auf der Masterseite ausfallen wird der Standby Router zum Master und das Internet funktioniert weiter über die andere Leitung.
- Switch nicht pingbar, switcht aber noch
- Switch nicht pingbar, switcht auch nicht mehr
- Switch noch pingbar, switcht aber nicht mehr
Im ersten Fall hättest du einen Fehlalarm und im dritten Fall den Fehler erst gar nicht erkannt... Für die Internet-Redundanz reicht es aus, die Internet-Verbindungen zu ünberwachen...
Gruß0
Bakslash
Re: VRRP - Ping auf Virtuelle und Master IP
Hi Backslash,
du hast recht, das habe ich nicht bedacht mit den Switchen…
Ich möchte die beiden Leitungen gleichzeitig nutzen, wie bisher.
Die CC Leitung ist lahm und wird nur für DMZ bzw. nur Mail und als Reserve für VPN benutzt, die UM Leitung ist viel schneller und wird für VPN und Internet surfen benutzt.
Wie ich schon geschrieben habe, leider habe ich keine 2 Leitung (geschweige CC Leitung) um das ganze durchzutesten.
Aktiv-Aktiv Szenario? UM Leitung über den einen Router und CC über den 2 Router?
Hast du ein Tipp für mich, wie ich so was am besten Umsätzen kann?
Vielen Dank im Voraus
Grüße, Manni
du hast recht, das habe ich nicht bedacht mit den Switchen…
Ich möchte die beiden Leitungen gleichzeitig nutzen, wie bisher.
Die CC Leitung ist lahm und wird nur für DMZ bzw. nur Mail und als Reserve für VPN benutzt, die UM Leitung ist viel schneller und wird für VPN und Internet surfen benutzt.
Wie ich schon geschrieben habe, leider habe ich keine 2 Leitung (geschweige CC Leitung) um das ganze durchzutesten.
Aktiv-Aktiv Szenario? UM Leitung über den einen Router und CC über den 2 Router?
Hast du ein Tipp für mich, wie ich so was am besten Umsätzen kann?
Vielen Dank im Voraus
Grüße, Manni
Re: VRRP - Ping auf Virtuelle und Master IP
Hi manni4,
Ansonsten, wenn also deine PCs i Imtarnet direkt mit einem Mailserver im Internet kommunizieren wollen, hast du ein Problem... Du könntest da vielleicht was mit RIP machen: Getaggte Routen per RIP propagieren und dann mittels Firewall-Regeln das pasende Tag auswählen (policy based routing). Ob das aber wirklich problemlos funktioniert, müßtest du ausprobieren
Gruß
Backslash
ist ja auch kein Problem, solange du sie quasi getrennten LANs zuordnest...Ich möchte die beiden Leitungen gleichzeitig nutzen, wie bisher.
Wenn du einen eigenen Mail-Server in die DMZ stellst und alle Hosts in deinem Netz diesen zum Versenden der Mails nutzen mußt du nur allen Rechnern in der DMZ die virtuelle IP des VRRP-Routers, der die CC-Leitung überwacht als Default-Getway mitgeben und den Rechnern in deinem Intranet die desjenigen, der die UM-Leitung überwacht...Die CC Leitung ist lahm und wird nur für DMZ bzw. nur Mail und als Reserve für VPN benutzt, die UM Leitung ist viel schneller und wird für VPN und Internet surfen benutzt.
Ansonsten, wenn also deine PCs i Imtarnet direkt mit einem Mailserver im Internet kommunizieren wollen, hast du ein Problem... Du könntest da vielleicht was mit RIP machen: Getaggte Routen per RIP propagieren und dann mittels Firewall-Regeln das pasende Tag auswählen (policy based routing). Ob das aber wirklich problemlos funktioniert, müßtest du ausprobieren
Gruß
Backslash
Re: VRRP - Ping auf Virtuelle und Master IP
Hi Backslash,
vielen Dank für deine Antwort.
Damit sollte meine Konfiguration wie oben beschrieben funktionieren.
Vielen Dank für deine Hilfe
Grüße, Manni
vielen Dank für deine Antwort.
Dann muss ich nur den Polling auf die WAN-SW Switche rausnehmen und nur UM und CC Leitung überwachen und noch in der VRRP-Liste die Router-ID 10 und 30 auf die UM Leitung umstellen.Wenn du einen eigenen Mail-Server in die DMZ stellst und alle Hosts in deinem Netz diesen zum Versenden der Mails nutzen mußt du nur allen Rechnern in der DMZ die virtuelle IP des VRRP-Routers, der die CC-Leitung überwacht als Default-Getway mitgeben und den Rechnern in deinem Intranet die desjenigen, der die UM-Leitung überwacht...
Damit sollte meine Konfiguration wie oben beschrieben funktionieren.
Kein PC aus dem Intranet kommuniziert direkt mit einem Internet Mailserver.Ansonsten, wenn also deine PCs i Imtarnet direkt mit einem Mailserver im Internet kommunizieren wollen, hast du ein Problem... Du könntest da vielleicht was mit RIP machen: Getaggte Routen per RIP propagieren und dann mittels Firewall-Regeln das pasende Tag auswählen (policy based routing). Ob das aber wirklich problemlos funktioniert, müßtest du ausprobieren
Vielen Dank für deine Hilfe
Grüße, Manni
Re: VRRP - Ping auf Virtuelle und Master IP
Hi Backslash,
ich habe jetzt weiter getestet und muss ich feststellen, dass das was ich vorhabe nicht wirklich funktioniert.
Ein Beispiel:
Wenn alle netze auf den Master-Router laufen, funktioniert alles, sobald z.B. UM-Leitung ausfällt werden die 3 Netze die an UM-Leitung gebunden sind auf den Standby-Router geswitcht, soweit alles OK.
Nur jetzt, nach dem Switch habe ich das Problem das ich keinen Server aus dem Netzen die jetzt auf den Standby-Router laufen, in der DMZ (Master-Router) erreichen kann, da diese Netze auf den Master-Router geblieben ist.
Ist das so? Habe ich irgendwo ein Fehler in der Konfiguration?
Habe ich jetzt genau das Problem was du hier angesprochen hast?
RIP Propagieren – ehrlich gesagt habe ich keine Ahnung was und wo eingestellt werden sollte.
Sollte es tatsächlich so sein, wie im meinem Fall, das wenn ein Teil der Netze die auf dem Master-Router und ein andere teil auf den Standby-Router laufen das diese sich untereinander nicht sehen können, musste ich die verbliebenen Netze die an CC-Leitung gebunden sind vom Master-Router zwangsweise auf den Standby-Router mit umswitchen. Ich habe das auch probiert und einfach das DSL-Interface von der CC-Leitung auf den Master-Router deaktiviert und das hat funktioniert
Gibt es villeicht eine andere Möglichkeit (eleganter/erprobt) um die CC-Leitung zwangsweise umzuswitchen?
Vielen Dank im Voraus
Grüße, Manni
ich habe jetzt weiter getestet und muss ich feststellen, dass das was ich vorhabe nicht wirklich funktioniert.
Ein Beispiel:
Wenn alle netze auf den Master-Router laufen, funktioniert alles, sobald z.B. UM-Leitung ausfällt werden die 3 Netze die an UM-Leitung gebunden sind auf den Standby-Router geswitcht, soweit alles OK.
Nur jetzt, nach dem Switch habe ich das Problem das ich keinen Server aus dem Netzen die jetzt auf den Standby-Router laufen, in der DMZ (Master-Router) erreichen kann, da diese Netze auf den Master-Router geblieben ist.
Ist das so? Habe ich irgendwo ein Fehler in der Konfiguration?
Habe ich jetzt genau das Problem was du hier angesprochen hast?
Du hast geschrieben Mailserver im Internet und nicht in der DMZ, deswegen dachte ich es betrifft meine Konfiguration nicht.Ansonsten, wenn also deine PCs i Imtarnet direkt mit einem Mailserver im Internet kommunizieren wollen, hast du ein Problem... Du könntest da vielleicht was mit RIP machen: Getaggte Routen per RIP propagieren und dann mittels Firewall-Regeln das pasende Tag auswählen (policy based routing). Ob das aber wirklich problemlos funktioniert, müßtest du ausprobieren
RIP Propagieren – ehrlich gesagt habe ich keine Ahnung was und wo eingestellt werden sollte.
Sollte es tatsächlich so sein, wie im meinem Fall, das wenn ein Teil der Netze die auf dem Master-Router und ein andere teil auf den Standby-Router laufen das diese sich untereinander nicht sehen können, musste ich die verbliebenen Netze die an CC-Leitung gebunden sind vom Master-Router zwangsweise auf den Standby-Router mit umswitchen. Ich habe das auch probiert und einfach das DSL-Interface von der CC-Leitung auf den Master-Router deaktiviert und das hat funktioniert
Gibt es villeicht eine andere Möglichkeit (eleganter/erprobt) um die CC-Leitung zwangsweise umzuswitchen?Vielen Dank im Voraus
Grüße, Manni
Re: VRRP - Ping auf Virtuelle und Master IP
Hi Backslash,
ich nochmal.
Ich habe jetzt doch, versuchsweiße die aktuelle Beta von FTP - 10.20.0156 (01.09.2018) - Installiert aber das Problem aus meinem ersten Posting mit dem Ping auf die Virtuelle oder Master-Router IP in anderen Netzen funktioniert mit der Version auch nicht.
Korrektur:
In den einen Netz funktioniert der Ping auf den Master-Router in dem anderen Netz nicht. Ping auf Virtuelle IP in anderen Netzen nach wie vor nicht.
Beispiele:
Mein PC befindet sich in 20 Netz.
Ping -> 10.1 – Virtuelle IP - geht nicht
Ping -> 10.2 und 10.3 – Master und Standby – OK
Ping -> 30.1 – Virtuelle IP - geht nicht
Ping -> 30.2 und 30.3 – Master und Standby – OK
Ping -> 40.1 und 40.2 – Virtuelle IP und Master - geht nicht
Ping -> 40.3 – Standby – OK
Viele Grüße
Manni
ich nochmal.
Ich habe jetzt doch, versuchsweiße die aktuelle Beta von FTP - 10.20.0156 (01.09.2018) - Installiert aber das Problem aus meinem ersten Posting mit dem Ping auf die Virtuelle oder Master-Router IP in anderen Netzen funktioniert mit der Version auch nicht.
Korrektur:
In den einen Netz funktioniert der Ping auf den Master-Router in dem anderen Netz nicht. Ping auf Virtuelle IP in anderen Netzen nach wie vor nicht.
Beispiele:
Mein PC befindet sich in 20 Netz.
Ping -> 10.1 – Virtuelle IP - geht nicht
Ping -> 10.2 und 10.3 – Master und Standby – OK
Ping -> 30.1 – Virtuelle IP - geht nicht
Ping -> 30.2 und 30.3 – Master und Standby – OK
Ping -> 40.1 und 40.2 – Virtuelle IP und Master - geht nicht
Ping -> 40.3 – Standby – OK
Viele Grüße
Manni
Re: VRRP - Ping auf Virtuelle und Master IP
Hallo Manni4,
ohne alles zu lesen, versuche doch einmal auf der Backup Seite eine zusätzliche VRRP Adresse als Master (ohne Backup) im gleichen Subnetz anzulegen.
Die Backup Seite kann die Master VRRP Adresse nicht erreichen, wenn keine andere VRRP Adresse im gleichen Subnetz als Master aktiv ist ( steht in der Doku ). Im Trace gibt's dafür einen Hinweis.
Viele Grüße
Henri
ohne alles zu lesen, versuche doch einmal auf der Backup Seite eine zusätzliche VRRP Adresse als Master (ohne Backup) im gleichen Subnetz anzulegen.
Die Backup Seite kann die Master VRRP Adresse nicht erreichen, wenn keine andere VRRP Adresse im gleichen Subnetz als Master aktiv ist ( steht in der Doku ). Im Trace gibt's dafür einen Hinweis.
Viele Grüße
Henri
Re: VRRP - Ping auf Virtuelle und Master IP
Hallo Zusammen,
@Henri
vielen Dank für dein Tipp, aber leider hat das nicht geholfen bzw. ist eigentlich meine Meinung gar nicht notwendig, den unter VRRP/Virtuelle-Router sind die Master für das jeweilige Netzwerk auf den beiden Routern bekannt.
@Backslash
Wie es scheint ist bei mir, beim Import Teil der jetzigen Konfig. LCOS 9.24 (als Script Importiert) einiges schiefgelaufen, den plötzlich haben die Firewall-Regeln nicht mehr richtig funktioniert, woran es liegt/lag kann ich momentan nicht sagen.
Ich habe dann eine ganz simple Konfig. mit VRRP zum Testen erstellt und weitergetestet (heute nochmal mit LCOS 10.20.161)
Thema Ping/Routing
Alle Netze sind auf den Master-Router und der PC ist im 192.168.20.0 Netz:
Ping auf die beiden Router IPs (also 192.168.10.2, 192.168.10.3, usw.) in alle Netze funktioniert, Ping auf die VRRP-IP funktioniert nur wenn der PC sich im gleichen Netz befindet.
Switcht wie z.B. in meinem Fall die DMZ (192.168.40.0) auf den Standby-Router dann funktioniert zusätzlich zu der oberen Beschreibung, Ping auf die VRRP-IP 192.168.40.1.
Jetzt aus Sicht der DMZ
Alle Netze sind auf den Master-Router und der PC ist im 192.168.40.0 Netz:
Gleiches verhalten wie im 192.168.20.0 Netz aber sobald die DMZ auf den Standby-Router geswitcht wird, kann ich alle IPs von beiden Router und die VRRP-IPs Pingen.
Ein weiteres Problem z.B. RDP (Remotedesktop) von 192.168.20.40 auf 192.168.40.85 oder umgekehrt (Ping funktioniert):
Sind alle Netze auf dem Master-Router – gibt's kein Problem, wird die DMZ auf den Standby-Router geswitcht kann ich kein RDP mehr aufbauen. Hatte ich eine RDP Verbindung während des Switchs der DMZ auf den Standby-Router offen, bleibt die Verbindung bestehen und wird nicht unterbrochen, schließe ich diese und versuche anschließend wiederaufzubauen, keine Chancen.
Hier die Traces:
Verbindung von 192.168.20.40 -> 192.168.40.85
Router1 - Master
Router2 - Standby
Verbindung von 192.168.40.85 -> 192.168.20.40
Router1 - Master
Router2 - Standby
Wie es scheint gibt's hier bei der RDP Verbindung ein Firewall Problem, oder Interpretiere ich hier was Falsch
Hier die beiden Firewall Regeln (DENY_ALL Strategie)
Wenn du weitere Traces brauchst, sag Bescheid.
Ich bin kein Routing/Netzwerk experte aber ich denke das ein Scenario mit 2 Aktiven WAN Leitung auf einen Router im Zusammenhang mit VRRP und das Switchen von nur ein Teil der Netze auf den Standby-Router bisher nicht vorgesehen war, den VRRP sichert eigentlich nur Geräteausfall.
Ich glaube aber dennoch, dass ich mein Vorhaben nicht so Umsätzen kann, wie ich es gerne hätte.
Leider habe ich momentan echt keine Zeit mich damit weiter zu beschäftigen und muss das Projekt erstmal auf Eis legen.
Vielen Dank und viele Grüße
Manni
@Henri
vielen Dank für dein Tipp, aber leider hat das nicht geholfen bzw. ist eigentlich meine Meinung gar nicht notwendig, den unter VRRP/Virtuelle-Router sind die Master für das jeweilige Netzwerk auf den beiden Routern bekannt.
@Backslash
Wie es scheint ist bei mir, beim Import Teil der jetzigen Konfig. LCOS 9.24 (als Script Importiert) einiges schiefgelaufen, den plötzlich haben die Firewall-Regeln nicht mehr richtig funktioniert, woran es liegt/lag kann ich momentan nicht sagen.
Ich habe dann eine ganz simple Konfig. mit VRRP zum Testen erstellt und weitergetestet (heute nochmal mit LCOS 10.20.161)
Thema Ping/Routing
Alle Netze sind auf den Master-Router und der PC ist im 192.168.20.0 Netz:
Ping auf die beiden Router IPs (also 192.168.10.2, 192.168.10.3, usw.) in alle Netze funktioniert, Ping auf die VRRP-IP funktioniert nur wenn der PC sich im gleichen Netz befindet.
Switcht wie z.B. in meinem Fall die DMZ (192.168.40.0) auf den Standby-Router dann funktioniert zusätzlich zu der oberen Beschreibung, Ping auf die VRRP-IP 192.168.40.1.
Jetzt aus Sicht der DMZ
Alle Netze sind auf den Master-Router und der PC ist im 192.168.40.0 Netz:
Gleiches verhalten wie im 192.168.20.0 Netz aber sobald die DMZ auf den Standby-Router geswitcht wird, kann ich alle IPs von beiden Router und die VRRP-IPs Pingen.
Ein weiteres Problem z.B. RDP (Remotedesktop) von 192.168.20.40 auf 192.168.40.85 oder umgekehrt (Ping funktioniert):
Sind alle Netze auf dem Master-Router – gibt's kein Problem, wird die DMZ auf den Standby-Router geswitcht kann ich kein RDP mehr aufbauen. Hatte ich eine RDP Verbindung während des Switchs der DMZ auf den Standby-Router offen, bleibt die Verbindung bestehen und wird nicht unterbrochen, schließe ich diese und versuche anschließend wiederaufzubauen, keine Chancen.
Hier die Traces:
Verbindung von 192.168.20.40 -> 192.168.40.85
Router1 - Master
Code: Alles auswählen
[IP-Router] 2018/09/12 11:17:49,734 Devicetime: 2018/09/12 11:17:40,217
IP-Router Rx (LAN-1, NETZ2, RtgTag: 20):
DstIP: 192.168.40.85, SrcIP: 192.168.20.40, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 3389, SrcPort: 60233, Flags: S
Seq: 691142144, Ack: 0, Win: 64240, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 8 (multiply by 256)
Option: NOP
Option: NOP
Option: SACK permitted
Route: LAN-2 Tx (LAN-DMZ):
[Firewall] 2018/09/12 11:17:49,780 Devicetime: 2018/09/12 11:17:40,230
Packet matched rule A_NETZ2_TO_LAN-DMZ
DstIP: 192.168.40.85, SrcIP: 192.168.20.40, Len: 40, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 3389, SrcPort: 60233, Flags: A
Seq: 691142145, Ack: 85100877, Win: 256, Len: 0
bad TCP state (SYN/ACK missing)
packet rejected
[IP-Router] 2018/09/12 11:17:49,780 Devicetime: 2018/09/12 11:17:40,230
IP-Router Rx (LAN-1, NETZ2, RtgTag: 20):
DstIP: 192.168.40.85, SrcIP: 192.168.20.40, Len: 40, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 3389, SrcPort: 60233, Flags: A
Seq: 691142145, Ack: 85100877, Win: 256, Len: 0
Filter (Port)
[TraceStopped] 2018/09/12 11:18:16,890
Used config:
# Trace config
trace + IP-Router @ 192.168.40.85
trace + Firewall
# Show commands
Code: Alles auswählen
[IP-Router] 2018/09/12 11:17:49,734 Devicetime: 2018/09/12 11:17:39,569
IP-Router Rx (LAN-2, LAN-DMZ, RtgTag: 40):
DstIP: 192.168.20.40, SrcIP: 192.168.40.85, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 60233, SrcPort: 3389, Flags: SA
Seq: 85100876, Ack: 691142145, Win: 64000, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 0 (multiply by 1)
Option: NOP
Option: NOP
Option: SACK permitted
Route: LAN-1 Tx (NETZ2):
[Firewall] 2018/09/12 11:17:52,749 Devicetime: 2018/09/12 11:17:42,584
Packet matched rule A_LAN-DMZ_TO_NETZ2
DstIP: 192.168.20.40, SrcIP: 192.168.40.85, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 60233, SrcPort: 3389, Flags: SA
Seq: 85100876, Ack: 691142145, Win: 64000, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 0 (multiply by 1)
Option: NOP
Option: NOP
Option: SACK permitted
bad TCP state (ACK expected in session recovery)
packet rejected
[IP-Router] 2018/09/12 11:17:52,749 Devicetime: 2018/09/12 11:17:42,584
IP-Router Rx (LAN-2, LAN-DMZ, RtgTag: 40):
DstIP: 192.168.20.40, SrcIP: 192.168.40.85, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 60233, SrcPort: 3389, Flags: SA
Seq: 85100876, Ack: 691142145, Win: 64000, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 0 (multiply by 1)
Option: NOP
Option: NOP
Option: SACK permitted
Filter (Port)
[Firewall] 2018/09/12 11:17:58,766 Devicetime: 2018/09/12 11:17:48,600
Packet matched rule A_LAN-DMZ_TO_NETZ2
DstIP: 192.168.20.40, SrcIP: 192.168.40.85, Len: 48, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 60233, SrcPort: 3389, Flags: SA
Seq: 85100876, Ack: 691142145, Win: 64000, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: NOP
Option: SACK permitted
bad TCP state (ACK expected in session recovery)
packet rejected
[IP-Router] 2018/09/12 11:17:58,766 Devicetime: 2018/09/12 11:17:48,600
IP-Router Rx (LAN-2, LAN-DMZ, RtgTag: 40):
DstIP: 192.168.20.40, SrcIP: 192.168.40.85, Len: 48, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 60233, SrcPort: 3389, Flags: SA
Seq: 85100876, Ack: 691142145, Win: 64000, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: NOP
Option: SACK permitted
Filter (Port)
[IP-Router] 2018/09/12 11:18:10,784 Devicetime: 2018/09/12 11:18:00,617
IP-Router Rx (LAN-2, LAN-DMZ, RtgTag: 40):
DstIP: 192.168.20.40, SrcIP: 192.168.40.85, Len: 40, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 60233, SrcPort: 3389, Flags: R
Seq: 85100877, Ack: 691142145, Win: 0, Len: 0
Route: LAN-1 Tx (NETZ2):
[TraceStopped] 2018/09/12 11:18:14,002
Used config:
# Trace config
trace + IP-Router @ 192.168.40.85
trace + Firewall
# Show commands
show bootlog
Router1 - Master
Code: Alles auswählen
[IP-Router] 2018/09/12 11:10:02,464 Devicetime: 2018/09/12 11:09:52,954
IP-Router Rx (LAN-1, NETZ2, RtgTag: 20):
DstIP: 192.168.40.85, SrcIP: 192.168.20.40, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 50077, SrcPort: 3389, Flags: SA
Seq: 2263984858, Ack: 987909616, Win: 64000, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 0 (multiply by 1)
Option: NOP
Option: NOP
Option: SACK permitted
Route: LAN-2 Tx (LAN-DMZ):
[Firewall] 2018/09/12 11:10:05,465 Devicetime: 2018/09/12 11:09:55,954
Packet matched rule A_NETZ2_TO_LAN-DMZ
DstIP: 192.168.40.85, SrcIP: 192.168.20.40, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 50077, SrcPort: 3389, Flags: SA
Seq: 2263984858, Ack: 987909616, Win: 64000, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 0 (multiply by 1)
Option: NOP
Option: NOP
Option: SACK permitted
bad TCP state (ACK expected in session recovery)
packet rejected
[IP-Router] 2018/09/12 11:10:05,465 Devicetime: 2018/09/12 11:09:55,954
IP-Router Rx (LAN-1, NETZ2, RtgTag: 20):
DstIP: 192.168.40.85, SrcIP: 192.168.20.40, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 50077, SrcPort: 3389, Flags: SA
Seq: 2263984858, Ack: 987909616, Win: 64000, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 0 (multiply by 1)
Option: NOP
Option: NOP
Option: SACK permitted
Filter (Port)
[Firewall] 2018/09/12 11:10:11,466 Devicetime: 2018/09/12 11:10:01,955
Packet matched rule A_NETZ2_TO_LAN-DMZ
DstIP: 192.168.40.85, SrcIP: 192.168.20.40, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 50077, SrcPort: 3389, Flags: SA
Seq: 2263984858, Ack: 987909616, Win: 64000, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 0 (multiply by 1)
Option: NOP
Option: NOP
Option: SACK permitted
bad TCP state (ACK expected in session recovery)
packet rejected
[IP-Router] 2018/09/12 11:10:11,466 Devicetime: 2018/09/12 11:10:01,955
IP-Router Rx (LAN-1, NETZ2, RtgTag: 20):
DstIP: 192.168.40.85, SrcIP: 192.168.20.40, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 50077, SrcPort: 3389, Flags: SA
Seq: 2263984858, Ack: 987909616, Win: 64000, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 0 (multiply by 1)
Option: NOP
Option: NOP
Option: SACK permitted
Filter (Port)
[IP-Router] 2018/09/12 11:10:23,466 Devicetime: 2018/09/12 11:10:13,955
IP-Router Rx (LAN-1, NETZ2, RtgTag: 20):
DstIP: 192.168.40.85, SrcIP: 192.168.20.40, Len: 40, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 50077, SrcPort: 3389, Flags: R
Seq: 2263984859, Ack: 987909616, Win: 0, Len: 0
Route: LAN-2 Tx (LAN-DMZ):
[TraceStopped] 2018/09/12 11:10:45,058
Used config:
# Trace config
trace + IP-Router @ 192.168.20.40
trace + Firewall
# Show commands
show bootlog
Code: Alles auswählen
[IP-Router] 2018/09/12 11:10:02,464 Devicetime: 2018/09/12 11:09:52,301
IP-Router Rx (LAN-2, LAN-DMZ, RtgTag: 40):
DstIP: 192.168.20.40, SrcIP: 192.168.40.85, Len: 52, DSCP: CS0/BE (0x00), ECT: 1, CE: 0
Prot.: TCP (6), DstPort: 3389, SrcPort: 50077, Flags: SEC
Seq: 987909615, Ack: 0, Win: 8192, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 8 (multiply by 256)
Option: NOP
Option: NOP
Option: SACK permitted
Route: LAN-1 Tx (NETZ2):
[Firewall] 2018/09/12 11:10:02,464 Devicetime: 2018/09/12 11:09:52,302
Packet matched rule A_LAN-DMZ_TO_NETZ2
DstIP: 192.168.20.40, SrcIP: 192.168.40.85, Len: 40, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 3389, SrcPort: 50077, Flags: A
Seq: 987909616, Ack: 2263984859, Win: 256, Len: 0
bad TCP state (SYN/ACK missing)
packet rejected
[IP-Router] 2018/09/12 11:10:02,464 Devicetime: 2018/09/12 11:09:52,302
IP-Router Rx (LAN-2, LAN-DMZ, RtgTag: 40):
DstIP: 192.168.20.40, SrcIP: 192.168.40.85, Len: 40, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 3389, SrcPort: 50077, Flags: A
Seq: 987909616, Ack: 2263984859, Win: 256, Len: 0
Filter (Port)
[TraceStopped] 2018/09/12 11:10:46,742
Used config:
# Trace config
trace + IP-Router @ 192.168.20.40
trace + Firewall
# Show commands
show bootlog
Hier die beiden Firewall Regeln (DENY_ALL Strategie)
Code: Alles auswählen
"NETZ2" {Description} "%A192.168.20.0 %M255.255.254.0"
"LAN-DMZ" {Description} "%A192.168.40.0 %M255.255.255.0"
"A_LAN-DMZ_TO_NETZ2" {Prot.} "ANY" {Source} "LAN-DMZ" {Destination} "NETZ2" {Action} "ACCEPT" {Linked} No {Prio} 1 {Firewall-Rule} Yes {VPN-Rule} No {Stateful} Yes {Src-Tag} 0 {Rtg-tag} 20 {Comment} ""
"A_NETZ2_TO_LAN-DMZ" {Prot.} "ANY" {Source} "NETZ2" {Destination} "LAN-DMZ" {Action} "ACCEPT" {Linked} No {Prio} 1 {Firewall-Rule} Yes {VPN-Rule} No {Stateful} Yes {Src-Tag} 0 {Rtg-tag} 40 {Comment} ""
Ich bin kein Routing/Netzwerk experte aber ich denke das ein Scenario mit 2 Aktiven WAN Leitung auf einen Router im Zusammenhang mit VRRP und das Switchen von nur ein Teil der Netze auf den Standby-Router bisher nicht vorgesehen war, den VRRP sichert eigentlich nur Geräteausfall.
Ich glaube aber dennoch, dass ich mein Vorhaben nicht so Umsätzen kann, wie ich es gerne hätte.
Leider habe ich momentan echt keine Zeit mich damit weiter zu beschäftigen und muss das Projekt erstmal auf Eis legen.
Vielen Dank und viele Grüße
Manni
Re: VRRP - Ping auf Virtuelle und Master IP
Hi manni4,
deine Traces sgaen mir, daß der RDP-Server in der DMZ nicht die VRRP-IP als Default-Gateway hat, sondern die physikalische von Router 2, denn sonst würde das SYN/ACK im ersten Fall bzw. das SYN im zweiten nicht bei Router 2 ankommen, sondern bei Router 1, der ja Master ist...
Gruß
Backslash
deine Traces sgaen mir, daß der RDP-Server in der DMZ nicht die VRRP-IP als Default-Gateway hat, sondern die physikalische von Router 2, denn sonst würde das SYN/ACK im ersten Fall bzw. das SYN im zweiten nicht bei Router 2 ankommen, sondern bei Router 1, der ja Master ist...
Gruß
Backslash
Re: VRRP - Ping auf Virtuelle und Master IP
Hi Backslash,
Wo ich das gelesen habe, ich dachte mich trifft der Schlag - ich habe tatsächlich bei den vielen Tests den Default-Gateway mal geändert gehabt.
Aber es ist nicht so, ist alles Korrekt, auf den PC ist der Default-Gateway VRRP-IP 192.168.20.1 und der RDP-Server hat die VRRP-IP 192.168.40.1 als Default-Gateway.
Viele Grüße
Manni
Wo ich das gelesen habe, ich dachte mich trifft der Schlag - ich habe tatsächlich bei den vielen Tests den Default-Gateway mal geändert gehabt.
Aber es ist nicht so, ist alles Korrekt, auf den PC ist der Default-Gateway VRRP-IP 192.168.20.1 und der RDP-Server hat die VRRP-IP 192.168.40.1 als Default-Gateway.
Viele Grüße
Manni