Mini-Howto: Kompletten Internetverkehr über AVM VPN routen

Ich glaube ich habe jetzt mehr oder weniger die accesslist verstanden.

Um den DNS der Fritz Box weiterhin zu nutzen, aber den gesamten Traffic durch den VPN zu schicken geht folgendes.

Code:
                accesslist = "reject udp any any eq 53",
                             "reject udp any any eq 500",
                             "reject udp any any eq 4500",
                             "permit ip any any";

Wenn man nur accesslist = "permit ip any any"; definiert, wird alles, auch die DNS Anfragen, durch den VPN geschickt. Die Daten kommen in beiden Fällen an der pfsense an.

Und damit die VOIP Rufnummern z.B. für Telekom DSL weiterhin funktionieren, müssen die entspr. Ports noch definiert werden. Das sieht dann so aus.

Code:
                accesslist = "reject udp any any eq 53",
                             "reject udp any any eq 500",
                             "reject udp any any eq 4500",
                             "reject udp any any eq 5060",
                             "reject udp any any eq 3478",
                             "reject udp any any eq 3479",
                             "reject udp any any range 30000 31000",
                             "reject udp any any range 40000 41000",
                             "permit ip any any";
 
Zuletzt bearbeitet:
@spätere Leser:
Das ist hier aber ein Sonderfall, daß der Port 53 (also DNS-Abfragen) auch über die VPN-Verbindung gehen könnte ... denn hier hat der Peer eine statische IPv4-Adresse (zumindest sieht die FRITZ!Box-Konfiguration auf der vorherigen Seite so aus).

Wenn der Peer auch erst noch über DNS aufgelöst werden muß, braucht man schon für den Aufbau des Tunnels noch die DNS-Abfrage und darf den DNS-Traffic nicht über den Tunnel senden ... das FRITZ!OS leitet den nicht etwa unverschlüsselt weiter, nur weil der Tunnel noch nicht steht.

Für eine Konstellation, wo die DNS-Abfragen auch durch eine VPN-Verbindung gehen und der Peer trotzdem eine dynamische Adresse mit entsprechendem dynamischen DNS-Namen hat, ist die FRITZ!Box ab Werk nicht geeignet ... so etwas wie die spätere Modifikation der Filter aus der "accesslist" kennt das FRITZ!OS nicht und es sind immer die Filter aus allen aktivierten Verbindungen aktiv (nicht mit "aktiven Verbindungen" zu verwechseln, die dann tatsächlich aufgebaut sind).

Eine Konfiguration ohne die "Sperren" für die IPSec-Ports (500 und 4500) habe ich noch nie probiert (zumindest keine, wo dann ein "permit ip any any" die Liste beschließt) ... Auslöser ist sicherlich auch die Feststellung, daß AVM bei der Verwendung des Windows-Programms für die Konfiguration einer VPN-Verbindung diese beiden Regeln auch setzt, wenn man "alles über die VPN-Verbindung" auswählt (zumindest war das mal so).

Es mag unterschiedliche Implementierungen des WAN-Stacks bei AVM geben und damit auch unterschiedliche Stellen, wo der verschlüsselte Traffic dann wieder "eingeleitet" wird in das normale Routing ... aber es gibt eben auch unterschiedliche Szenarien, bei denen unterschiedliche Protokolle verwendet werden. Es mag ohne die Filter für UDP 500 und 4500 manchmal gut gehen (so wie es sich in #481 ja anhört in dem Satz:

Wenn man nur accesslist = "permit ip any any"; definiert, wird alles, auch die DNS Anfragen, durch den VPN geschickt. Die Daten kommen in beiden Fällen an der pfsense an.

), aber darauf würde ich mich nicht blind verlassen.

