[Gelöst] hinzufügen einer zweiten Public IP unterbricht VPN

[Radio2]

Hallo in die Runde,

heute habe ich ein sehr spezielles Problem, das ich Hoffe mit euch lösen zu können. Gegeben ist eine XL12500 die über einen externen Router mit Internet versorgt wird. Wir haben einen statischen IP Adress Kreis in der Form xx.xx.xx.200 / 255.255.255.248
Hosts von 201 bis 206
Auf dem Interface zum externen Router ist als IP/Maske folgendes eingetragen: xx.xx.xx.202 / 255.255.255.248
Routing Default GW zur xx.xx.xx.201 und auf der LAN Schnittstelle zum externen Router xx.xx.xx.200 / 255.255.255.248 GW xx.xx.xx.202
Das funktioniert alles, Internet geht, VPN geht. Ein Server kann per NAT Regeln und Port Forward von außen erreicht werden.

Jetzt kommt im LAN ein 2. Server, der wegen LetsEncrypt auch von außen erreichbar sein soll hinzu. Er soll dann von außen über den einen Hostrecord per DNS Name unter der .203 erreichbar sein. NAT Regeln sind erstellt.
Der nächste Schritt ist nun im Bintec unter LAN, IP-Konfiguration, (Interface), Grundlegende IPv4-Parameter, IP-Adresse hinzufügen die xx.xx.xx.203 einzutragen. Hier haben wir als Maske .255 gewählt (Testweise auch schon .248).
Soweit alles schick, der neue Server ist von extern unter .203 erreichbar, Portforwardings gehen. Hurra? Leider nein.

Soweit die Vorrede, jetzt das Problem: eine konfigurierte Site-2-Site IPsec Verbindung mit einer Fritz!Box (FW 7.5x) hört auf Daten zu befördern, in dem Augenblick wo die .203 im Bintec aktiviert wird. Weiterer vorhandene VPN Einwahlverbindungen für Clienten mit Shrew und NCP funktionieren weiter. Die Verbindung zwischen Bintec und Fritzbox steht, alles grün, aber kein Datenfluss. Man kann die Verbindung auch Problemlos auf/abbauen aber es geht kein Ping oder sonstiger Zugriff durch den Tunnel. Sobald man die .203 im Bintec wieder entfernt geht der Ping sofort wieder durch ohne den Tunnel neu zu aktivieren..

Das lässt uns nun etwas ratlos zurück. Seit der AVM Firmware 7.5.x ist bei IPsec in der Fritzbox irgendetwas anders. Seit dieser Firmware muss ich IPsec Verbindungen wieder über das externe Config Tool erstellen und importieren, der interne Assistent für eine Kopplung über KeyID geht nicht mehr. Da wird auch nur die Verbindung hergestellt, keine Daten fließen.

Die Config (anonymisiert) für die Fritzbox ist auch sehr einfach und rudimentär:

/*
 *
 */

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "VPNname";
                always_renew = no;
                keepalive_ip = 172.16.0.1;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "vpn.domain.tld";
                localid {
                        fqdn = "meinefritzbox.myfritz.net";
                }
                remoteid {
                        fqdn = "vpn.domain.tld";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geiheimerkey";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 172.16.0.0;
                                mask = 255.252.0.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 172.16.0.0 255.252.0.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}


// EOF

Die Maske 255.252.0.0 für die Bintec Gegenstelle verwenden wir um weitere Netze im Bereich 172.x zu erreichen und uns zusätzliche Routing Einträge sparen zu können. Der Bintec hat die LAN IP 172.16.0.1. Das funktioniert problemlos.

Was wir nicht verstehen: Was hat das hinzufügen der .203 für eine Auswirkung auf die IPsec Verbindung, die über die .202 reinkommt? Darauf zeigt ja vpn.domain.tld und wird in der FritzBox auch korrekt aufgelöst angezeigt. Da die VPN Verbindung steht und Problemlos aufgebaut wird aber keine Daten fließen tippen wir auf ein Routing Problem, sind aber noch nicht dahinter gekommen, wo das steckt.

Blickt hier jemand durch und hat einen Tipp für uns?

Gruß

 

[Radio2]

