[Gelöst] LAN-LAN-Koppelung mit nur 1 öffentlichen IP

Entschuldigung! So viel Mühe wollte ich dir nicht machen. Ich wollte ja nur meine Erfahrungen mitteilen.

Was mich noch wundert: Wozu trägt der bei "keepalive_ip = 192.168.10.1" diese IP ein, wenn ich die dann nirgends in den keepalive Paketen sehe? Der NAT-keepalive wird doch an die öffentliche IP gesendet.

Getract habe ich auf der Gegenseite auf der FB7170. Da wird mir folgendes angeboten:
Internet

1. PVC
2. PVC
Schnittstelle 0 ('internet')
Schnittstelle 1 ('voip')
alle Schnittstellen
Zuerst habe ich "Schnittstelle 0 ('internet')" genommen und da hatte ich die Pakete ohne ATM.
Dann wollte ich sie noch mal mit ATM sehen und habe "1. PVC" genommen.
Hättest du doch bestimmt genau so gemacht, oder?
Aber ich finde die keepalive Pakete nicht! Grübel, grübel.:confused: Ja warum sind denn hier so viele SIP Pakete?
Aha, da hat AVM wohl die PVC's verwechselt. Richtig! Im "2. PVC" waren dann die gesuchten Pakete da.

Wireshark zeigt die Pakete unter Info gleich mit "NAT-keepalive" an.
Dann den Filter setzen (öffentliche IP der Gegenseite): ip.addr == 2.200.111.222 und Apply drücken.
Und schon hast du nur noch den VPN-Verkehr.
 
Zuletzt bearbeitet:
Ist keine Mühe, ich will ja meine Behauptungen oben selbst noch einmal prüfen, wenn das auf einmal vielleicht nicht mehr stimmt.

Ich habe jetzt über 6 Minuten (370 Sekunden) einen Mitschnitt der "1. Internet-Schnittstelle" (das ist ptm_vr9, wirklich unmittelbar vor dem DSL-Modem), von "internet" (erster PVC, auch wenn das bei VDSL eher mit VLAN läuft) und von der "Routing-Schnittstelle" (das ist "dev dsl") gemacht und dabei (trotz zweier aktiver VPN-Verbindungen, von denen eine auch von meiner Box aus mit "keepalive_ip" konfiguriert ist) nicht ein einziges IPSec-Paket (weder mit NAT-T noch ohne) im Mitschnitt gefunden - jeweils bei der Aktivierung eines Filters für die von den Gegenstellen verwendeten IP-Adressen.

Nur wenn ich selbst entsprechenden Verkehr verursache (ping aus der Telnet-Session der Box in einem neuen Mitschnitt), werden jeweils 130 Byte lange ESP-Pakete ausgetauscht, von denen 46 Byte für die Adressierung draufgehen (18 für Ethernet+VLAN, 8 für PPPoE, 20 für den "äußeren" IP-Header). Das Ping der Busybox liefert offenbar auch einen anderen Payload, da stehen bei mir in den 56 Byte nur binäre Nullen ... damit kann man also auch die Ping-Pakete der FRITZ!Box von denen eines "normalen" Linux-Clients unterscheiden (und die enthalten auch kein "PING" als Payload).

Ich werde den Verdacht nicht los, daß da meine 7490 mal einen Restart haben möchte (bisher wurde der avmike nur immer umkonfiguriert) ... aber ich muß noch etwas warten, bis ein größerer Upload durch ist.

Das kann irgendwie alles nicht so richtig stimmen und dabei ist das nicht einmal eine Labor-Version, sondern die 06.23 ... alles sehr merkwürdig.
 
So, jetzt habe ich es gestern mal geschafft die VPN Verbindung den ganzen Tag in Ruhe zu lassen.

Ergebnis im Online-Zähler über 24h:

Daten gesamt: 322 KB
gesendet: 203 KB
empfangen: 119 KB

Warum ist das bei gesendet fast das doppelte vom empfangen?
 
Zuletzt bearbeitet:
Ich rate mal (wenn Du so eine Situation noch einmal über einen vollen Zeitraum von 24h erträgst, mach doch mal einen Paketmitschnitt, das geht bei Telnet-Zugriff auch auf einen USB-Stick) und behaupte, daß die NAT-Keepalive-Pakete gesendet werden, es darauf aber keine Antworten gibt. Die wären für das Aufrechterhalten einer NAT-Connection ja auch nicht erforderlich.