Es kann schon ein entscheidender Unterschied sein, ob IKE über UDP 500 und der Rest über ESP (das ist ein Protokoll auf derselben Ebene wie TCP und UDP - es verwendet die IP-Protokollnummer 50) abgewickelt wird oder ob alles - bei Erkennung eines NAT-Devices im Verbindungsweg - über NAT-Traversal (da kommt dann nur noch UDP 4500 zum Einsatz mit einer zusätzlichen Kapselung der Pakete, an denen auch ein NAT-Router "herumspielen" darf) arbeitet.

Sollten die verschlüsselten Pakete an einer Stelle in den WAN-Stack eingespeist werden, wo sie noch einmal an dem Filter aus der "accesslist" vorbeikommen, dann sollte dieser auch dafür sorgen, daß die bereits verschlüsselten Pakete jetzt nicht erneut "selektiert" werden ... genau das machen ja die "reject"-Einträge für die Ports 500 und 4500. Kommen sie da nicht noch einmal vorbei, braucht man sicherlich diese "rejects" nicht wirklich.

Man weiß ja nicht so richtig, um welches Modell einer FRITZ!Box mit welcher FRITZ!OS-Version es sich hier handelt(e) ... es wäre aber auch tatsächlich denkbar, daß AVM die Arbeitsweise des VPN in verschiedenen Versionen unterschiedlich implementiert hat. Aber schaden können diese Regeln für Port 500 und 4500 eigentlich auch nicht (nur in extremen Situationen, wo tatsächlich noch Traffic für diese Ports durch den Tunnel gehen soll) und damit sollte man sie lieber eingetragen lassen bzw. selbst eintragen ... ebenso wie die erwähnte Port 53-Regel, wenn der Peer einen DNS-Namen hat - ansonsten wird der Tunnel niemals aufgebaut werden und im Ergebnis hat man hinter der FRITZ!Box gar kein Internet mehr, weil die Pakete von "any" für "any" einfach verworfen werden.
 
Zuletzt bearbeitet:
Und damit die VOIP Rufnummern z.B. für Telekom DSL weiterhin funktionieren, müssen die entspr. Ports noch definiert werden.
Code:
accesslist =SNIP
"reject udp any any eq 5060",
"reject udp any any eq 3478",
"reject udp any any eq 3479",
"reject udp any any range 30000 31000",
"reject udp any any range 40000 41000",
SNIP
erlaubt die Telekom keine "nomadische" Nutzung von SIP/VOIP am DSL-Anschluß ?
ist nur die eigene WAN-IP erlaubt ?
kann man das ggf im KC anpassen ?
 
Zuletzt bearbeitet:
Ich habe es nun geschafft, das das Telekom VOIP weiterhin über die Fritz Box läuft und der restliche Internet Traffic über den VPN zur pfsense. Es reicht nicht, die UDP Ports zu rejecten, man muss auch das Telekom VOIP Netz ausschließen. Hier meine komplette Fritz Box VPN Config für Copy & Paste. Nicht vergessen bei der Fritz Box einen sicheren DNS Server einzutragen wie 1.1.1.1 und 1.0.0.1.

Code:
/*
* vpn.cfg
*/
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "pfsenseall";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = [pfsense public UP];
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "DynDNS Fritz Box Domain";
                }
                remoteid {
                        ipaddr = [pfsense public UP];
                }
                mode = phase1_mode_idp;
                phase1ss = "dh14/aes/sha";
                keytype = connkeytype_pre_shared;
                key = "sehr langer Zeichensalat";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = [Fritz Box internes Netzwerk];
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = [pfsense internes Netzwerk];
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
        accesslist = "reject udp any any eq 53",
                 "reject udp any any eq 5060",
                 "reject udp any any eq 5070",
                 "reject udp any any eq 5080",
                 "reject udp any any eq 3478",
                 "reject udp any any eq 3479",
                 "reject udp any any eq 8089",
                 "reject tcp any any eq 8089",
                 "reject udp any any range 7078 7109",
                 "reject udp any any range 30000 31000",
                 "reject udp any any range 40000 41000",
                 "reject ip any 217.0.0.0 255.255.0.0",
                 "permit ip any any";
      }
        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
 
