2 Fritz!Box 7490 - VPN - VoIP Probleme

[hjoerg]

Ich habe folgende Herausforderung:

2 FritzBox’ en 7490 sind per VPN verbunden, an Box 1 ist ein Telekom SIP Trunk angeschlossen und an Box 2 ein Telekom VoIP.
Box 2 hat eine zusätzliche “eigene Rufnummer” eingetragen, welche in Box 1 als Telefoniegerät eingetragen ist.
Registrierung erfolgt und interne Anrufe von Box 1 auf Box 2 funktionieren auch, nur andersherum leider nicht.
Jetzt meine Frage:
Was muss ich hier spezielles einrichten, denn ich sehe komische Kombinationen wenn ich von Box 1 anrufe zb ***124#*#**2 hmm müsste nicht nur *124* für die explizite Amtsbelegung verwendet werden - denn dies klapp wenn ich von Box 2 über *124#<externe Rufnummer> wähle, aber interne Nummern von Box 1 erreiche ich über dieses Konstrukt nicht !

Hoffe es war einigermaßen verständlich dargestellt

[Update 12.11.18]
Egal ob ich ***124#*#**2 (für Fon1 auf der Box 1) oder *124#**2 (für Fon1 auf der Box 1) von meiner Fritz!Fon App wähle, bekomme ich zwar den richtigen Namen angezeigt, aber werde abgewiesen - was ich noch gesehen habe, er belegt nicht die "Leitung" *124' sondern immer die *121* des Telekom VoIP Accounts - was mich nun verwundert.

Grüße

 

[Micha0815]

Du solltest Deine Wünsche und Angaben etwas konkretisieren, damit man Dir helfen kann.
1. VPN-Verbindung LAN2LAN zwischen den FBs?
2. Box1 hat wieviel Rufnummern im Trunk?
3. Box2 wieviele?
4. Die Fritz!Fon-App wird als VPN-Client behandelt, wobei es drei Szenarien gibt. Eingebucht im WLAN Box1 oder Box2 oder Mobilfunk/Sonstiges externes Netz.
5. Wenn Du intern sprechen möchtest, könnte **62x die Rufnummer der App sein? U.U. musst Du auf beiden Boxen ein IP-Phone kreuzweise einrichten.

Je nach Art und Konfiguration der VPN-Verbindung, gibt es unterschiedliche Lösungen. Wichtig wäre auch die Anzahl und Art (DECT/IP-Phones/ISDN/Schnurgebunden) der beteiligten Endgeräte zu beschreiben, und was neben internen Gesprächen nach draussen über welche SIP-Accounts gehen soll, bzw. welche Geräte wo über welche SIP-Accounts für eingehende Gespräche erreichbar sein sollen.
LG

 

[hjoerg]

Das kann ich gerne machen

1. Verbindung zwischen den beiden FBs ist ein IPSec VPN über das Internet
2. Box 1 hat 13 registrierte Rufnummer im Trunk
3. Box 2 hat 3 registrierte Rufnummern nach extern (Telekom) und eine als Nebenstelle der Box 1
4. Die Fritz!Fon App ist per VPN (externes Netzt) an Box 1 oder Box 2 (beides getestet), wobei auch schon innerhalb des WLAN an Box 2 getestet wurde, ohne Erfolg
5. Die App hat an Box 1 die **620, diese gibt es natürlich auch auf der Box 2 für ein dort angeschlossenes Gerät ( in dem Fall ein Fax), aber auch andere interne Nummern auf Box 2 kann ich nicht erreichen - ich dachte über die direkte Belegung der Leitung *124# könnte ich die Nebenstellen der Box 2 direkt adressieren, oder zumindest wie oft beschrieben mit ***124#*#**620 - diese Kreuzweise Einrichtung hatte ich auch schon woanders gelesen, nur das wird schwer wenn diese Nr. auf beiden Seiten in Verwendung ist - oder ?