Ich glaube der Thread kann zu. It's Magic, auf einmal funktioniert es sogar ohne die .203 im Router hinzuzufügen. Vermutlich wurden im Provider-Router anpassungen vorgenommen, die wir nicht einsehen können. Jedenfalls geht es jetzt erst mal.

 

[stoney]

Ich glaube der Thread kann zu

Bearbeiten -> Präfix auf [Gelöst] oder [Erledigt] setzten

 

[Radio2]

mmhh, vielleicht doch noch nicht :/ Momentan ist die .203 wieder nicht erreichbar ohne das jemand etwas geändert hat. Das ist sehr mysteriös und vielleicht kann doch noch mal jemand über das erste Posting gucken.

 

[frank_m24]

Ein Server kann per NAT Regeln und Port Forward von außen erreicht werden.

Verstehe ich das richtig, du konfigurierst das öffentliche Netz ausschließlich auf virtuelle Interfaces oder virtuelle IPs im Router und machst dann ein Mapping auf interne IP-Adressen (172.16.x.y) im LAN? Die Server im LAN erhalten keine öffentliche IP mit einem vollwertigen Routing? Ist das ein vollwertiges Mapping von einer öffentlichen IP auf einen internen Host, oder kannst du auch Portweiterleitungen auf mehrere interne Hosts anlegen von einer öffentlichen IP aus?

Ist das wirklich so vorgesehen? Wenn du mehrere öffentliche IPs aus dem gleichen Subnetz anlegst, dann könnte das das Routing natürlich gründlich durcheinander bringen. Grundsätzlich könnte ich mir da zwei Probleme vorstellen, in Abhängigkeit von der Umsetzung im Bintec:

• Wenn die Einrichtung im Bintec über virtuelle Interfaces erfolgt, die die öffentlichen IPs aufnehmen, dann hast du plötzlich mehrere Interfaces im gleichen Subnetz. Damit ist nicht mehr klar, welche Route greift und über welches Interface das System die Pakete zum Default Gateway schicken will. In der Folge können einzelnen Anwendungen, Hosts oder das gesamte Netz zusammenbrechen
• Wenn die Einrichtung im Bintec über mehrere virtuelle IPs auf einem Interface erfolgt, dann hast du plötzlich mehrere IPs aus dem gleichen Bereich auf einem Interface. Hier ist dann die Frage, welche IP das System als Abgangs-IP für gesendete Pakete nimmt. Antworten auf Pakete, die an die 202 gesendet wurden, können mit der Absender IP 203 losgeschickt werden. Du kannst dir vorstellen, was das im Sender macht, wenn es Pakete von der 202 erwartet und von der 203 bekommt.

Beide Probleme erklären die von dir beobachteten Symptome zuverlässig, sowohl fürs VPN als auch für die nicht funktionierenden Portweiterleitungen. Auch der Umstand, dass es mal geht und mal nicht, lässt sich über den Zufallscharakter der Konfiguration schlüssig erklären.
Und deshalb noch mal die Frage: Ist das so vorgesehen, dass du mehrere öffentliche IPs ausschließlich im Router zuweist? Ich kenne das eigentlich anders: Die Server im Netz erhalten direkt die öffentliche IP und der Router routet vollwertig und nicht per NAT. Das würde diese Probleme zuverlässig vermeiden. Ich weiß aber nicht, ob Bintec sowas unterstützt.

Das lässt uns nun etwas ratlos zurück. Seit der AVM Firmware 7.5.x ist bei IPsec in der Fritzbox irgendetwas anders.

IKEv2 und IPv6 sind natürlich erhebliche Änderungen.

 

[Radio2]

Ich versuche es mal anders zu erklären. Du merkst, richtig sattelfest bin ich nicht in diesem Thema.