Trotzdem ist das extrem wenig, kannst Du noch einmal die Situation schildern (was ist da wirklich aktiv) und ggf. auch mal eine VPN-Konfiguration anonymisiert dazu veröffentlichen? Da dürfte ja nach einer überschläglichen Berechnung nicht einmal eine SIP-Anmeldeung der FRITZ!Box aktiv sein, denn die müßte schon mehr Traffic erzeugen ... (knapp) 4 KB alle 260 Sekunden ergibt ja alleine schon (86400 / 260) * 4096 = 1,29 MB an Traffic. Bei 1&1 im CC konnte man glaube ich - nach einigen Tagen - auch das aus deren Sicht verbrauchte Volumen tagesgenau abfragen, wenn Du da noch einmal den Vergleich wagen könntest, wäre das auch schön.

Ich bin noch nicht wieder zur Suche gekommen, das wird auch am WE definitiv nichts mehr. In #30 habe ich erst einmal eine Warnung eingefügt, meine Beobachtungen mit Vorsicht zu genießen.
 
über einen vollen Zeitraum von 24h erträgst, mach doch mal einen Paketmitschnitt
Bin ich gerade dabei, diesmal auf der UMTS-FB7362SL, unten kommt die Hochrechnung von 12 Uhr auf volle 24h.
Ich mußte mir nur was einfallen lassen, daß der PC keine Daten ins Internet schickt und mir damit die Ergebnisse verfälscht. Ich habe ihm dann nur eine IP und kein GW und kein DNS gegeben.
das geht bei Telnet-Zugriff auch auf einen USB-Stick
Das kenn' ich noch nicht. Ist ja günstig, da muß nicht die ganze Zeit ein PC mit laufen.
Kannst du mir da mal bitte die Befehle aufschreiben oder einen Link geben.
die NAT-Keepalive-Pakete gesendet werden, es darauf aber keine Antworten gibt.
Jain. Die DSL-FB7170 gibt schon die Antwort, siehe #37, aber die kommen am UMTS nicht an.
Vermutlich ist der CGP (CG-PAT) daran Schuld.
(was ist da wirklich aktiv)
So gut wie nichts, nur DDNS und VPN.
Weil ich ja gerade nur die Daten zum aufrecht Erhalten des VPN sehen will.
nicht einmal eine SIP-Anmeldeung
Richtig
Ja, werde ich nach 3 Tagen machen.

So jetzt zu meiner Hochrechnung für 24h:
Da auf dieser Seite PPPoE und das Ethernet im Paket weg fällt, sind die Pakete entsprechend kleiner.
z.B. das NAT-keepalive Paket, was in #37 noch 52 oder 62 Byte hat, sehe ich hier mit nur 30 Byte:
Code:
0000  21 45 00 00 1d 56 96 00  00 40 11 a0 53 02 c8 xx
0010  xx 5c c8 xx xx 11 94 11  94 00 09 00 00 ff

305KB - gesamt

aller 20s: 1 Paket a 30 Byte:
115KB - NAT-keepalive nur gesendet s.o.

aller 120s=2min am Anfang, nach 10616s=177min=knapp 3h (Zeitpunkt des IP Wechsels auf der DSL Seite) nur noch alle 3242s=54min (wieso das?): 2 Pakete 64 + 80 Byte:
18KB - DNS Anfrage + Antwort der DDNS der anderen FB
Wenn Die FB das aber im 2 min Rhythmus weiter macht, dann sind das auch 104KB.

aller 1024s=17min: 6 Pakete a 77 Byte
43KB - Anfrage und Antwort an 3 verschiedene NTP-Server

aller 3242s=54min: 8 bis 11 Pakete
77KB - ISAKMP
48KB - dazu gehörende verschlüsselte Pakete

nur ein mal am Anfang: 11 Pakete
1KB - DDNS Aktualisierung

