IPsec: IP Adress-Konflikt bei VPN-Verbindungen zu unterschiedlichen FBen im selben lokalen Subnetz

[odoll]

Moin,

da z.Z. mein UM Kabel-Anschluss gestört ist fällt mir gerade diese Nickeligkeit der FBen wieder auf.

Normalerweise terminiere ich meine VPN-Verbindung zu meiner 6490 (150/10). So weist diese z.B. der Konfig meines PCs (Shrewsoft) die .128 und die .129 für mein Android-Handy zu.

Nun habe ich z.Z. für das Handy auch einen VPN-Zugangspunkt auf meiner 7490 mit DSL-Anschluss (17.5/1.2), allerdings vergibt die 7490 nun auch die .128.

Das wäre halb so wild, wenn die lokalen "VPN IPs" nur dann aktiv wären, wenn die entsprechende Verbindung aktiv wäre. Aber leider scheints so zu sein, dass die FBen sich unabhängig davon nun beide immer (*) zuständig fühlen (ARP Requests), was natürlich zu Problemen führt.

Ich vermute dies kann man nur im Workaround lösen, in dem man z.B. manuell mittels FBEditor die Config ausliest, dort das Mapping auf eine "freie" IP ändert und dann zurück spielt?!

Oder sollte / kann man die VPN-Konfigs extern mit den vorgesehenen IPs erstellen und diese dann importieren um diese Konflikte zu vermeiden?

 

[koyaanisqatsi]

Moin

Ich nehm auf den androiden Geräten für die VPN Verbindung: MyFRITZ!App 2 (Heimnetzverbindung - Einzurichten im F!B W-LAN)
Dann im/über Mobilfunkinternet das auf dem Homescreen gelegte Widget (Heimnetzverbindung) tappen und gut is.
(probiers doch auch mal aus)

 

[odoll]

ok danke - aber löst das das Problem, dass dann keine Konflikte entstehen, da die App dafür sorgt, dass die VPN-Endpunkt-IPs auf den unterschiedlichen FBen disjunkt bleiben?

 

[Benares]

Soweit ich weiß beginnt die Fritzbox mit der Vergabe der VPN-Ports oberhalb des DHCP-Adressbereichs aufsteigend also beispielsweise mit 200 beim Standard-DHCP-Range 10-199.
Durch setzten des DHCP-Portranges hast also indirekt Einfluss auf die Vergabe der VPN-Ports.

 

[PeterPawn]

Wenn Du einfach die entsprechende VPN-Verbindung deaktivierst, antwortet die FRITZ!Box auch nicht mehr als Proxy auf ARP-Requests für die Client-Adressen. Wenn also der UM-Anschluß im Moment ohnehin keine VPN-Verbindung aufbauen kann, sollte es (wenn ich nicht etwas fundamental falsch verstanden habe) auch ausreichen, einfach auf dieser Box den Haken aus der Checkbox in der Liste der VPN-Verbindungen zu entfernen für die betreffenden Verbindungen.

 

[odoll]

Nein, hast Du schon richtig verstanden Im Augenblick habe ich auch 'Alles unter Kontrolle' (*) ;-)

Ich möchte nur gern für den hoffentlich bald wieder einsetzenden "Normal"-Betrieb die (konfliktfreie) Möglichkeit schaffen, dass die VPN-Setting zukünftig auf allen FBen 'scharf' sind, und ich im Störungsfall nicht erst noch hier und da konfigurieren / rumklicken muss (inbs. von Remote).

(*) Anekdote am Rande: Die UM Hotline sagte mir bereits heute morgen, dass nicht nur mein Anschluss von der Störung betroffen sei, sondern auch noch weitere Anlieger.
Vorsorglich, obwohl ich bereits der Meinung war, dass der "Hausbesuch" eines UM (Sub)-Technikers bei mir daher nicht zur Störungsbeseitung beitragen würde, habe ich in der Familie nachgefragt, wann denn heute jemand wieder zuhause wäre und einen Techniker in Empfang nehmen könnte.
Und siehe da, es meldet sich ein Subunternehmen auf meinem Handy und "zwingt" mir einen Besuch auf.
Der Techniker war dann auch gegen 15:30 vor Ort, hat als erstes (wie ich per Zweit-VPN beobachten konnte) erst mal die 6490 rebootet - natürlich ohne Erfolg.
Dann ist er mit meinem 'Schwieger'sohn draußen messen gewesen um festzustellen, dass ja die ganze Straße "tot" ist. Alsim dann noch mal mitgeteilt wurde, dass das ja schon die Hotline "diagnostiziert" hatte, sagte er, ihm hätte das niemand gesagt, und da müßte jemand anders kommen ... Entstörung wird also noch was dauern ...

 