Es gibt ein LAN Segment 172.16.x.x.
Der Bintec ist in dem LAN unter 172.16.0.1 konfiguriert
Dann gibt es zwei Server 172.16.2.1 und 172.16.2.2 bei denen die Ports 25, 80 und 443 vom Internet aus erreichbar sein sollen.
Vom Internet Anbieter existiert ein Router im Haus, der vor dem Bintec sitzt
Wir haben auf dem Interface des Bintec zum Provider Router folgende IP Vorgaben: xx.xx.xx.200/29
Im Interface zum Provider Router ist unter Grundlegende IPv4-Parameter: Sicherheit nicht vertrauenswürdig, Adressmodus statisch, IP-Adresse xx.xx.xx.202 Maske 255.255.255.248
Daraus resultieren dann 2 Routing Einträge:
Ziel IP-Adresse 0.0.0.0 Maske 0.0.0.0 GW: xx.xx.xx.201 Schnittstelle zum Provider Router, Standardroute über Gateway
Ziel-IP-Adresse xx.xx.xx.200 Maske 255.255.255.248 GW: xx.xx.xx.202 Schnittstelle zum Provider Router, Netzwerkroute via Schnittstelle
Jetzt sind für den Server1 3 NAT Einträge gemacht:
eingehend http Quelle 0.0.0.0 Ziel xx.xx.xx.202:80 Neu 172.16.2.1/32
eingehend https Quelle 0.0.0.0 Ziel xx.xx.xx.202:443 Neu 172.16.2.1/32

Für den Server2
eingehend http Quelle 0.0.0.0 Ziel xx.xx.xx.203:80 Neu 172.16.2.2/32
eingehend https Quelle 0.0.0.0 Ziel xx.xx.xx.203:443 Neu 172.16.2.2/32
eingehend smtp Quelle 0.0.0.0 Ziel 0.0.0.0:25 Neu 172.16.2.2/32

Für die .202 und .203 sind beim Internetprovider der Domain A-Records angelegt. Der Zugriff auf Server1 funktioniert mit http und https von extern, der Zugriff des MX auf Server2 funktioniert auch.

Die eigentliche Aufgabe ist nur der Zugriff auf Port 80/443 auf Server2. Hier läuft u.a. wie auch Server1 ein LetsEncrypt Dämon und so muss der Server über Port 80 vom Internet erreichbar sein. Da kein Reverseproxy vorhanden ist, der wieder andere Probleme machen würde, war der Gedanke die derzeit nicht genutzte öffentliche IP xx.xx.xx.203 dafür zu benutzen und die auf den Server2 für die entsprechenden Port zu leiten. Dazu haben wir diese IP unter LAN, IP-config, Interface, Grundlegende Parameter als 2.IP hinzugefügt. Dort steht dann also:
1. IP xx.xx.xx.202 maske 255.255.255.248 (/29)
2. IP xx.xx.xx.203 maske 255.255.255.255 (/32)

Das Funktioniert soweit auch alles wie es soll. Der 2. Server ist nun vom Internet über die A-Records oder direkte IP auf den gewünschten Port (per NAT) erreichbar. So stehts ja auch in der Bintec Dokumentation unter folgendem Link:
https://faq.bintec-elmeg.com/index....zweiten_IP-Adresse_zu_einer_LAN-Schnittstelle

Alles schick nur in dem Augenblick, wo wir die xx.xx.xx.203 aktivieren ist der Traffic der VPN Site-2-Site Verbindung blockiert. Die Verbindung steht noch, es fließen keine Daten. Dafür ist aber in diesem Moment Server2 über das Internet erreichbar. Jetzt wird es aber noch kurioser...

Wir deaktivieren also die .203 wieder, Traffic im VPN ist sofort wieder da und auch Server2 ist noch immer erreichbar! Freude! ... aber nur 1-2h, danach ist der Server wieder weg als ob da irgendwo eine Route gelernt wurde (außerhalb unseres Einflussbereich) die nach dem entfernen der .203 eine zeit weiter besteht und dann abläuft. So stellt sich das Problem so ausführlich beschrieben wie möglich dar.

Die Site-2-Site Verbindung ist über statische IPs realisiert, keine Server Zuweisung. Angesprochen wird die xx.xx.xx.202 über einen A-Record beim Provider (vpn.domain.tld).

Ist das jetzt klarer beschrieben, wie das gelöst ist? Die Server stehen nicht public im Internet, die haben eine LAN IP.

Gruß

 

[frank_m24]

Alles schick nur in dem Augenblick, wo wir die xx.xx.xx.203 aktivieren ist der Traffic der VPN Site-2-Site Verbindung blockiert.