Hier noch die UMTS-vpn.cfg, eigentlich nichts besonderes:
Code:
vpncfg {
        connections {
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "DSL.ddns.com";
                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 = "DSL.ddns.com";
                keepalive_ip = 192.168.10.1;
                localid {
                        fqdn = "UMTS.ddns.com";
                }
                remoteid {
                        fqdn = "DSL.ddns.com";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geheim";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.20.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.10.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.10.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";
}
Und der Teil aus der DSL-vpn.cfg:
Code:
                enabled = yes;
                conn_type = conntype_lan;
                name = "UMTS.ddns.com";
                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 = "UMTS.ddns.com";
                localid {
                        fqdn = "DSL.ddns.com";
                }
                remoteid {
                        fqdn = "UMTS.ddns.com";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geheim";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.10.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.20.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.20.0 255.255.255.0";

Was mich in den Ereignissen verwundert:
Code:
23.06.15  04:46:35  VPN-Verbindung zu DSL.ddns.com wurde erfolgreich hergestellt.
23.06.15  03:49:32  VPN-Verbindung zu DSL.ddns.com wurde getrennt. Ursache: 3 IKE server
23.06.15  03:47:32  VPN-Verbindung zu DSL.ddns.com wurde erfolgreich hergestellt.
23.06.15  02:59:54  VPN-Verbindung zu DSL.ddns.com wurde getrennt. Ursache: 3 IKE server
Das 2:59 ist klar, da hat die DSL Seite eine neue IP bekommen, PPPoE Trennung.
Aber warum dauert es dann 47 min bis das VPN wieder steht?
Wieso bricht es dann nach 2 min zusammen? Da war auf DSL-Seite nichts.
Und dauert dann nochmal 57 min bis der VPN wieder steht?
Könnte da das always_renew = yes helfen?

EDIT: eine Ursache gefunden: Die FB hat auf die DNS Anfrage um 3:49 Uhr die alte IP bekommen, obwohl sie vorher schon 2 mal die neue IP erhalten hatte (2:59 und 3:47).
Die nächste DNS Anfrage machte sie dann erst 4:46 Uhr.
Wie geht denn so was?
 
Zuletzt bearbeitet:
Das kenn' ich noch nicht. Ist ja günstig, da muß nicht die ganze Zeit ein PC mit laufen.
Kannst du mir da mal bitte die Befehle aufschreiben oder einen Link geben.
Ich suche es mal raus ... das war irgendwas mit dem Aufruf von /usr/www/cgi-bin/capture-notimeout per Kommandozeile mit passend gesetzten Environment-Variablen für das zu dumpende Interface (das ist ja ein CGI und da stehen die Daten aus dem HTTP-Request dann im Environment des aufgerufenen Prozesses) und einer Ausgabeumleitung in eine Datei auf dem USB-Speicher (stdout ist ja das, was das CGI-Module sonst an den Browser sendet). Wäre jedenfalls der spontane Ansatz dazu, der mir einfällt als logischste Variante ... aber ich teste das lieber noch mal, bevor ich einen entsprechenden CODE-Block als Beispiel poste.

Wie geht denn so was?
Provider-Server befragt? Dann macht der vielleicht die Antworten aus einer Farm per "round robin" und einer der dort versammelten Server war noch nicht aktualisiert bzw. hat einen älteren Eintrag ausgeliefert, weil ein neuer nicht zur Verfügung stand oder er hat einen falsch konfigurierten Cache, der nicht richtig invalidiert wird nach Ablauf der TTL? Was ist denn überhaupt die TTL bei einer "frischen" Abfrage, also wenn der Forwarder den Eintrag auch noch nicht im Cache hat - das sollte ja die TTL vom DynDNS-Provider sein.

Das ist alles ohne Mitschnitt (wer da diese falsche Information geliefert hat) eher die berühmte Glaskugel, da gibt es zu viele Stolpersteine im DNS.
 
Provider-Server befragt?
Ja, ich habe nichts spezielles eingestellt: 139.7.30.126 dns2.vodafone.de
einer der dort versammelten Server war noch nicht aktualisiert bzw. hat einen älteren Eintrag
In den ersten 5 min könnte ich das noch verstehen, aber nach 50 min sollte sich die neue IP doch "rum-gesprochen" haben?
TTL: 253
 
Zuletzt bearbeitet:
Capture auf der Box in Datei auf USB-Speicher:

Code:
QUERY_STRING=sid=[I][B]sid[/B][/I]\&capture=Start\&snaplen=1600\&minor=[I][B]minor[/B][/I] REMOTE_ADDR=[I][B]127.0.0.1[/B][/I] REQUEST_METHOD=GET /usr/www/cgi-bin/capture_notimeout >/var/media/ftp/[I][B]path[/B][/I]/capture.pcap
Die SID muß man halt erzeugen durch eine Anmeldung von der Box selbst (wenn man die 127.0.0.1 verwendet, das hat nichts mit dem Capture oder der Ausgabe zu tun, es geht nur um die Anmeldung), ansonsten kann man sich auch mit
Code:
msgsend ctlmgr sessions
sleep 2
eval $(sed -ne "s/^\([a-f0-9]*\) *\([0-9]*\) *\([0-9]*\) *\([A-Za-z0-9]*\) \([0-9.]*\) *\([^ ]*\) .*BoxAdmin:RW.*$/sid=\1 valid=\2 uid=\3 source=\4 ip=\5 user=\6/p" /var/tmp/sessions.txt)
echo ip=$ip sid=$sid
eine SID und die zugehörige IP-Adresse einer aktiven Sitzung mit Admin-Rechten (BoxAdmin:RW) "borgen". Wenn das Capture erst einmal läuft, spielt die SID keine Rolle mehr.

Stoppen kann man das dann auch wieder - entweder selektiv (z.B. mit "echo sessions=capture:settings/session/list\(displayname,ifacename,minor,type\) | queries.lua" die richtige Capture-Session finden) oder mit dem Holzhammer und "iface=stopall&capture=Stop" in QUERY_STRING bei einem weiteren Aufruf.

Bei der Verarbeitung der auf dem USB-Speicher abgelegten Daten muß man dann die Download-Header vorher noch entfernen:
Code:
# hd capture.pcap | head -n 20
00000000  43 6f 6e 74 65 6e 74 2d  74 79 70 65 3a 20 61 70  |Content-type: ap|
00000010  70 6c 69 63 61 74 69 6f  6e 2f 6f 63 74 65 74 2d  |plication/octet-|
00000020  73 74 72 65 61 6d 0a 43  6f 6e 74 65 6e 74 2d 44  |stream.Content-D|
00000030  69 73 70 6f 73 69 74 69  6f 6e 3a 20 61 74 74 61  |isposition: atta|
00000040  63 68 6d 65 6e 74 3b 20  66 69 6c 65 6e 61 6d 65  |chment; filename|
00000050  3d 66 72 69 74 7a 62 6f  78 2d 76 63 63 30 5f 32  |=fritzbox-vcc0_2|
00000060  34 2e 30 36 2e 31 35 5f  31 34 34 34 2e 65 74 68  |4.06.15_1444.eth|
00000070  0a 0a a1 b2 cd 34 00 02  00 04 00 00 00 00 00 00  |.....4..........|
00000080  00 00 00 00 08 00 00 00  00 01 55 8a a6 29 00 08  |..........U..)..|
00000090  c5 82 00 00 00 68 00 00  00 68 00 00 00 00 00 01  |.....h...h......|
[...]
Hier sind das also 0x72 = 114 Byte, die wir am Beginn der Datei abschneiden müssen, wofür man
Code:
dd if=capture.pcap of=shortened.pcap skip=114 iflag=skip_bytes
unter "normalem" Linux (mit "dd" aus den Gnu-coreutils) benutzen kann. Die Busybox kennt die Option "iflag" nicht, da wäre dann
Code:
dd if=capture.pcap of=shortened.pcap bs=1 skip=114
eine denkbare (und lange laufende, denn es wird in "1-Byte-Happen" kopiert) Alternative.
 
Zuletzt bearbeitet:
Danke für deine Bemühung, aber das ist mir zu kompliziert. Ich hoffe es wird einem anderen helfen.

In der nächsten Nacht hatte ich wieder den DNS Fehler:
bis 2:55 - aller 2min die alte IP
2:57 - 1. mal die neue IP
3:52 bis 4:28 im 2min Abstand immer die neue IP
4:30 - noch mal die alte IP
4:51 - neue IP
5:45 - neue IP
6:39 - neue IP
Also nach dem sie 20 mal die neue IP erhalten hat, bekommt sie beim 21. mal nach 93min noch mal die alte IP. :confused:

Ich habe aber auch noch einen Fehler bei mir gefunden. Da hat noch ein anderer Client die UMTS-DDNS-IP aktualisiert.
Jetzt ist der Fehler mit den langen VPN Unterbrechungen beim IP-Wechsel weg und auch die DNS Abfragen der UMTS-Box bleiben im 2min Rhythmus. Das erklärt aber nicht den ober gezeigten Fehler.

Ein Blick ins CC: Wenn man ständig online ist, wird alle 6h abgerechnet. Da habe ich immer so um die 100KB. Also 400KB/Tag = rund 12MB/Monat.
 
Zuletzt bearbeitet:
Ein Blick ins CC: Wenn man ständig online ist, wird alle 6h abgerechnet. Da habe ich immer so um die 100KB. Also 400KB/Tag = rund 12MB/Monat.
So kenne/habe ich das auch ... bei mir sind es allerdings (SIP-Registrierung an einer anderen FRITZ!Box über VPN, kein Keepalive) alle sechs Stunden zwischen 600 und 700 KB, solange kein zusätzlicher Verbrauch durch Tablets/Smartphones zu Buche schlägt. Natürlich schwankt das schon dann, wenn da mal ein Anruf signalisiert wird ... die SIP-Messages werden ja auch ausgetauscht, wenn da keiner ist (was die philosophische Frage nach dem Klingeln des Telefons, wenn es gar keiner hören kann, aufwirft) und es nur parallel an beiden Boxen einen eingehenden Anruf gibt.

Zur Überprüfung des Keepalives, was ich da mal bei VPN-Verbindung gesehen haben will (war ja gar nicht diese Mobilfunk-gebundene Box, das war nur eine Hochrechnung auf Mobilfunk-Basis, weil da eben i.d.R. Volumina berechnet werden), bin ich immer noch nicht gekommen ... habe ich vorne ja in Frage gestellt; wenn ich mal viel Zeit habe, denke ich neu darüber nach, das noch einmal zu prüfen.

PS: Das capture ist eigentlich ganz simpel, man müßte es nur mal in ein passendes Skript tippen ... der "Leidensdruck" fehlt irgendwie.
 
Hier mal noch ein Auszug aus den Ereignissen der UMTS-Box:
Code:
30.06.15	05:42:13	VPN-Verbindung zu DSL.ddns.com wurde erfolgreich hergestellt.
[COLOR="#FF0000"]30.06.15	04:43:44[/COLOR]	VPN-Verbindung zu DSL.ddns.com wurde getrennt. Ursache: 3 IKE server
30.06.15	02:51:24	VPN-Verbindung zu DSL.ddns.com wurde erfolgreich hergestellt.
[COLOR="#00FF00"]30.06.15	02:51:16	[/COLOR]VPN-Verbindung zu DSL.ddns.com wurde getrennt. Ursache: 3 IKE server
29.06.15	03:17:28	VPN-Verbindung zu DSL.ddns.com wurde erfolgreich hergestellt.
[COLOR="#FF0000"]29.06.15	03:17:27[/COLOR]	VPN-Verbindung zu DSL.ddns.com wurde getrennt. Ursache: 3 IKE server
28.06.15	03:51:49	VPN-Verbindung zu DSL.ddns.com wurde erfolgreich hergestellt.
[COLOR="#FF0000"]28.06.15	02:54:43[/COLOR]	VPN-Verbindung zu DSL.ddns.com wurde getrennt. Ursache: 3 IKE server
28.06.15	02:52:44	VPN-Verbindung zu DSL.ddns.com wurde erfolgreich hergestellt.
[COLOR="#00FF00"]28.06.15	02:52:40[/COLOR]	VPN-Verbindung zu DSL.ddns.com wurde getrennt. Ursache: 3 IKE server
27.06.15	02:55:11	VPN-Verbindung zu DSL.ddns.com wurde erfolgreich hergestellt.
[COLOR="#00FF00"]27.06.15	02:55:07[/COLOR]	VPN-Verbindung zu DSL.ddns.com wurde getrennt. Ursache: 3 IKE server
25.06.15	03:00:01	VPN-Verbindung zu DSL.ddns.com wurde erfolgreich hergestellt.
[COLOR="#00FF00"]25.06.15	02:59:56[/COLOR]	VPN-Verbindung zu DSL.ddns.com wurde getrennt. Ursache: 3 IKE server
Ich habe grün die IP-Wechsel der DSL-Box und rot den "alte IP Fehler" markiert.
Also es geht manche Nacht ordentlich, und manche Nacht gibt es lange Ausfälle.


SIP-Registrierung an einer anderen FRITZ!Box über VPN
Das wollte ich auch gerade probieren. Hast du dazu den Haken gesetzt bei:
Code:
[X] Internetrufnummern über mobile Internetverbindung nutzen
Ohne Haken geht es bei mir nicht, da bekomme ich noch nicht mal eine Fehlermeldung.
Ich dachte aber wegen des VPN brauche ich den Haken gerade nicht.
 
Zuletzt bearbeitet:
Ich fragte aber nicht nach:
Code:
[_] Anmeldung immer über eine Internetverbindung

Sondern unter Internet/Mobilfunk
 
Ok, dann haben wir aneinander vorbei geschrieben ... wenn die von Dir nachgefragte Option nicht ausgewählt ist, dann wird gar keine externe SIP-Registrierung gestartet (also keine "Eigene Rufnummer" auf VoIP-Basis aktiviert), das ist aber nach meinem Verständnis eine absichtliche Sperre gegen unbeabsichtigten Verbrauch und weil einige Provider SIP in den AGB verbieten. Daß die Verbindung hier über ein VPN geht, ist für diese Einstellung nicht zu "erkennen" ... daher macht die Box auch keinen Unterschied.

Da das dann gar keinen Zusammenhang mit dem VPN hat (nur da stellt sich ja u.U. die Frage, über welches Interface der SIP-Verkehr gehen muß, damit er auch im Tunnel landet), habe ich Dich mißverstanden und da es gar kein getrenntes "voip"-Interface gibt, ist bei der SIP-Registrierung die Auswahl von "always_over_internet" eben auch vollkommen egal.
 
OK, dann weiß ich wie es gehen sollte.
Registrierung geht ja bei mir an der DSL-Box wegen der FB7170 und des 2. PVC nicht. (Du erinnerst dich?)
Fehler: Gegenstelle antwortet nicht, Zeitüberschreitung.

Dann habe ich mal die andere Richtung probiert. Also mein Snom über VPN an der UMTS-Box angemeldet.
Das geht sogar ohne den gewissen Haken (eigentlich ja Kreuz), weil wahrscheinlich eingehend.
Das hat zwar nicht viel Sinn, aber nur mal zum Test.
Alles an der UMTS-Box:
Es geht in beide Richtungen mit Ton, egal wie rum ich anwähle:
1.) Telefonieren zwischen **1 und **620 (Snom) über VPN
2.) Telefonieren zwischen **1 über GSM zum Handy