[PeterPawn]

Also zumindest halb falsch verstanden ... generell würde ich jedem, der etwas "ausgefeiltere" VPN-Einstellungen braucht (und zwei Boxen mit demselben Subnetz, auf denen auch noch identische VPN-Accounts existieren, gehören m.E. schon dazu), zur Benutzung von "templates" raten.

Wenn man keine Vorlagen hat, exportiert man einfach die Einstellungen, läßt diese Export-Datei entschlüsseln und zerlegen und macht sich aus der "vpn.cfg" dann seine eigenen (einzelnen) Dateien.

Ich würde heutzutage nicht einmal mehr das AVM-Programm "FRITZ!Fernzugang konfigurieren" verwenden ... höchstens noch dann, wenn ich verschlüsselte VPN-Einstellungen (das Prinzip der Verschlüsselung ist dasselbe wie bei den Export-Dateien) an jemand anderen weitergeben wollte.

 

[odoll]

Soweit ich weiß beginnt die Fritzbox mit der Vergabe der VPN-Ports oberhalb des DHCP-Adressbereichs aufsteigend ...

Danke für Deinen Hinweis, den ich bis dato übersehen habe.

Allerdings scheint dies bei mir aber nicht zu greifen. Zum einen habe nicht nur einer sondern sogar beiden FBen - bzw. den FB allgemein - wegen andere DNS Nickeligkeiten schon seit Längerem per separatem dnsmasq die Hohheit über DHCP / DNS entzogen, und obwohl die eingetragenen Bereiche jetzt schon unterschiedlich sind (7490/DSL .120-160, 6490-UM .60-.80) vergeben beide trotzdem ab .128 aufwärts.

generell würde ich jedem, der etwas "ausgefeiltere" VPN-Einstellungen braucht (und zwei Boxen mit demselben Subnetz, auf denen auch noch identische VPN-Accounts existieren, gehören m.E. schon dazu), zur Benutzung von "templates" raten.

Wenn man keine Vorlagen hat, exportiert man einfach die Einstellungen, läßt diese Export-Datei entschlüsseln und zerlegen und macht sich aus der "vpn.cfg" dann seine eigenen (einzelnen) Dateien.

Ich würde heutzutage nicht einmal mehr das AVM-Programm "FRITZ!Fernzugang konfigurieren" verwenden ... höchstens noch dann, wenn ich verschlüsselte VPN-Einstellungen (das Prinzip der Verschlüsselung ist dasselbe wie bei den Export-Dateien) an jemand anderen weitergeben wollte.

Ja, mit "Oder sollte / kann man die VPN-Konfigs extern mit den vorgesehenen IPs erstellen und diese dann importieren um diese Konflikte zu vermeiden?" meinte ich Templates, allerdings in der Hoffnung, dass man in den Templates auch die IP, die die FB nutzen soll, festlegenen kann.

BTW: die VPN Konfigs auf den beiden FB nutzen zwar gleichlautende Benutzernamen - weil ich mich mit dem 'Hauptnutzer' unter dem Namen eben an allen anmelde, allerdings ist der "Rest" natürlich indviduell, was z.B. die PSKs oder eben auch die DynDNS Adressen betrifft.

 

[Benares]

Egal wie, es geht ja m.E. nur darum, die IP-Vergabe beim Anlegen neuer VPN-Zugriffe irgendwie zu steuern. Direkten Einfluss hat man wohl nicht darauf. Also lösche, die bisherigen, setzt den DHCP-Bereich (ggf. DHCP-Server temporär aktivieren, evtl. ist dafür auch ein temporärer Wechsel der Betriebsart notwendig) und definiere sie neu. Bei mir hat das bisher immer geklappt.

Oder, du erstellst die Konfi, wie von Peter vorgeschlagen, halt manuell und importierst sie. Das ist aber der weitaus steinigere Weg.
Hier dafür mal ein älteres, abschreckendes Beispiel von mir, die Werte in <> musst dafür natürlich anpassen. Ob das alles noch so stimmt, dafür leg ich aber meine Hand nicht ins Feuer.

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_user;
                name = "<Name>";
                always_renew = no;
                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 = <IP>;
                remoteid {
                        key_id = "<Name>";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "<Schlüssel>";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "<Name>";
                        passwd = "<Password>";
                }
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = <IP>;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist =
                             "permit ip any <IP> 255.255.255.255";
        }
        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";
}