Belegung:
an Box 1 sind zwei Analoge Ports (Fon 1 und Fon2) belegt mit jeweils einem Telefon und via internen SIP ein Grandstream ATA 701 für den Fax, hier werden noch Telefone hinzu kommen, aber aktuell noch nicht
an Box 2 ist ein AP Telefon an Port Fon1

Gespräche:
an Box 1 sollen interne Gespräche zu den lokal angeschlossenen Telefonen funktionieren + die eine NST an Box 2 -- nach extern jedes Telefon seiner zugewiesenen Nr
an Box 2 sollen nach extern alle Gespräche gehen, außer die NST an Box 1 über diesen VPN Tunnel.

Hintergrund: zwei Wohnungen, die sich später eine Türsprechstelle teilen und Gespräche von Wohnung 1 zu Wohnung 2 über den internen Weg.

 

[stoney]

Von AVM gibt es in der Regel KB-Artikel in welchen die verschiedenen Szenarien behandelt sind.

Welcher Anleitung wurde gefolgt? (Link dorthin beifügen)
(am Einfachsten wäre es, es würden von beiden Boxen Screenshots der betreffenden Einstellungen/Einstellungsseiten angefertig und ebenfalls mit angefügt)

Ich habe zB eine Firmen-VPN-Einwahl zu einer anderen F!B.

Es kann untereinander telefoniert sowie wenn gewollt zB eine "extern" angerufene MSN bei mir (lokal) klingeln.
Ebenso kann ich mit der passenden Vorauswahl über diese externe MSN Gespräche (incl Signalisierung der korrekten externen Rufnummer) führen.

Leider konkretisiert Dein 1. nicht die verwendete Art des VPN-Aufbaus (Sagt ansich ja nur etwas über die verwendete Verschlüsselung aus)

 

[hjoerg]

Ich bin keinem kb Artikel gefolgt, da m.W. für dieses Szenario keine offizielle Vorgehensweise gibt.

Ein Screenshot mit internen Besamungen poste ich ungern hier öffentlich - denke das ist nachvollziehbar !

FB 2 (Netze 192.168.3.0/24) - Eigene Rufnummer 21 (Rufnummer für die Anmeldung + interne Rufnummer der Fritz!Box) mit Vorauswahl *124# (Anbieter Fritz!Box im Heimnetz) - DSL-Internet (IPSec VPN) - DSL-Internet - FB 1 (Netz 192.168.2.0) - Telefongerät **622


Das beschriebene Szenario mit externen Rufnummern die intern weitergeleitet werden und der entsprechenden Auswahl nach exten telefonieren, geht ja auch so wie ich im initialen Post beschrieben habe, nur interne Nummern nicht und das auch nur in eine Richtung nicht.

das VPN ist als "Ihr Heimnetz mit einem anderen Fritz!Box Netzwerk verbinden (LAN-LAN-Kopplung)" aufgebaut, d.h. ohne weiteren Einfluss, reines Routing zwischen den beiden lokalen Netzen, wie eben so ein IPSec siite2site VPN aufgebaut ist

 

[Micha0815]

Wie @stoney schon fragte, ist der VPN-Verbindungstypus massgeblich. Du musst Dir auch vor Augen halten, dass bei 13 Rufnummern im Trunk die Anzahl der Sprachkanäle einerseits seitens der Telekom und anderseits Fritz!Box-bedingt die Anzahl gleichzeitiger Gespräche begrenzt ist. Die gegenseitige IP-Phone-Registrierung via VPN belegt nochmals Kanäle, wodurch es für die imho wichtige und gemeinsam genutzte Tor-/Türsprechstelle "eng" werden könnte?
Da gäbe es sicherlich einfacherere Lösungen, wenn die beiden Wohnungen im selben Gebäude/Anwesen liegen
LG
Nachtrag: Laut #5 LAN2LAN (sieht man in der *.export-Datei) Um dort Fehler zu erkennen in der access_list musst Du halt doch unter Auslassung der credentials diese posten oder in ähnlichen threads hier zu den Deinigen vergleichen.

 

[hjoerg]

@Micha, von welcher access_list sprichst du ?