Was nicht geht:
3.) Telefonieren zwischen **620 (Snom) über VPN über GSM zum Handy
Anklingeln geht, aber kein Ton in keiner Richtung, egal wie rum ich die Verbindung aufbaue.
Ich hab schon im Snom bei den Codec g722 und pcmu entfernt, pcma steht als erstes. Hat aber auch nicht geholfen.
Auch gsm als erstes hilft nicht. Was könnte ich noch probieren?
 
Zuletzt bearbeitet:
Das geht sogar ohne den gewissen Haken (eigentlich ja Kreuz), weil wahrscheinlich eingehend.
Wenn Du unter "eingehend" "als Telefoniegerät" verstehst ... ja. Der Unterschied ist eben, daß die "Eigene Rufnummer" kein Telefoniegerät ist. Die entscheidende Frage ist, wer ist Registrar und wer ist UA.

Was könnte ich noch probieren?
Hier hast Du mich bei der Schilderung dessen, was da geht und was nicht, schon wieder verloren ... ich kann schon nicht richtig erkennen, auf welche Box Du Dich bei der Angabe "**1" (das soll sicherlich die erste analoge Nebenstelle sein) beziehst, also ob da jetzt die an der DSL- oder an der UMTS-Box gemeint ist.

Bei "Telefonieren zwischen **1 und **620 (Snom) über VPN" würde ich ja auf den Analoganschluß der UMTS-Box und das dort angemeldete Snom tippen, das wäre dann ein internes Telefonat in der UMTS-Box.