Hallo Zusammen,

Ich habe mich jetzt schon etwas in die Thematik eingelesen, einiges hinbekommen aber das fehlende Puzzleteil fehlt noch.
Vielleicht kann mir hier jemand weiterhelfen.

Kurz zur Aufgabenstellung.
Wohnort A: Fritzbox 7360 (192.168.10.1)
Wohnort B: Fritzbox 6590 Cable (192.168.178.1) + Fritzbox 7330 in zweiter Reihe (192.168.188.1)

Ich möchte die Fritzbox 7330 als VPN Gateway konfigurieren.
D.h Jedes Gerät was mit Fritzbox 7330 (in Zweiter Reihe an Wohnort B) verbunden ist soll über VPN zu FritzBox 7360 (Wohnort A) durchgeschleußt werden. (Es soll definitiv der GESAMTE Traffic getunnelt werden)

Die VPN Verbindung von Fritzbox 7330 zu Fritzbox 7360 steht bereits (Anleitung: FritzBox mit einem Firmenneztwerk verbinden).
Alle Geräte die mit der Fritzbox 7330 verbunden sind, können bereits auf sämtliche Geräte im Neztwerk von Fritzbox 7360 (Wohnort A) zugreiffen.

Grundsätzlich würde ich die Lösung von OlliBerlin (#12) bevorzugen, nur realisiert er es über die Lan-Lan Vpn Kopplung, welche bei mir nicht in Frage kommt da die FritzBox 7330 in zweiter Reihe hängt.

Wie kann ich realisieren damit der gesamte Traffic der FritzBox 7330 über den Tunnel geht?

Vielen Dank schonmal
 
Zuletzt bearbeitet:
Ohne die entsprechenden *vpn.cfg (teilanonymisiert bzgl credentials), insbesonders der accesslist der 7360 und 7330, wird Dir niemand zielführend weiterhelfen können.
LG
 
Hier die beiden .cfg Dateien.
Einmal .cfg Serverseitig 7360 und einmal die .cfg der Fritzbox7330 welche in zweiter Reihe ist.
Mit diesen Konfigs funktioniert der Aufbau des VPN's erfolgreich.

Wohnort A: Fritzbox 7360 (192.168.10.1)
Wohnort B: Fritzbox 6590 Cable (192.168.178.1) + Fritzbox 7330 in zweiter Reihe (192.168.188.1)


Code:
//vpnserver7360
vpncfg {
        vpncfg_version = 1;
        connections  {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "userxxxvpn";
                boxuser_id = 11;
                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.10.202;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        key_id = "userxxxvpn";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "LT8h/all/all/all";
                keytype = connkeytype_pre_shared;
                key = "xxxpasswordpsk";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "userxxxvpn";
                        passwd = "xxxpassword";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.10.202;
                }
                phase2ss = "LT8h/esp-all-all/ah-none/comp-all/no-pfs";
                accesslist =
                             "permit ip 0.0.0.0 0.0.0.0 192.168.10.202 255.255.255.255";
                app_id = 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

Code:
// vpnclient 7330
vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = yes;
                conn_type = conntype_out;
                name = "f7360**myfritz.net";
                boxuser_id = 0;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = no;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.10.202;
                remotehostname = "f7360**myfritz.net";
                keepalive_ip = 192.168.10.1;
                localid {
                        key_id = "userxxxvpn";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "xxxpasswordpsk";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "userxxxvpn";
                        passwd = "xxxpassword";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = "permit ip any 192.168.10.0 255.255.255.0";
                dns_domains = "";
                app_id = 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 Zahl der Benutzer, die sich hier noch an einen mehr als sieben Jahre alten Beitrag erinnern können, dürfte "überschaubar" sein ... daher verlinkt man besser auf so alte Beiträge, wenn man erwartet, daß sich heutzutage jemand dort informiert, wie diese Lösung aussah, nur weil er Dir hier helfen will. Da baust Du eine vollkommen unnütze Hürde vor den Antwortwilligen (und -fähigen) auf, welche diese erst mal zu nehmen bereit sein müssten, wenn sie Dir hier antworten wollten.

-------------------------------------------------------------------------------------------------------

Aber vielleicht solltest Du generell noch einmal "einen Schritt zurücktreten" und neu überlegen bzw. für diese Feststellung:
welche bei mir nicht in Frage kommt da die FritzBox 7330 in zweiter Reihe hängt.
eine Begründung oder zumindest eine Quelle angeben?

Vielleicht fällt Dir dann schon bei der Suche nach der Antwort darauf auf (ich weiß es zwar nicht definitiv, aber die bisher abgegebene Beschreibung enthält nicht einen einzigen Punkt, der gegen eine LAN-LAN-Kopplung sprechen würde), daß diese Prämisse eventuell doch nicht stimmt.

-------------------------------------------------------------------------------------------------------

Aber auch danach würde ich mich (bei der Umstellung auf eine LAN-LAN-Verbindung, die in diesem Falle tatsächlich auch auf beiden Seiten mit einer Textdatei zu konfigurieren wäre, weil die eine Seite nur passiver Responder sein darf (was mit dem GUI nicht geht) und die andere eine modifizierte "accesslist" (auch nicht per GUI einstellbar) benötigt) nicht auf Anleitungen und/oder Vorschläge verlassen, die dermaßen alt sind.

Mit FRITZ!OS 06.2x hat AVM mächtig geändert (u.a. kam da überhaupt erst der GUI-Editor) und auch später wurde noch an vielen Details gefeilt ... aber auch seitdem haben viele Leute erfolgreich eine solche Konfiguration umgesetzt - sie ist also definitiv auch heute noch machbar. Der kaskadierte Router ist ja auch problemlos mit einem zu vergleichen, der an einem DS-Lite-Anschluß hängt - wo dann das CGN beim Provider in der Rolle Deiner 6590 ist.

Einen plausiblen Grund, das mit einer "conntype_user"-Verbindung zu lösen, kann ich hier nicht sehen (die 7330 macht dann halt NAT über die IP-Adresse aus dem VPN) und ich würde das auch nicht so konfigurieren. Wenn es noch "besondere Umstände" gibt, die tatsächlich eine "conntype_user"-Verbindung unumgänglich machen, dann solltest Du diese noch beschreiben.

Aber selbst wenn man das mit einer solchen User-Verbindung macht (bzw. machen will), woher stammt denn dann die Feststellung, daß die Lösung auf Seite 12 (sprich: Ändern der "accesslist") hier nicht funktionieren würde? Gibt es da irgendwelche Protokolle von solchen Fehlversuchen? Auch hier kann ich (weder in der Beschreibung noch in den Dateien) einen Grund sehen, warum man die "accesslist" nicht anpassen können sollte - außer daß dieses halt über das GUI (was 2011 noch gar nicht existierte) nicht möglich ist.
 
  • Like
Reaktionen: michaelFritte
Falls die 7330 (192.168.188.0/24) nicht im restriktiven Gastnetz der 6590 hängt, könntest Du die vorgenannte LAN2LAN-Konfig im Initiator<->Responder-Modus testen.
LG
 
Anleitung: FritzBox mit einem Firmenneztwerk verbinden)
Ich möchte die Fritzbox 7330 als VPN Gateway konfigurieren.
D.h Jedes Gerät was mit Fritzbox 7330 (in Zweiter Reihe an Wohnort B) verbunden ist soll über VPN zu FritzBox 7360 (Wohnort A) durchgeschleußt werden. (Es soll definitiv der GESAMTE Traffic getunnelt werden)

Aber selbst wenn man das mit einer solchen User-Verbindung macht (bzw. machen will), woher stammt denn dann die Feststellung, daß die Lösung auf Seite 12 (sprich: Ändern der "accesslist") hier nicht funktionieren würde?

Vorschlag für Test (Catch-All VPN-Setup, except DNS Queries):
FB7360 (Dial-Out):
vpn.cfg:
conn_type = conntype_out;
OLD:
Code:
accesslist = "permit ip any 192.168.10.0 255.255.255.0";

NEW:
Code:
accesslist = "reject udp any any eq 53",
             "reject udp any any eq 500",
             "reject udp any any eq 4500",
             "permit ip any any";
@michaelFritte: Bitte testen und um Rückinfo.

Ansonsten empfehle ich den von PeterPawn vorgeschlagene LAN2LAN-VPN-Tunnel (Conntype_lan) mit FB7360 als VPN-Responder und FB7330 als VPN-Initiator.


Falls die 7330 (192.168.188.0/24) nicht im restriktiven Gastnetz der 6590 hängt

@Micha0815:
wenn aktuell VPN im conntype_out Modus funktioniert, dann wird auch LAN2LAN-VPN-Tunnel (conntype_lan) mit FB7360 als VPN-Responder und FB7330 als VPN-Initiator funktionieren; die FB6590 kennt das LAN der FB7330 nicht.
 
Zuletzt bearbeitet:
Die Zahl der Benutzer, die sich hier noch an einen mehr als sieben Jahre alten Beitrag erinnern können, dürfte "überschaubar" sein ... daher verlinkt man besser auf so alte Beiträge, wenn man erwartet, daß sich heutzutage jemand dort informiert, wie diese Lösung aussah, nur weil er Dir hier helfen will. Da baust Du eine vollkommen unnütze Hürde vor den Antwortwilligen (und -fähigen) auf, welche diese erst mal zu nehmen bereit sein müssten, wenn sie Dir hier antworten wollten.

Sorry, Ich habe den Link nun nachträglich eingefügt

Aber vielleicht solltest Du generell noch einmal "einen Schritt zurücktreten" und neu überlegen bzw. für diese Feststellung:
eine Begründung oder zumindest eine Quelle angeben?

Vielleicht fällt Dir dann schon bei der Suche nach der Antwort darauf auf (ich weiß es zwar nicht definitiv, aber die bisher abgegebene Beschreibung enthält nicht einen einzigen Punkt, der gegen eine LAN-LAN-Kopplung sprechen würde), daß diese Prämisse eventuell doch nicht stimmt.

Ich habe es mit einer LAN-LAN-Kopplung probiert und ICH bin daran gescheitert. Eine Quelle kann ich nicht angeben, da es keine gibt. Du hast ja recht..
Mein Vorgehen war folgendermaßen:
HTTPS-Port(Fritzbox 7330)-Freigabe am 6590 eingerichtet.
Ergebnis: myfritzadresse der 6590 mit dem Freigegebenen HTTPS-Port der 7330 ist nun funktionell.
Rufe ich den Link auf, komme ich von außen auf das WI der FritzBox7330.
Soweit so gut.
Wenn ich jetzt die Lan-Lan Kopplung über die GUI einrichte kommt aber keine Verbindung zu stande.

Aber auch danach würde ich mich (bei der Umstellung auf eine LAN-LAN-Verbindung, die in diesem Falle tatsächlich auch auf beiden Seiten mit einer Textdatei zu konfigurieren wäre, weil die eine Seite nur passiver Responder sein darf (was mit dem GUI nicht geht) und die andere eine modifizierte "accesslist" (auch nicht per GUI einstellbar) benötigt) nicht auf Anleitungen und/oder Vorschläge verlassen, die dermaßen alt sind.

Das ist dann wohl die Antwort darauf, warum LAN-LAN Kopplung (Meine Konstellation) nicht über GUI funktioniert..

Einen plausiblen Grund, das mit einer "conntype_user"-Verbindung zu lösen, kann ich hier nicht sehen (die 7330 macht dann halt NAT über die IP-Adresse aus dem VPN) und ich würde das auch nicht so konfigurieren. Wenn es noch "besondere Umstände" gibt, die tatsächlich eine "conntype_user"-Verbindung unumgänglich machen, dann solltest Du diese noch beschreiben.

Aber selbst wenn man das mit einer solchen User-Verbindung macht (bzw. machen will), woher stammt denn dann die Feststellung, daß die Lösung auf Seite 12 (sprich: Ändern der "accesslist") hier nicht funktionieren würde? Gibt es da irgendwelche Protokolle von solchen Fehlversuchen? Auch hier kann ich (weder in der Beschreibung noch in den Dateien) einen Grund sehen, warum man die "accesslist" nicht anpassen können sollte - außer daß dieses halt über das GUI (was 2011 noch gar nicht existierte) nicht möglich ist.

Ich habe die Accesslist gemäß (Lösung Seite 12 angepasst) und keine Verbindung hinbekommen.

Was wäre denn dann deiner Meinung nach eine zeitgemäße/saubere/perfekte Lösung dieser Konstellation?

### Zusammenführung Doppelpost by stoney ###

@michaelFritte: Bitte testen und um Rückinfo.
Danke für deine Mithilfe, melde mich wenn getestet
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: Micha0815
Vorschlag für Test (Catch-All VPN-Setup, except DNS Queries):
FB7360 (Dial-Out):
vpn.cfg:
conn_type = conntype_out;
OLD:
Code:
accesslist = "permit ip any 192.168.10.0 255.255.255.0";
NEW:
Code:
accesslist = "reject udp any any eq 53",
"reject udp any any eq 500",
"reject udp any any eq 4500",
"permit ip any any";
@michaelFritte: Bitte testen und um Rückinfo.
Die Verbindung steht und der gesammte Traffic wird getunnelt. Ich habe es mit oben zittierter Lösung von umgesetzt (Catch-All VPN-Setup, except DNS Queries). (conntype_out/conntype_user)
Vielen Dank nochmals für eure Hilfe.
 
Auch mein Provider lässt keine "nomadische" Nutzung von SIP/VOIP.
Dies möchte ich jetzt durch VPN von 2 Fritzboxen umgehen.

Fritzbox 1 DSL mit SIP/VOIP

Fritzbox 2 UMTS/LTE mit Fritzbox 1 verbunden.
Code:
accesslist = "reject udp any any eq 53", "reject udp any any eq 500", "reject udp any any eq 4500", "permit ip 192.168.Fritz2.0 255.255.255.0 any";

Verbunden sind die beiden Boxen, beide haben die selbe öffentliche IP wie Fritzbox 1
Allerdings weigert sich Box 2 beharrlich, das VOIP zuzulassen. Im Systemlog findet sich:
Code:
Anmeldung der Internetrufnummer 49xxxxxxxxxxx war nicht erfolgreich. Ursache: DNS-Fehler [85 Meldungen seit 31.03.19 16:16:10]
Hat jemand eine Idee, woran es hapern könnte?
 
Eine echte nomadische Nutzung setzt auch versciedene IP-Adressen der einzelnen Anschlußpunkte voraus.
Sonst wäre es ja eine Art Parallelschaltung und nix nomadisches.
 
Von mir aus auch Parallelschaltung. Hauptsache ich kann von Fritzbox2 über den Anschluß 1 telefonieren. Per VPN vom Handy mit der FritzboxFon App geht es ja, nur nicht von der 2. Box aus nicht.
 
Dazu muß die Telefonnummer nur an der ersten Box registriert sein.
Für Box Nr. 2 ist dann Box Nr. 1 der Registrar (Provider).
 
  • Like
Reaktionen: Hamburger-E65
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.