Unter dem Bericht der VPN Verbindung

phase2remoteid {
ipnet {
ipaddr = 192.168.2.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.2.0 255.255.255.0";

mehr finde ich da nicht !

 

[Micha0815]

Du musst schon die vpn.cfg aus beiden FBs andienen (zu erkennen in der jeweiligen *.export oder support.txt), um zu erkennen, wer mit wem was darf ... das gezeigte ist entweder unvollständig oder falls selbst kreiert, da nicht erkennbar aus welcher beteiligten FB das stammt? falsch bzw. unvollständig (ike_
LG
P.S.: Kurz g* gesucht ...

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "fd-wv-fw03";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 80.154.108.229;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "fdorf.webernetz.net";
                }
                remoteid {
                        ipaddr = "80.154.108.229";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "alt/aes/sha";
                keytype = connkeytype_pre_shared;
                key = "ExdHIoxzmsBbkbW5vnkUVAlCNcNf2n";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.86.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.130.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-3des-sha/ah-no/comp-no/pfs";
                accesslist = "permit ip any 192.168.130.0 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";
}

sieht etwas umfangreicher aus, und umfasst nur EINE Beteiligte FB. Dabei fqdn und Passwörter xxx-en dürfte via code-tags kein Umstand sein, ohne seine "Besamungs-Utensilien"

Ein Screenshot mit internen Besamungen poste ich ungern hier öffentlich - denke das ist nachvollziehbar !

in voller Pracht präsentieren zu müssen?

 

[hjoerg]

So ! beide vpncfg Abschnitte - die ike_forward_rules habe ich leider nicht gefunden

FB 1:

vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "321.domain.de";
                boxuser_id = 0;
                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 = "321.domain.de";
                keepalive_ip = 192.168.3.1;
                localid {
                        fqdn = "$$$$xxxxxxxxxxxxxxxxxxxx1";
                }
                remoteid {
                        fqdn = "$$$$xxxxxxxxxxxxxxxxxxxx2";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "$$$$xxxxxxxxxxxxxxxxxxxxkey1";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.2.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.3.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.3.0 255.255.255.0";
                app_id = 0;
        }
     
        voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
                            "tcp 0.0.0.0:5060 0.0.0.0:5060",

FB 2

vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "123.domain.de";
                boxuser_id = 0;
                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 = "123.domain.de";
                keepalive_ip = 192.168.2.1;
                localid {
                        fqdn = "$$$$xxxxxxxxxxxxxxxxxxxx2";
                }
                remoteid {
                        fqdn = "$$$$xxxxxxxxxxxxxxxxxxxx1";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "$$$$xxxxxxxxxxxxxxxxxxxxkey1";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.3.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.2.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.2.0 255.255.255.0";
                app_id = 0;
        }

                voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
                                    "tcp 0.0.0.0:5060 0.0.0.0:5060",

 

[hjoerg]

Leider habe ich von AVM auch keine zielführende Antwort bekommen, hier heißt es nur dass dies keine zugesicherte Funktion sei und somit keine Unterstützung möglich wäre - super Sache.

Ich habe nun doch ein paar Screenshots mit im Anhang !
Frage: Bei den Anmeldedaten für die externe Nummer bin ich mir nicht sicher - aber in eine Richtung kann ich ja telefonieren, daher müsste dies egal sein - oder ?

 

[Micha0815]

Erstens solltest Du Deine *.cfg im Bereich credentials (das sind die Stellen mit $$$$) sinnvoll ersetzen/xxx-en. So kann die jeder Leser decodieren auf einer anderen FB.
Zweitens fehlen imho die essentiell für IPSEC-Protokolle wichtigen ike_forward_rules, die bei mehreren VPN-Einträgen ganz am Ende stehen. Die voip_forwardrules sehe ich zum ersten Mal im Bereich vpn. Hast Du oder ein Programm die dort hingepackt bzw. wo hast Du dazu etwas gelesen?
Drittens. Bei FB2 würde ich editable = yes rauswerfen, da es Ärger machen kann und für LAN2LAN wohl nicht vorgesehen ist.
Viertens bei den IP-Phones immer auf die User- und Passwort-Länge achten.
Fünftens die Besonderheiten beim import bzgl. möglicher ausgeschalteter 2FA bedenken und ggfs. vorher einschalten (lassen).
LG

 

[hjoerg]

1. Ich habe die Credentials verschleiert - danke für den Hinweis !
2. Ich finde in dem Export File leider keinen Eintrag mit ike_forward_rules
3. kann ich das *.export File editieren und auch so wieder einspielen, oder auf der Box selbst editieren - ist da kein Hashwert in Form md5 check oder ähnlichem gelegt ?
4. Hier habe ich über 8 Zeichen
5. ich habe aktuell für die Testphase 2FA deaktiviert, da ich remote auf die FBs zugreife und niemanden vor-Ort habe, der mir das immer wieder bestätigt - ist das ein Problem ?

LG

 

[Micha0815]

2. Ich finde in dem Export File leider keinen Eintrag mit ike_forward_rules

Deshalb solltest Du diese ja mal einfügen und die voip_forwardrules rauswerfen. Du kannst eine vpn.cfg mit einem vernünftigen Editor (ich nehme stets Notepad++) als Import-Vorlage erstellen. Bei den FWs 7.0x gab es z.T. Probleme mit ausgeschalteter 2FA, weshalb ich noch nicht meine entfernte FB darauf upgedatet habe.

Die einfachste Methode für diese kleine Änderung dürfte der aktuelle FB-Editor sein, falls die VPN-Verbindung auch ohne ike_forward-rules korrekt aufgebaut ist. Der Fernzugriff sollte als Rettungsanker vorhanden sein und funktionieren. Entsprechende IP-Phones müssen auch die richtigen Berechtigungen haben bzgl. Zugriff aus dem Internet/Heimnetz.
LG

 

[hjoerg]

sorry bekomme nicht hin, mit FB-Editor editiere ich die Datei und spiele diese zurück - dann startet die Box neu und lädt die alte Datei, mit jedit (nutze Mac daher kein Notepad++) kann ich die Datei nicht zurückspielen, da die Datei dann anscheinend nicht gelesen werden kann.

klappt bei mir irgendwie nicht - evtl. hab ich ein Syntax Fehler mit fehlenden Klammern

 

[Micha0815]

Ich bin keinem kb Artikel gefolgt, da m.W. für dieses Szenario keine offizielle Vorgehensweise gibt.

Dies habe ich -u.U. fahrlässig- so interpretiert, dass Du eine eigene vpn.cfg kreiert hast und einspielen konntest.
Eigentlich, sofern "plausibel", lässt die FB viele Varianten einer vpn.cfg als Import zu. Wie um alles in der Welt, sind die VPN-Configs in die Boxen gelangt?
Der FB-Editor sollte eigentlich Plattformunabhängig funktionieren da JAVA-basiert? Dass nach Änderungen die FB neu startet ist normal, da sie dies nach konventionellen Imports von *export-Dateien so auch macht.
LG

 

[hjoerg]

ok - die erste Konfiguration war über die FritzBox UI und da kann man nur die Gegenstelle, das Netz und den PSK angeben - da kommt dann solch eine Konfiguration raus.
Jetzt habe ich alle Boxen mit der "Fernzugriff erstellen" Applikation neu gemacht und nun sind auch die ike_forward-rules drin - jedoch leider ohne Verbesserung, die Situation ist die gleiche.
ich vermute, dass es an den Settings für die "Eigene Rufnummer" liegt, weil immer die erste Nummer verwendet wird, obwohl ich explizit mit ***125* die entsprechenden Nummer vorauswähle

 

[hjoerg]

Solved !

Es geht nun - Konfig über “Fernzugriff einrichten” und den ike_forward-rules scheint die Lösung gewesen zu sein.

Danke in die Runde

 

[Faxenmacher]

Wenn ich mich hier mal dranhängen darf: hjoerg, was hast du denn genau editiert mit den ike_forward-rules?

Ich vermute, daß dies auch mein Problem lösen könnte:

Ich habe 2 entfernte 7490 gem. AVM-Anleitung seit Jahren erfolgreich über VPN LAN-LAN gekoppelt, was auch keine Probleme macht. Ich kann alle Geräte an der entfernten Fritze über ihre IPv4-Adresse ansprechen.
Beide Fritzen sind an einem Telekom All-IP Anschluss mit jew. 5 MSNs registriert. Am Standort B habe ich ein Telefoniegerät eingerichtet, welches ich mit einer eigenen Rufnummer am Standort A verbunden habe, Status ist grün. Somit konnte ich die Firmenrufnummer von Standort B beliebig im Homeoffice am Standort A verwenden, abgehend, ankommend, alles problemlos.

Seit dem Update von FritzOS 6.? auf FritzOs 7.01 kann ich nur noch abgehend von A über B raustelefonieren. Ankommende Rufe an B lassen die entspr. Telefone an A nicht mehr klingeln. (Lokale ankommende Rufe an A und B sind ok)
Weder ein ISDN-Telefon am internen S0 noch ein FritzFon (DECT) noch ein Softphone (SIP) klingeln trotz enspr. Einrichtung der Telefoniegeräte in A nicht mehr. Jedoch geht die LED Internettelefonie kurz an und ich in der Anrufliste finde ich einen verpassten Anruf.

Wer weiss Rat?

Gruß vom Faxenmacher

 

[Micha0815]

Ohne genau das Problem orten zu können aus den spärlichen Angaben? Die Vorgaben bei FW-Updates hier die Passwortlänge und Unterschiedliche User-Namen bei IP-Phones, was via VPN halt auch zuschlägt, würde ich als erstes mal untersuchen. Die neue Mindestlänge 8 Zeichen und ungleich User-Account schlägt fast täglich in Verbindung mit FW-Updates im Forum auf?
LG

 

[PeterPawn]

In beiden Boxen finden sich (unmittelbar nach so einem fehlgeschlagenen Anruf) die entsprechenden SIP-Pakete, mit denen man dem Problem nachgehen kann. Die erste Idee wäre es wohl, daß die erste FRITZ!Box die Infos zur "Quelle" des Anrufes 1:1 durchreicht und damit die zweite Box versucht, eine direkte RTP-Verbindung zum Provider (oder gar zum Anrufer) aufzubauen. Da das aber sicherlich unterschiedliche Adressen sind, könnte das der Gegenstelle etwas komisch erscheinen. Da helfen dann meist ein paar Einstellungen, damit die erste Box tatsächlich auch für die RTP-Verbindung als "Vermittler" weitermacht (also als B2BUA) und gar nicht erst versucht wird, eine direkte Verbindung einzurichten.

Das ist zwar nur meine Vermutung und mehr "Bauchgefühl" anhand der geschilderten Symptome, aber die SDP-Einträge in den SIP-Paketen der Box A sollten ja Aufschluß darüber geben, welche RTP-Streams der Box A angeboten werden.

Nur muß man das tatsächlich (erst recht bei fünf aktiven Registrierungen, die schon im Ruhezustand jede Menge Traffic produzieren) recht zeitnah zum Versuch der Verbindung machen, sonst sind die Einträge im Ringpuffer ruckzuck wieder überschrieben. Klappt das deshalb nicht, deaktiviert man für den Versuch die nicht benötigten Registrierungen (in beiden(!) Boxen). Man sollte auch die Support-Daten aus beiden erstellen, denn nur dann kann man eindeutig die entsprechenden Pakete auf beiden Seiten finden und dem Dialog auch dann noch folgen, wenn Box B nach dem Abbruch irgendwelche Messages an den Anrufer (bzw. den Provider) schickt - spätestens wenn sie tatsächlich als B2BUA arbeitet, kommuniziert sie ja ihrerseits auch in beide Richtungen (Box A und Provider) parallel.