Wie ich dann aber wieder "Telefonieren zwischen **1 über GSM zum Handy" verstehen soll, da versagt meine Phantasie. Keine der beiden naheliegenden Erklärungen - analoge Nebenstelle der UMTS-Box über VPN und den DSL-Anschluß, weiter über das Mobilfunknetz zu irgendeinem Handy oder als Alternative: analoge Nebenstelle über den UMTS-Stick und die dort eingelegte SIM-Karte zu irgendeinem Handy - ergibt für mich in dem fraglichen Kontext irgendeinen Erkenntnisgewinn beim VPN bzw. die erste Variante wäre ja genau das, was Du als nicht funktionierend beschreibst, da wird es ja jetzt nicht auf einmal doch gehen.

Ich hoffe mal, mit "über GSM zum Handy" meinst Du eine ausgehende Verbindung zum Handy an der DSL-Box (erst mal egal, von welcher Nebenstelle der DSL-Box, wo die UMTS-Box dann nur eine von vielen/mehreren ist), aber das ist eigentlich auch nur geraten.

Um das mal Stück für Stück zu verstehen ... woran scheitert denn nun die Anmeldung der UMTS-Box (über eine VPN-Verbindung) als SIP-Client am SIP-Registrar der DSL-Box? Nur an der alten Firmware-Version, wo der voipd vermutlich noch keine Unterscheidung der verschiedenen Wege zum Client vornehmen kann, also das Problem aus der PM?