Hast du die Möglichkeit, den Traffic mitzuschneiden? Ich bin mir ziemlich sicher, dass VPN plötzlich die falsche IP als Abgangs-IP benutzt. Kannst du ggf. auch auf der Fritzbox auf der anderen Seite verifizieren.

Wir deaktivieren also die .203 wieder, Traffic im VPN ist sofort wieder da und auch Server2 ist noch immer erreichbar! Freude! ... aber nur 1-2h, danach ist der Server wieder weg als ob da irgendwo eine Route gelernt wurde (außerhalb unseres Einflussbereich) die nach dem entfernen der .203 eine zeit weiter besteht und dann abläuft.

Das dürften die ARP Einträge sein.

Die Server stehen nicht public im Internet, die haben eine LAN IP.

Ja, hab ich mir gedacht. Wie gesagt, ich kenne das anders. Die öffentlichen IPs nur im Router anzulegen, ist eher ungewöhnlich.

 

[Radio2]

Danke das Du dir die Zeit nimmst hier rein zu sehen.
Das mit ARP und den Routen leuchtet ein. Spielt hier der Provider Router eine Rolle oder liegt das dann im Einflussbereich des Bintec?
Datenmitschnitt ist jetzt erst mal nicht möglich da wir die Site-2-Site vorübergehen gekappt haben damit die eigentlich Einrichtung des Servers in der Zentrale weiter gehen kann. Da gibt es Termine. Übergangsweise behelfen wir uns mit Client Einwahlen um in die Zentrale zu kommen. Das Thema ist aber noch nicht vom Tisch und bleibt weiter aktuell, nur können wir da heute nicht den laufenden Betrieb stören.

Ganz blöd gedacht hilft vielleicht auch ein Router Neustart Den können wir aber auch nur zu festen Terminen machen.

/Nachtrag:
Es ist wohl nicht nur unsere Site-2-Site Verbindung betroffen sondern noch eine 2. Verbindung die wir gar nicht auf dem Schirm hatte da wir damit nichts zu haben. Die läuft auch Site-2-Site mit IKE2 und da kommt es genau zu dem gleichen Effekt und damit liegt es nicht an der Fritzbox. Zumindest das ist schon mal sicher.

Kurzfassung: Client-2-Site über IPpools im Bintec gehen immer, Site-2-Site mit statischen Adressen gehen nicht. Heute Nacht gibt es erst mal einen Neustart des Bintecs und wir sehen was passiert. Danach muss man mal sehen ob wir an die Routing Tabelle des Provider Routers ran kommen um zu sehen was da drin steht und dann gibts bei Bintec ein Ticket. Das Problem ist irgendwo trickreich.

 

[frank_m24]

Das mit ARP und den Routen leuchtet ein. Spielt hier der Provider Router eine Rolle oder liegt das dann im Einflussbereich des Bintec?

Das ist eher Sache des vorgelagerten Routers. Dessen ARP Eintrag wird ungültig und er findet die zugehörige MAC nicht mehr, wenn ihn ein Paket für die IP erreicht. Und wenn er danach fragt, antwortet der Bintec nicht mehr, weil dort die IP entfernt wurde.

Schaut euch das mit den Abgangs-IPs bei Gelegenheit mal an. Ich könnte mir da durchaus ein Problem vorstellen. Dann müsste man sehen, wie man das gelöst bekommt. Ggf. ist es einfach nur ein Bug in der Firmware. Es könnte aber auch ein grundsätzliches Problem sein, und dann müsste man sehen, wie man dran vorbeikommt. Eine Idee hab ich da auf Anhieb auch nicht.

 

[Radio2]

Das Problem ist umgangen. Wir haben alles richtig gemacht mit der 2. IP und NAT Regeln. Die Lösung war ... ein Neustart vom Bintec Router. Danach lief alles wie gewollt. Es scheint so als ob irgendwo ein kleiner Bug existiert der die Settings für die 2. IP in Verbindung mit VPN nicht richtig on the fly handhabt. Da wir erst ein Zeitfenster für den Neustart finden mussten hat es natürlich etwas gedauert bis wir da zu einem Ergebnis kommen konnten. Fazit: viel gelernt, viel Zeit geopfert, ein paar graue Haare mehr.

