[Gelöst] VPN zw. DSL-Box in D und UMTS-Box in ES - ES-Verbindung hat 2 IPs (1 priv 1 öffentl)?

Micha0815 · 14 Aug 2015

Wenn sie (die dritten) keinerlei Passwörter sowohl von der DE-FB alsauch ES-FB kennen und eben nur mit bedingtem Zugriff/PW auf die IP des Poolcontrollers zugreifen können??? OK sie sehen per Scannen der IP-Ranges ggfs. andere Clients (PC/Drucker/TV/STB/NAS usw.) ... das meiste davon lässt sich imho PW-schützen.

Zumindest protokolliert die DE-Box die VPN-Zugriffe. Ok wenn das so obskure Gesellen sind, die Dir vermeintlich bei der Poolsteuerung behilflich sein wollen??? und im Bypass Deine Netzwerke (Clients) angreifen wollen und 24h via VPN verbunden sind ... geschenkt.

PeterPawn und andere haben philosophiert, wie LAN-Clients ggfs. sogar WLAN-Clients hinter einer Fritzbox attackieren können/könnten. Im Normalfall sind einem die User/Clients bei privaten Anschlüssen/FBs mehr oder weniger persönlich bekannt? Meine Meinung.

Ich bin kein Netzwerkspezialist -nur einfachster User- und bin daher etwas konfus, wie über zwei Netzwerke/IP-Ranges ein einziges Gerät per unikater IP

ort ansprechbar sein soll und der Rest an Clients aus den IP-Ranges vollständig verborgen dabei bleibt.

LG

Docmarten · 18 Aug 2015

PeterPawn schrieb:
Das kannst Du dann auch per Fernzugriff auf das GUI der Box in ES und das Wählen eines Telefonbucheintrags dort realisieren. [...] Die IP-Telefone können jedenfalls die Tastencodes nicht ohne weiteres verwenden, zumindest bisher speist AVM diese (meines Wissens) nicht in das emulierte Q.931 ein und der "telefon"-Daemon liest die wohl nur von dort.

Der Vollständigkeit halber: Ich habe gerade mal die Fritz!App Fon auf dem iPhone, das ich zuvor aus dem 7270er-Büronetz per VPN mit dem 7490er DE-DSL-Netz (welches wiederum mit dem 7490er-ES-UMTS-Netz per VPN verbunden ist) gestartet und mit *13# die Yoigo-Mobilfunknummer für einen ausgehenden Anruf an die spanische Festnetznummer genutzt. Hat geklappt.
Ebenso konnte ich mich gerade *121# und der Sipgate-Nummer hier im Büro anrufen (Ortsgespräch

)
Insofern gehe ich mal davon aus, dass auch der Telefonica-Keep-Alive-Anruf klappen wird.

Docmarten · 1 Okt 2015

Zwischenbericht: Das läuft jetzt seit sechs Wochen erschreckend stabil - ohne Neustarts (abgesehen von einem oder zwei durch allgemeine Stromausfälle verursachten).
Ein paarmal habe ich die Situation erwischt, in der gerade keine Verbindung stand ("dead peer" usw.), konnte aber nicht wirklich aus den Logs herauslesen, warum bzw. von welcher Seite das ausging - es schien aber eher die deutsche als die spanische gewesen zu sein. Die Boxen haben sich nach einer Weile aber immer wieder brav und unaufgefordert verbunden.
Grüße
Martin

babylon05 · 9 Okt 2015

Hallo hätte auch eine Frage dazu für das Deutsche LTE Netz.