Der 2. PVC alleine wäre ja mit einer halbwegs aktuellen Box noch kein Problem, wenn ich da nicht etwas fundamental falsch verstehe. Auch jeden Versuch, da aus Deiner Signatur irgendwelche Schlüsse zu ziehen oder Analogien zu finden, habe ich mir abgeschminkt. Was sind denn das nun für Boxen mit welcher Firmware, die hier eine Rolle spielen?

Das endgültige Ziel erschließt sich mir aus der Beschreibung "Telefonieren zwischen **620 (Snom) über VPN über GSM zum Handy" ehrlich gesagt auch nicht so richtig (wo ist das Snom dabei dann angemeldet? zu den denkbaren varianten s.o.) ... mag aber sein, daß ich heute besonders langsam (weil todmüde) bin.
 
OK, war ich wieder zu ungenau.
Alles ohne die DSL-Box. Nur die UMTS-Box. OK der VPN geht über die DSL-Box.
Bei "Telefonieren zwischen **1 und **620 (Snom) über VPN" würde ich ja auf den Analoganschluß der UMTS-Box und das dort angemeldete Snom tippen, das wäre dann ein internes Telefonat in der UMTS-Box.
Richtig, das geht.

analoge Nebenstelle über den UMTS-Stick und die dort eingelegte SIM-Karte zu irgendeinem Handy
Richtig, das geht auch.