/update: Der Neustart ist nicht wirklich die Lösung sondern nur die Änderung von Symptomen. Durch die 2. Site-2Site Kopplung (IKEv2) sehen wir mehr. Da taucht auf einmal auf, das die VPN Anfragen über die .202 reinkommen (ist ja richtig) aber über die .203 beantwortet werden! Warum auch immer. Diesbezügliche Routing Einstellungen können wir nicht finden. Unser Workaround: Site-2-Site wird jetzt über die .203 hergestellt. Das geht jetzt zumindest mit der ersten von zwei Verbindungen. Warum Client-2-Site davon nicht betroffen ist bleibt ein Rätsel. Hier ist der Unterschied, das die IP Dynamisch aus einem Pool geholt wird. Die zweite Verbindung wird demnächst auch noch angepasst und wir vermuten das es dann alles geht.

 

[Radio2]

Eine weitere Erkenntnis haben wir noch gewonnen, die wohl die Grundsätzliche Ursache all unser Probleme ist. Wenn man einen öffentlichen IP Block zum Internet hat (in unserem Fall ein /29) und nur eine davon im Router einträgt ist alles gut. Er nimmt die IP als Internet Adresse und schickt sie zum GW des Blocks. In unserem Fall ist die öffentliche IP die .202 und das GW die .201.
In dem Augenblick wo man eine zweite oder dritte öffentliche IP einträgt (hier die .203) wird auf einmal die zuletzt eingetragene IP zur Absender IP Richtung Internet. Auf einmal surft man im Internet auch mit der .203. Dadurch ist klar, warum die VPN Verbindung in dem Fall steht aber keine Daten fließen. Warum das aber nicht bei den Client VPNs mit Pool IP passiert ist weiter unklar. Die kommen über die .202 rein und gehen darüber auch raus. Die Probleme machen nur die Verbindungen mit statischen IPs. Wo man hier das offensichtliche falsche Routing korrigiert haben wir nicht raus gefunden. Workaround besteht darin die statischen VPNs über die .203 laufen zu lassen anstatt über die .202

 

[frank_m24]

In dem Augenblick wo man eine zweite oder dritte öffentliche IP einträgt (hier die .203) wird auf einmal die zuletzt eingetragene IP zur Absender IP Richtung Internet. Auf einmal surft man im Internet auch mit der .203. Dadurch ist klar, warum die VPN Verbindung in dem Fall steht aber keine Daten fließen.

Wie oft hab ich genau das oben beschrieben? Und deshalb noch mal die Frage: Ist das so vorgesehen? Weil man macht das eigentlich auch nicht! Dem Router mehrere öffentliche IPs zuweisen und dann Portweiterleitungen ins LAN ist auch echt von hinten durch die Brust ins Auge.

Wo man hier das offensichtliche falsche Routing korrigiert haben wir nicht raus gefunden.

Das kannst du nicht lösen. Du hast zwei gleichberechtigte IPs aus dem gleichen Subnetz auf dem gleichen Interface. Was willst du da machen? Es ist pures Glücksspiel, welche abgehend benutzt wird.

Workaround besteht darin die statischen VPNs über die .203 laufen zu lassen anstatt über die .202

GEFÄHRLICH! Weil plötzlich ohne Ankündigung oder nach einem Neustart oder Verbindungsabbruch kann es auch mal wieder 202 sein. Stell dich drauf ein, das WIRD passieren. Die Frage ist nicht, ob, sondern wann. Es ist genau das, was ich oben schon angekündigt habe. Kann übrigens auch bei den VPN Clients passieren.

Es gibt nur eine Lösung für dein Problem: Verpasse dem Server die öffentliche IP und route vollwertig. Alles andere wird zu unvorhersehbarem Verhalten führen!

 

[CapFloor4711]

Hi,

Es gibt nur eine Lösung für dein Problem: Verpasse dem Server die öffentliche IP und route vollwertig. Alles andere wird zu unvorhersehbarem Verhalten führen!

das stimmt so nicht ganz. Das "vollwertige Routen" funktioniert zwar, verbrät aber nutzlos einen Haufen (öffentliche) IP-Adressen. Es gibt allerdings auch mindestens eine andere Möglichkeit, die die effektive Nutzung von IP-Adressen für die DMZ-Hosts erlaubt. Ich habe das mal in - diesem Beitrag - beschrieben.

VG