Habe eine 7490 VDSL50 als IP Anschluss und dazu eine 7490 mit einem USB Stick von Huawei E3372 als Karte ist dort drin Combicard Data Comfort L Eco (Mobilfunk, von meinem Handyvertrag.

Über das Tool von AVM habe ich nun cfg's erstellt für die 2 Fritzboxen um untereinander einen VPN aufbauen zu können.
Die Verbindung wird aufgebaut, sehe ich in allen beiden Routern, da unter VPN Einstellung dort der Punkt grün ist bei beiden.
Von dem Netzwerk des Router der den LTE Stick hat, komme ich auch in den Netzwerkbereich des Routers der über VDSL angebunden ist.

Umgekehrt komme ich nicht in das Netzwerk des LTE Routers. In den Verbindungen beim LTE Router zeigt er mir eine IPv4 Adresse mit 10.xx.xx.xx an. Gehe ich z.B. auf www.wieistmeineipadresse.de kommt eine andere IP zum Beispiel 86.xx.xx.xx. Bei noip wird mir die gleiche IP wie im LTE Router angezeigt. Bei den Verbindungen im Router der über VDSL angebunden ist, sehe ich dort als Adresse der öffentlichen IP LTE Router auch diese 86.xx.xx.xx.

An was liegt das, dass ich zum LTE Router keinen VPN oder anfragen hin machen kann?

Habe dies auch mit der Technikabteilung Telekom besprochen, die wissen nicht so was ich von denen wollte. Die meinten ich sollte bei der Telekom Hotline für DSL anrufen statt bei denen für Mobilfunk....

Micha0815 · 9 Okt 2015

babylon05 schrieb:
Hallo hätte auch eine Frage dazu für das Deutsche LTE Netz.

...
An was liegt das, dass ich zum LTE Router keinen VPN oder anfragen hin machen kann?

...

Weil die LTE-Box via Dyndns von Aussen nicht erreichbar ist. Sie hat eine private IP hinter einer öffentlichen.

In der VDSL-Box sollte die LTE-Box mit interner IP erkennbar und ansprechbar sein, wenn Deine vpn-cfg`s korrekt angepasst.

Möchtest Du von ausserhalb via Deiner VDSL-Box auf die LTE-Box zugreifen, musst Du noch einen VPN-User in der VDSL-Box anlegen.

Sonst poste mal die 4 Configs mit gexxten Keys und Dyndns-Daten, dann erkennt man schneller das Problem.

Ein Hinweis, welche FW auf den 7490 wäre auch ganz hilfreich, mangels Signatur dazu.
LG

Docmarten · 6 Dez 2015

Guten Morgen,

PeterPawn schrieb:
...

Ich habe jetzt (notgedrungen, weil Windows 10) den Fritz Fernzugang in den Ruhestand geschickt. Beim Aufsetzen mit dem Shrewsoft Client (Free) hatte ich dieselben Probleme, die viele andere in diversen Foren schildern: VPN-Tunnel wurde korrekt aufgebaut (auf beiden Seiten als aktiv gekennzeichnet), aber kein Zugriff auf IPs des Fritz-Netzes. Bis ich dann zufällig bemerkt habe, dass dieser Zugriff nur dann funktioniert, wenn ich die Box-zu-Box-Verbindung zur spanischen Box deaktiviere. Mache ich da etwas falsch oder muss ich dafür evtl. die Professional-Version des Shrewsoft-Clients nutzen?
Viele Grüße
Martin

PeterPawn · 6 Dez 2015

Ich denke mal, das ist eher ein Routing-Problem ... wie sehen denn die verwendeten IP-Konfigurationen und die jeweiligen "accesslist"-Einträge in den ganzen VPN-Konfigurationen aus?

Wenn das Deaktivieren des LAN2LAN-VPN zwischen der Box in D und der in ES zu einem funktionierenden VPN-Zugriff mit dem ShrewSoft-Client auf die Box in D führt (das habe ich doch richtig verstanden?), dann ist ja die Schlußfolgerung, daß die Daten bei aktiviertem Tunnel fälschlicherweise in diesem Tunnel landen, naheliegend.

Die in #66 zitierte "accesslist" galt für eine Verwendung auf dem PC mit dem Programm FRITZ!Fernzugang. Beim ShrewSoft-Client werden die Regeln für die zu tunnelnden Daten anders konfiguriert (nennt sich nach meiner Erinnerung "Policy"). Auf keinen Fall braucht es eine Änderung an einer der VPN-Konfigurationen in der FRITZ!Box, nur weil sich der Client ändert, mit dem man auf eine dieser Boxen zugreift.

Bei ShrewSoft-Client kann man entweder alle Daten (außer dem Tunnel selbst logischerweise) über den Tunnel abwickeln oder nur gezielt einzelne Zieladressen. Die zweite Variante (die würde ich verwenden, wenn nicht wichtige Gründe für die erste sprechen) braucht dann (wenn ich die Adressen aus der accesslist in #66 zugrunde lege) eben die Einträge für die beiden Netze 192.168.0.0/24 und 192.168.50.0/24.

Ansonsten gilt - wie bei allen anderen VPN-Fragen auch - immer wieder die goldene Regel: Konfigrationsdateien und Protokolle werden gebraucht. Epische Breite bei Antworten ist (zumindest auch!) das Ergebnis eines unklaren Fehlerbildes anhand einer unvollständigen Beschreibung. Auch kann es nach so langer Zeit keineswegs schaden, wenn man die aktuelle Konfiguration einfach noch einmal zusammenfaßt. Erstens schließt das Probleme aus zwischenzeitlichen Änderungen, die man selbst für unwichtig hält, aus und zweitens muß sich dann jemand, der Dir helfen will, nicht durch 65 alte Beiträge kämpfen. Zwar hatte man sicherlich als Leser dieses Threads vor 4 Monaten die Konfiguration einigermaßen sicher vor Augen, aber seitdem sind hier viele weitere Threads mit ähnlichen Themen durchgerauscht und da verblassen solche Erinnerungen - die jetzt durch das Lesen von >60 alten Beiträgen auffrischen zu müssen, um eine aktuelle Frage zu beantworten, ist verschwendete Zeit (für den Antwort-/Hilfewilligen).

Docmarten · 7 Dez 2015

PeterPawn schrieb:
Ansonsten gilt - wie bei allen anderen VPN-Fragen auch - immer wieder die goldene Regel: Konfigrationsdateien und Protokolle werden gebraucht. Epische Breite bei Antworten ist (zumindest auch!) das Ergebnis eines unklaren Fehlerbildes anhand einer unvollständigen Beschreibung.

Prinzipiell völlig richtig, sorry. Ich dachte nur, der Fall sei vielleicht angesichts der grassierenden W10-Updates so evident, dass quasi alle die Lösung kennen - außer mir.

wie sehen denn die verwendeten IP-Konfigurationen und die jeweiligen "accesslist"-Einträge in den ganzen VPN-Konfigurationen aus?

ES-Box IP-Bereich: 192.168.0.0
ES-Box VPN-Config:

Code:

connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "dyndns.DE-Box";
                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 = 0.0.0.0;
                remotehostname = "dyndns.DE-Box";
                keepalive_ip = 192.168.50.237;
				localid {
                        fqdn = "dyndns.ES-Box";
                }
                remoteid {
                        fqdn = "dyndns.DE-Box";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "key";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.0.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.50.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.50.0 255.255.255.0";
        }

DE-Box IP-Bereich: 192.168.50.0
DE-Box VPN-Config:

Code:

connections 
		{
                enabled = yes;
                conn_type = conntype_lan;
                name = "dyndns-ES-Box";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
 				localid {
                        fqdn = "dyndns.DE-Box";
                }
                remoteid {
                        fqdn = "dyndns.ES-Box";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "key";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.50.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.0.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.0.0 255.255.255.0",
							 "permit ip any 192.168.50.0 255.255.255.0";
				 
        }

Shrew VPN Client Config:

Code:

n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:1
n:network-notify-enable:1
n:client-dns-used:0
n:client-dns-auto:1
n:client-dns-suffix-auto:1
n:client-splitdns-used:1
n:client-splitdns-auto:1
n:client-wins-used:0
n:client-wins-auto:1
n:phase1-dhgroup:2
n:phase1-life-secs:3600
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
n:phase1-keylen:256
n:phase2-keylen:256
s:network-host:dyndns.DE-Box
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:auth-method:mutual-psk
s:ident-client-type:ufqdn
s:ident-server-type:address
s:ident-client-data:[email protected]
b:auth-mutual-psk:key2
s:phase1-exchange:aggressive
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:deflate
n:phase2-pfsgroup:2
s:policy-level:auto
s:policy-list-include:192.168.50.0 / 255.255.255.0

Wenn das Deaktivieren des LAN2LAN-VPN zwischen der Box in D und der in ES zu einem funktionierenden VPN-Zugriff mit dem ShrewSoft-Client auf die Box in D führt (das habe ich doch richtig verstanden?), dann ist ja die Schlußfolgerung, daß die Daten bei aktiviertem Tunnel fälschlicherweise in diesem Tunnel landen, naheliegend.

Will ich nicht ausschließen. Ein Zugriff auf IPs des ES-Netzes ist allerdings ebenfalls nicht möglich.

Bei ShrewSoft-Client kann man entweder alle Daten (außer dem Tunnel selbst logischerweise) über den Tunnel abwickeln oder nur gezielt einzelne Zieladressen. Die zweite Variante (die würde ich verwenden, wenn nicht wichtige Gründe für die erste sprechen) braucht dann (wenn ich die Adressen aus der accesslist in #66 zugrunde lege) eben die Einträge für die beiden Netze 192.168.0.0/24 und 192.168.50.0/24.

Hier war mir nicht klar, ob ich die beiden Netze bei den Policies eintragen muss oder an anderer Stelle. Bei den Policies kann man sie ja nur in der Form 192.168.50.0 und 192.168.0.0 eintragen. Ich habe versuchsweise auch beide eingetragen, mit demselben Ergebnis: Tunnel wird aufgebaut, aber kein Zugriff auf die Netze.

ipconfig ergibt (sitze im ICE und bin mit dem Telekom-Hotspot verbunden):

Code:

Drahtlos-LAN-Adapter WiFi:

   Verbindungsspezifisches DNS-Suffix: railnet.train
   Verbindungslokale IPv6-Adresse  . : fe80::505a:d561:f74b:7112%13
   IPv4-Adresse  . . . . . . . . . . : 10.56.58.48
   Subnetzmaske  . . . . . . . . . . : 255.255.255.128
   Standardgateway . . . . . . . . . : 10.56.58.1

Ethernet-Adapter LAN-Verbindung* 12:

   Verbindungsspezifisches DNS-Suffix:
   Verbindungslokale IPv6-Adresse  . : fe80::718c:a2c9:6035:d9ff%15
   IPv4-Adresse  . . . . . . . . . . : 192.168.50.203
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . :

Mir fällt auf, dass bei der Verbindung zur DE-Box kein Standardgateway erscheint - relevant?
Grüße
Martin

PeterPawn · 7 Dez 2015

Netz in ESP: 192.168.0.0/24
Netz in D: 192.168.50.0/24

Der ShrewSoft-Client soll vermutlich die Verbindung zur Box in D herstellen?

Die "accesslist" in D verstehe ich nicht:

Code:

accesslist = "permit ip any 192.168.0.0 255.255.255.0",
                   "[COLOR="#FF0000"]permit ip any 192.168.50.0 255.255.255.0[/COLOR]";

Damit würde der Netzwerkverkehr an Adressen im eigenen LAN über den VPN-Tunnel nach ESP getunnelt. Daß Du bei dieser Konfiguration im LAN überhaupt noch kommunizieren kannst, ist reines Glück, weil die LAN-Kommunikation normalerweise nicht über "dev dsl" und die FRITZ!Box geht (da greift das VPN erst). Jedenfalls beißt sich dieser Eintrag u.U. mit dem Eintrag für einen Benutzer, der in etwa auch so aussehen sollte wie der rot markierte, nur daß dort anstelle eines Netzes ein gezielter Host adressiert wird (vermutlich 192.168.50.201, wenn es der erste und einzige VPN-Benutzer ist).

Dieser Eintrag hat m.E. in der VPN-Konfiguration der Box in D nichts zu suchen (ich verstehe seinen Sinn eben ohnehin nicht) und der ShrewSoft-Client braucht in der Konfiguration für ein einzelnes gezieltes Netz (wenn also nicht aller Traffic über die FRITZ!Box gehen soll) noch zusätzliche die Policy für das Netz 192.168.0.0/24, damit Traffic für ESP auch erst einmal in den Tunnel zur FRITZ!Box in D geht und von dort dann weitergeleitet werden kann. Solange der ShrewSoft-Client eine Adresse aus dem Segment 192.168.50.0/24 hat, braucht es in ESP keine weiteren "accesslist"-Einträge, da paßt dann die derzeit vorhandene Konfiguration.

Docmarten · 8 Dez 2015

PeterPawn schrieb:
Netz in ESP: 192.168.0.0/24
Der ShrewSoft-Client soll vermutlich die Verbindung zur Box in D herstellen?

Ja. Und über die DE-Box sollte dann (wie zuvor) die Verbindung zu den IPs des ES-Netzes klappen.

Code:
Die "accesslist" in D verstehe ich nicht:

Code:

accesslist = "permit ip any 192.168.0.0 255.255.255.0", "[COLOR="#FF0000"]permit ip any 192.168.50.0 255.255.255.0[/COLOR]";

Damit würde der Netzwerkverkehr an Adressen im eigenen LAN über den VPN-Tunnel nach ESP getunnelt. Daß Du bei dieser Konfiguration im LAN überhaupt noch kommunizieren kannst, ist reines Glück, weil die LAN-Kommunikation normalerweise nicht über "dev dsl" und die FRITZ!Box geht (da greift das VPN erst). Jedenfalls beißt sich dieser Eintrag u.U. mit dem Eintrag für einen Benutzer, der in etwa auch so aussehen sollte wie der rot markierte, nur daß dort anstelle eines Netzes ein gezielter Host adressiert wird (vermutlich 192.168.50.201, wenn es der erste und einzige VPN-Benutzer ist).

Dieser Eintrag hat m.E. in der VPN-Konfiguration der Box in D nichts zu suchen (ich verstehe seinen Sinn eben ohnehin nicht)

Da hatte ich glaube ich "meine Anweisungen", siehe #27 und #34:

PeterPawn schrieb:
@docmarten:
DE-DSL

Code:

accesslist = "permit ip 192.168.50.0 255.255.255.0 192.168.50.202 255.255.255.255", "permit ip 192.168.0.0 255.255.255.0 192.168.50.202 255.255.255.255";

könnte schon helfen, wenn ich die Adressen richtig verstehe. Im Moment erreichen die Daten aus ES (Absender 192.168.0.0/24) Dein iOS-Gerät (192.168.50.202/32) vermutlich einfach nicht, weil sie im LAN versanden bzw. per Route auf "dev dsl" geleitet, dort aber nicht in IPSec verpackt werden.

Möglicherweise hatte ich Dich da seinerzeit falsch verstanden - aber funktioniert hat es jedenfalls in der Prä-Shrewsoft-Ära.

der ShrewSoft-Client braucht in der Konfiguration für ein einzelnes gezieltes Netz (wenn also nicht aller Traffic über die FRITZ!Box gehen soll) noch zusätzliche die Policy für das Netz 192.168.0.0/24, damit Traffic für ESP auch erst einmal in den Tunnel zur FRITZ!Box in D geht und von dort dann weitergeleitet werden kann. Solange der ShrewSoft-Client eine Adresse aus dem Segment 192.168.50.0/24 hat, braucht es in ESP keine weiteren "accesslist"-Einträge, da paßt dann die derzeit vorhandene Konfiguration.

Die 192.168.0.0 hatte ich wie geschrieben ja probeweise hinzugefügt, ohne "/24", aber ohne Erfolg.
Grüße
Martin

PeterPawn · 8 Dez 2015

Docmarten schrieb:
Möglicherweise hatte ich Dich da seinerzeit falsch verstanden - aber funktioniert hat es jedenfalls in der Prä-Shrewsoft-Ära.

Ja, vollkommen falsch verstanden und pures Glück, daß es funktionierte.

Der Vorschlag in #34 drehte sich um die Konfiguration für das Programm "FRITZ!Fernzugang" und im Prinzip ist dort die zu sehende "accesslist" dasselbe wie zwei Policy-Einträge für die beiden Netzwerk-Segmente (x.50.x und x.0.x) im ShrewSoft-Client.

In #27 geht es um die "accesslist" für den Benutzer-Eintrag in der vpn.cfg der FRITZ!Box, also für das Konto/die Verbindung, die Dein iOS-Client und auch FRITZ!Fernzugang am Ende nutzt (oder auch jeder andere Client, wobei dann immer nur eine Verbindung möglich ist, weil es ja nur eine Adresse für diese ganzen Clients gibt).

In der Box in D hat jedenfalls eine Anweisung, den Verkehr für das .50-Netz durch den Tunnel nach ESP zu schicken, nichts zu suchen (im Eintrag für die L2L-Verbindung nach ESP) ... jedenfalls dann nicht, wenn die Beschreibung vollständig ist.

Docmarten · 9 Dez 2015

Danke PeterPawn. Ich habe die betreffende Zeile ("permit ip any 192.168.50.0 255.255.255.0") jetzt herausgenommen, und nun klappt der Zugriff aus einem Drittnetz auf die DE-Box auch dann, wenn sie L2L mit der ES-Box verbunden ist.
Was nach wie vor nicht mehr klappt ist der Shrew-Zugriff aus einem Drittnetz heraus über das DE-Netz (x.50.x) auf Adressen des ES-Netzes (x.0.x).
Da es mit iOS aus demselben Drittnetz heraus funktioniert, habe ich versucht, die Shrew-Konfig an die iOS-Konfiguration anzupassen, ohne Erfolg.
Der erwähnte iOS-Zugriff auf ES funktioniert nur dann, wenn die accesslist so aussieht:

Code:

accesslist = 
                         "permit ip 192.168.50.0 255.255.255.0 192.168.50.202 255.255.255.255",
			 "permit ip 192.168.0.0 255.255.255.0 192.168.50.202 255.255.255.255";

Die komplette cfg der DE-Box sieht nun so aus:

Code:

vpncfg {
        connections 
		{
                enabled = yes;
                conn_type = conntype_lan;
                name = "ES-Box";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
 				localid {
                        fqdn = "DE-Box";
                }
                remoteid {
                        fqdn = "ES-Box";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "key1";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.50.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.0.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.0.0 255.255.255.0";
							 
				 
        } {
                enabled = yes;
                conn_type = conntype_user;
                name = "[email protected]";
                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 = 192.168.50.203;
                remoteid {
                        user_fqdn = "[email protected]";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "key2";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.50.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.50.203;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = 
                             "permit ip 192.168.50.0 255.255.255.0 192.168.50.203 255.255.255.255";
        } {
                enabled = yes;
                conn_type = conntype_user;
                name = "IOS";
                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 = 192.168.50.202;
                remoteid {
                        key_id = "IOS";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "key3";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "IOS";
                        passwd = "pass";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.50.202;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = 
                             "permit ip 192.168.50.0 255.255.255.0 192.168.50.202 255.255.255.255",
							 "permit ip 192.168.0.0 255.255.255.0 192.168.50.202 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";
}


// EOF

Die Shrew Config mit beiden Policies:

Code:

n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:1
n:network-notify-enable:1
n:client-dns-used:0
n:client-dns-auto:1
n:client-dns-suffix-auto:1
n:client-splitdns-used:1
n:client-splitdns-auto:1
n:client-wins-used:0
n:client-wins-auto:1
n:phase1-dhgroup:2
n:phase1-life-secs:3600
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
n:phase1-keylen:256
n:phase2-keylen:256
s:network-host:DE-Box
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:auth-method:mutual-psk
s:ident-client-type:ufqdn
s:ident-server-type:address
s:ident-client-data:[email protected]
b:auth-mutual-psk:key2
s:phase1-exchange:aggressive
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:deflate
n:phase2-pfsgroup:2
s:policy-level:auto
s:policy-list-include:192.168.50.0 / 255.255.255.0,192.168.0.0 / 255.255.255.0

Woran kann es denn liegen, dass es mit den iOS Geräten geht, aber mit der Shrew-Verbingung nicht?

PeterPawn · 9 Dez 2015

Da ja mit dem ShrewSoft-Client wohl die Verbindung mit der Mail-Adresse im Namen verwendet wird (also die mittlere in der vpn.cfg), muß da natürlich für den Zugriff auf ESP auch noch der passende "accesslist"-Eintrag für die korrekte Adresse (das ist bei diesem Eintrag ja die 203 anstelle der 202) und den Datenverkehr aus ESP (also von einer Adresse 192.168.0.0/24) vorhanden sein. Die zweite Regel aus dem iOS-Eintrag also - an die andere Adresse des Clients angepaßt - in den Client-Eintrag für den ShrewSoft-Zugriff übernehmen.

PS: Ist das mit "no-pfs" beim iOS-Eintrag Absicht oder Notwendigkeit? Warum soll da kein PFS verwendet werden? Das macht so eine VPN-Verbindung unsicherer, weil ein zusätzlicher Schritt im Schlüsselaustausch wegfällt, mit dem auch eine nachträgliche Analyse von Cipher-Text scheitert, wenn man auf irgendwelchen Wegen doch an den Schlüssel kommen sollte (was bei einem PSK nun nicht so schwer ist, bei einem Zertifikat aber auch nicht).

Wenn eine Verbindung auch dann klappt, wenn da "pfs" anstelle von "no-pfs" steht, würde ich diese Einstellung verwenden.

Docmarten · 11 Dez 2015

PeterPawn schrieb:
Die zweite Regel aus dem iOS-Eintrag also - an die andere Adresse des Clients angepaßt - in den Client-Eintrag für den ShrewSoft-Zugriff übernehmen.

Das hatte ich schon einmal probiert - und eben, endlich wieder dem Heimnetz entronnen - noch einmal, also konkret:

Code:

name = "[email protected]";
[...]
accesslist = 
                         "permit ip 192.168.50.0 255.255.255.0 192.168.50.203 255.255.255.255",
			 "permit ip 192.168.0.0 255.255.255.0 192.168.50.203 255.255.255.255";

[edit]Aber nach wie vor kein Zugriff auf ES.

PS: Ist das mit "no-pfs" beim iOS-Eintrag Absicht oder Notwendigkeit?

Keine Absicht, hat wohl seinerzeit "Fritz Fernzugang einrichten" so entschieden. Habe gerade kein iOS Gerät zur Hand, aber werde das später ausprobieren.

PeterPawn · 11 Dez 2015

Zumindest wäre damit die Client-Konfiguration in der Box in D korrekt. Da die 192.168.50.203 unter die 192.168.50.0/24 in der Box in ESP fällt und damit Verkehr dafür automatisch nach D gelangt, ist die FRITZ!Box-Konfiguration damit erledigt.

Eigentlich kann es nur noch am ShrewSoft-Client liegen, hast Du "manuell" eingestellt und beide Netze per "Include" hinzugefügt (letztere sind ja eigentlich in der Konfigurationsdatei zu sehen, also ist das wohl geschehen)? Die Einstellung "Obtain Topology automatically or Tunnel All" müßte nach meinem Verständnis aus sein, die FRITZ!Box übermittelt ja keine Informationen über das zweite Netz. Wenn Du das schon deaktiviert hast, muß man mal mit den zusätzlichen Protokoll-Informationen des ShrewSoft-Clients nachsehen, wo es klemmt.

Am einfachsten wäre es erst einmal, wenn Du irgendwie feststellen könntest, ob ein "echo request"-Paket an die Box in ESP geht, wenn Du bei aktivierter Client-Verbindung zur Box in D ein "ping" ausführst und dort auch ankommt. Dann würde es nur am "Rückweg" liegen, ich bin mir aber eben im Moment nicht sicher, daß da überhaupt die Pakete für die Adressen in 192.168.0.0/24 per IPSec an die Box in D gehen und nicht direkt an den (W)LAN-Adapter des benutzten Gerätes.

Docmarten · 11 Dez 2015

Durch stumpfes Ausprobieren klappt es nun: Bei den Shrew-Policies (policy-level) muss anscheinend "require" ausgewählt - zuvor hatte ich es gemäß den diversen Anleitungen nur mit "auto" und mit "shared" versucht - meintest Du das mit "manuell"?

PeterPawn schrieb:
Die Einstellung "Obtain Topology automatically or Tunnel All" müßte nach meinem Verständnis aus sein, die FRITZ!Box übermittelt ja keine Informationen über das zweite Netz.

Ja, die muss wohl aus sein, sonst gibt es bei mir überhaupt keine VPN-Verbindung.
Nochmals vielen Dank - ich hoffe, das bleibt jetzt stabil.

voipspain · 1 Mai 2016

Ich habe ebenfalls derzeitig an einem Anschluß nur Internet über Yoigo UMTS Mobilfunk-Stick Huawei E3131 Hi-Link per USB-Tethering an FRITZ!Box 7490.
Voip funktioniert und ich kann mich auch über Fritz Fernzugang mit der entfernten FRITZ!Box 7390 (FTTH Internet) verbinden.
Natürlich komme ich jetzt nicht mehr mit Fritz Fernzuggang von aussen auf meine 7490.

Hab ich Euch jetzt richtig verstanden, daß ich dafür eine Lan-Lan Verbindung zwischen den 7490 (umts) und 7390 (FTTH) aufbauen muss und daß der Aufbau über die 7490 (umts)?

Ich habe auch noch bei meiner Suche eine evtl. Alternative gefunden. Man kann wohl den Huawei E3372 UMTS Stick auf Non Hi Link flashen. Link
Dann würde die Fritz!Box wieder die Verbindung zum Internet herstellen, hätte somit wieder eine öffentliche IP Adresse und wäre somit wieder über Dynamic DNS erreichbar.
Also im Ergebnis wie bei einem Festnetzanschluß und man kann sich mit Fritz Fernzugang wieder normal einwählen.

Hat das mal jemand versucht?

Ich sehe glaube ich den Wald vor lauter Bäumen nicht

thtomate12 · 1 Mai 2016

Dem Stick durch Flashen die NAT abzugewöhnen kann eine Lösung sein, muss aber nicht, da wir nicht wissen, ob dein Mobilfunkprovider dir überhaupt eine öffentlich erreichbare IP-Adresse zuteilt.

voipspain · 1 Mai 2016

Dank für den Hinweis. Anscheinend hat Yoigo nur eine private IP. Dann kann ich mir das flashen sparen und mir bleibt die Lan-Lan Verbindung.
Kann man die so einstellen, daß nicht der gesamte traffic über VPN läuft? Wäre ja fatal bei Volumenbegrenzung UMTS Internet.

Micha0815 · 1 Mai 2016

voipspain schrieb:
...
Hab ich Euch jetzt richtig verstanden, daß ich dafür eine Lan-Lan Verbindung zwischen den 7490 (umts) und 7390 (FTTH) aufbauen muss und daß der Aufbau über die 7490 (umts)?

Das hast Du richtig verstanden. Z.Zt. nutzt Du hinter der Yoigo-7490 (keine öffentliche IP) einen VPN-Client zu der 7390 FTTH (öffentliche IP).
Du musst nur Dir die entsprechenden configs erstellen und jeweils in die FBs einspielen. Dann kommst Du auf beide Boxen als jeweiliger Client dahinter. Wichtig ist zu verstehen, das der Tunnel stets von der Yoigo-Box (generell von derjenigen, die keine öffentliche IP hat) aufgebaut werden muss. Ein Dyndns-Eintrag auf der Yoigo-Box bringt garnichts. Lässt Du Dir eine Push-Mail zusenden, erkennst Du, dass da eine private IP zugewiesen ist. z.B. 10.x.x.x oder 100.x.x.x die von Aussen nicht erreichbar sind.

...Ich habe auch noch bei meiner Suche eine evtl. Alternative gefunden. Man kann wohl den Huawei E3372 UMTS Stick auf Non Hi Link flashen. Link
Dann würde die Fritz!Box wieder die Verbindung zum Internet herstellen, hätte somit wieder eine öffentliche IP Adresse und wäre somit wieder über Dynamic DNS erreichbar...

Das Umflashen des E3131 auf eine NonHilink-FW bringt Dir nur den Vorteil, die Yoigo-Rufnummer als GSM-Gateway nutzen zu können. Dadurch bekommst auch keine öffentliche IP bei Yoigo.

Bedenke, dass eine permanente LAN2LAN-VPN-Verbindung bei Yoigo -im Leerlauf ohne grössere Zugriffe mit einer registrierten VOIP-Nr.- ~200-300 MB Traffic/Monat verursacht. Zudem empfehle ich aus persönlicher Erfahrung, falls nicht ständig jmd. physischen Zugriff auf eine UMTS-FB hat, diese über eine Zeitschaltuhr o.ä. (ich nutze einen DECT200 der jede Nacht 3:00Uhr nach Versand einer Pushmail für 1 Minute die FB neu startet) regelmässig neu zu starten. Es kommt immerwieder mal vor, dass u.U. das Mobilfunknetz mal ausfällt/schwächelt oder andere internen Dinge die UMTS-FB aus dem Tritt bringt bishin zum "sich Aufhängen". Dann vergisst sie einfach als VPN-Initiator ggfs. sich neu zu Verbinden. Selbst das hilft nicht immer. An manchen Tagen will meine FB auf den Kanaren keine VPN-Verbindung zur heimischen FB aufbauen.

Als Vorlage die Du bzgl. Keys fqdn-Name und IP-Bereiche Deiner beiden Boxen anpassen musst (ohne Gewähr)

Als import in die DE-FTTH

Code:

vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "Yoigo z.B."
                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 = "";
                keepalive_ip = 0.0.0.0;
                localid {
                        fqdn = "de.vpncfg";
                }
                remoteid {
                        fqdn = "es.vpncfg";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "Denke Dir einen langen aus, muss in beiden cfgs. identisch sein ";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = IP-der FTTH[COLOR=#ff0000].0[/COLOR];
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = IP-der Yoigi[COLOR=#ff0000].0[/COLOR];
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any IP-der Yoigo[COLOR=#ff0000].0[/COLOR] 255.255.255.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";
}

Und für Deine Yoigo-ES

Code:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "FTTH";
                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 = 0.0.0.0;
                remotehostname = "dyndns der FTTH-Box";       (ohne https://.....)
                keepalive_ip = der FTTH-Box;
                localid {
                        fqdn = "es.vpncfg";
                }
                remoteid {
                        fqdn = "de.vpncfg";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "Derselbe lange key wie oben";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = IP-Yoigo-Box[COLOR=#ff0000].0[/COLOR];
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = IP-FTTH-Box[COLOR=#ff0000].0[/COLOR];
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any IP-FTTH-Box[COLOR=#ff0000].0[/COLOR] 255.255.255.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";
}

Bei den Platzhaltern Name-IP bitte die 0 am Ende beachten. IP-FTTH.0 wäre z.B. 192.168.178.0
Zum Anpassen bitte einen linuxkompatiblen Editor z.b. Notepad++ verwenden. Für den import ist die Extension wurst. Kann auch .txt statt .cfg sein.

Good Luck.

Nachtrag: Steht die VPN LAN2LAN-Verbindung, kannst Du als VPN-Client (Fritz!Fernzugang) hinter einer der beiden FBs diesen nicht nutzen.

[Gelöst] VPN zw. DSL-Box in D und UMTS-Box in ES - ES-Verbindung hat 2 IPs (1 priv 1 öffentl)?

IPPF-Promi

Mitglied

Mitglied

Mitglied

IPPF-Promi

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Statistik des Forums