also das Problem aus der PM?
Ja

Was sind denn das nun für Boxen mit welcher Firmware, die hier eine Rolle spielen?
Immer wieder die 2 gleichen:
UMTS-Box: FB7362SL mit 131.06.03
DSL-Box: FB7170 mit 29.04.88 aus der Signatur

wo ist das Snom dabei dann angemeldet?
So, wie ich schrieb:
Also mein Snom über VPN an der UMTS-Box angemeldet.
Das Snom "steckt" an der DSL-Box:

Snom ---LAN--- DSL-Box ---DSL-VPN-UMTS--- UMTS-Box ---GSM/UMTS--- Handy

Das ist das, wo der Ton nicht geht. Wobei die ersten 2 Beispiele zeigen sollen, daß die einzelnen Strecken gehen:
Also 1. vom Snom über VPN zur UMTS-Box und 2. von der UMTS-Box über Stick zum Handy.

Entschuldigung, ich habe da auch so meine Schwierigkeiten es verständlich rüber zu bekommen.
 
Zuletzt bearbeitet:
Also ist das eigentlich genau anders herum und die DSL-Box soll sich als SIP-Client über das VPN beim SIP-Registrar der UMTS-Box (7362SL) anmelden, damit Gespräche vom DSL-Anschluß (bzw. von einem an der dort vorhandenen 7170 angeschlossenen Telefoniegerät) über das VPN und die UMTS-Box per SIM-Karte im UMTS-Stick geführt werden können? Ob der B-Teilnehmer dann im Fest- oder im Mobilfunknetz erreichbar ist, wäre ja für die prinzipielle Funktion erst mal egal, wenn meine Interpretation stimmt.

Dann ist Dein Problem ja auch nicht das Registrieren einer "Eigenen Rufnummer" für die 7170 an der 7362SL, wenn das erwähnte "Snom" am Registrar der 7170 angemeldet ist und nicht gleich über das VPN am Registrar der 7362SL und diese Variante funktioniert ja (das ist die erste "Teilstrecke"), wenn ich es richtig verstanden habe.

Somit müßte sich ja die 7170 ihrerseits erfolgreich an der 7362SL registriert haben und (bei entsprechenden Einstellungen) auch ein Gespräch von der analogen Nebenstelle der 7170 (**1) zur analogen Nebenstelle der 7362SL möglich sein. Im nächsten Schritt dann ja auch vom Analoganschluß der 7170 über VPN und 7362SL mit dem UMTS-Stick ins Festnetz oder ins Mobilfunknetz. Wenn das funktioniert (da spielt eben die zusätzliche Strecke "SIP-Registrar 7170 <-> Snom" dann nicht mit rein), dann würde ich noch einmal mit dem Snom schauen ... das hört sich dann für mich nämlich eher nach einem RTP-Problem an und könnte/sollte in Abhängigkeit vom gewählten Ziel sogar variieren.
 
Nö, fast alles falsch. Geh erst mal schlafen.
Du denkst bestimmt zu kompliziert.

Ich schrieb doch: Alles ohne die DSL-Box (FB7170), die macht nur das VPN.
Noch mal:
Das Snom ist über VPN an der UMTS-Box angemeldet als 620.
1.) Wenn ich mit dem Snom **1 wähle, dann kann ich mit dem analogen Telefon an Fon1 der UMTS-Box sprechen.
Das geht auch umgedreht: Ich wähle an dem analogen Telefon an Fon1 an der UMTS-Box **620 und kann mit dem Snom sprechen.

2.) Ich wähle an dem analogen Telefon an Fon1 an der UMTS-Box 0152... (meine Handy-Nr.) und werde über den Stick mit meinem Handy verbunden und kann auch sprechen.
Ach das geht umgedreht: Ich wähle vom Handy den Stick an und kann mit dem analogen Telefon an Fon1 an der UMTS-Box sprechen.

3.) Wenn ich aber mit dem Snom 0152... (meine Handy-Nr.) wähle, dann werde ich über den Stick mit meinem Handy verbunden, aber ohne Ton.
Auch das geht umgedreht auch nicht: Ich wähle vom Handy den Stick an und hebe am Snom ab, auch kein Ton.
 
Zuletzt bearbeitet:
Um das also mal von der Beschreibung etwas zu verkürzen (und einen möglichen Test aufzuzeigen) ... Du kannst also mit dem über VPN an einer 7362SL angemeldeten IP-Telefon (ein Snom-irgendwas) keine Gespräche über die 7362SL und den dort vorhandenen UMTS-Stick (mithin das Mobilfunk-Netz) führen, dabei klappt zwar die SIP-Signalisierung, aber keine RTP-Verbindung (in beide Richtungen). Soweit jetzt richtig?

Wenn ja, wie sieht es denn dann mit anderen Clients als dem Snom aus? Gilt das für alle externen Gespräche über das Snom oder nur für die in das (nicht über das - ich habe denke ich verstanden, daß dort nur der UMTS-Stick als Internet-/Telefonverbindung vorhanden ist) Mobilfunk-Netz? Hier basiert die Frage auf der Überlegung, daß dort Codecs auf der Strecke innerhalb des Mobilfunk-Netzes verwendet werden könnten, wo die FRITZ!Box mit dem event. notwendigen Umkodieren der Sprachverbindungen nicht klar kommt und eine (mit einem weniger hochwertigen Codec) aus dem Festnetz aufgebaute Verbindung vom Mobilfunk-Betreiber sicherlich nicht mit einem besseren Codec neu kodiert wird (ein Qualitätsgewinn ist ja eher nicht zu erwarten).

Mich würde an Deiner Stelle auch interessieren, ob das Phänomen auf das Snom zurückzuführen ist oder auf das VPN ... denn direkt von der 7362SL aus funktioniert es ja und nach meinem Verständnis sind eben diese zwei Unbekannten im Moment noch im Spiel. Die Tatsache, daß das Snom mit der Box "kann" (internes Gespräch zwischen FON1 und dem Snom geht), muß für die externe Telefonie dort ja noch nicht unbedingt etwas bedeuten (s. "Umkodieren").

Auch ist mir der Software-Stand auf der 7362SL etwas rätselhaft ... gibt es dafür spezielle Gründe? Ich frage u.a., weil das von Dir beschriebene Phänomen in ähnlicher Form auch bei der 06.03 für die 6360 (auch wenn das eine DOCSIS-Box ist) auftrat. Dort lag es (meines Wissens) am falschen Routing des "voip/tr069"-Interfaces bei aufgebauter VPN-Verbindung und es ging natürlich um providerseitige SIP-Accounts ... das ist schon ein erheblicher Unterschied.

Aber gerade bei so unklarem Fehlerbild (solange Du nicht tracen kannst/willst, dann sollte ja zumindest zu sehen sein, von/nach wo da die RTP-Verbindung laufen soll und welche Codecs im Angebot sind und gewählt werden) würde ich auch mal mit aktueller Firmware (06.20 ist ja verfügbar, sogar eine Labor, oder?) testen, ob das Problem (von dem man ohne Trace ja nicht genau weiß, wo es liegt) nicht bereits behoben ist.
 

Zurzeit aktive Besucher

Keine Mitglieder online.

Statistik des Forums

Themen
246,085
Beiträge
2,245,799
Mitglieder
373,539
Neuestes Mitglied
Horst Fürst
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.