[Problem] Fritzbox 7490 OpenVPN server , stört SIP-Telefonie

Martin75

Neuer User
Mitglied seit
17 Okt 2010
Beiträge
26
Punkte für Reaktionen
1
Punkte
3
Hallo Forum,

ich betreibe eine 7490 mit Freetz und OpenVPN.

Kann mich übers 3G Netz zuhause per VPN einloggen und surfen oder NAS ansprechen, soweit fuktioniert alles.


Nur wenn ich mich mit dem Client einlogge, verliert die Fritzbox nach einigen Minuten die Regstrierung der Internetrufnummern (Telekom)

Erst wenn ich OpenVPN beende sind die Telefonnummern nach einigen Minuten wieder registriert.

Natürlich ist das so kein Zustand, denn immer wenn ich von Unterwegs das VPN nutze fallen zuhause die Telefone aus.

Irgendeine Idee dazu?

- - - Aktualisiert - - -

Im log der Fritzbox steht: Anmeldung der Internetrufnummer +49(Hier steht vorwahl und rufnummer) war nicht erfolgreich. Ursache: DNS-Fehler
 
Nur ins Blaue: Entweder das Routing passt nicht, so dass der Versuch, auf den DNS zuzugreifen "ins VPN" geht oder nutzt du im OpenVPN vielleicht "verbotene" IP-Adressen (z.B. aus dem Netz 192.168.180.0)?
 
Meine Glaskugel bleibt mangels INPUT dunkel.

Naja, die Glaskugeln sind auch nicht mehr das ....

Dabei ist OpenVPN so einfach einzurichten. Es gibt genügend Stoff im Netz.

TUN oder TAP?

Roadwarrior oder LAN2LAN?

IP ohne Routing wie es hier von einem Nutzer propagiert wurde?
 
Zuletzt bearbeitet:
Also die Fritzbox läuft auf 192.168.178.1 und alle PCs 192.168.178.x

Die VPN Adressen sind 192.168.200.1 (server) und der Client 192.168.200.2

jeweils 255.255.255.0 als Netmask.


VPN läuft mit static keys.

Ich habe mal alle route und push "route" zeilen aus den config dateien rausgenommen.

Einzige zeile was routingmässig eingreift ist ein redirect-gateway im client.

An portforwarding hab ich Port 443 auf 1194 der eigenen Fritzbox geroutet.

Selbes ergebnis.

Mir scheint als würde die fritzbox versuchen den sip server durch das vpn zu erreichen.

Während SIP ausgefallen ist bringt jedoch ein Ping tel.t-online.de auf den Pcs im lan und auf der fritzbox selbst ein positives Ergebniss.

als Nameserver wird 127.0.0.1 oder 127.0.1.1. benutzt (müsste ich nochmal nachschauen.)

Mich wundert dass niemand dasselbe Problem hat.

- - - Aktualisiert - - -

Nachtrag:
Hab eben ein Terminalprogramm auf dem Handy installiert:

Und hier funktioniert z.b. ping www.google.de korrekt.

Aber ein Ping www.t-online.de läuft ins Leere.

Anscheinend nutzt das Handy jetzt über VPN das Festnetzinternet (ist gewollt)

Allerdings scheint die Fritzbox nun über VPN das 3G netz vom Handy zu nutzen, weil hier kann tel.t-online.de nicht erreicht werden.

- - - Aktualisiert - - -

VPN läuft als TUN.

was ist roadwarrior oder lan2lan?
 
Warum nicht mal die Konfigurationen (Server/Client) rausrücken?

Routing Tabellen und der ganze Kram.

- - - Aktualisiert - - -

Roadwarrior und LAN2LAN sind übliche OpenVPN Szenarien die der Anwender kennen sollte.

-> Studium.
 
Zumindest dämmerte es mir, dass ich das schonmal gehört hatte.
"Der Einzige" mit dem Problem bist du nicht, ich musste nur länger suchen, bis ich den anderen Thread gefunden hatte ;-)

http://www.ip-phone-forum.de/showthread.php?t=275686

Dort steht am Ende eine interessante Anmerkung/Beobachtung, die auch dir vielleicht hilf. Der User hatte per rc.custom den voipd etwa eine Minute nach dem Start der Box neu gestartet und laut seiner Aussage trat das dann nicht mehr auf:
Code:
[COLOR=#333333](sleep 60; /bin/voipd -s && /bin/voipd) &[/COLOR]

 
Ja und? Das erklärt gar nichts.
 
Du hast den Thread durchgelesen und keine Erklärungen gefunden?!?
Ich hatte die Ergebnisse dort so verstanden: Sieht demnach stark danach aus, dass der voipd am "normalen" DNS vorbei seine Namensauflösung macht.
Auch die "Paket-Beschleunigung" (PA) könnte eine Ursache sein (zumindest sollte angeblich auch ein "echo disable > /proc/net/avm_pa/control" helfen).
Da das ganze (voipd und auch PA) closed source ist, weiß wohl nur AVM, was/warum da (nicht) geht.

In Summe kann ich mir durchaus vorstellen, dass ein Neustart eine Änderung/Verbesserung der Situation ergibt (hab aber selbst keine betroffene Box und kann das daher weder nachvollziehen noch testen).
 
Bei mir kann man mit einem Packetdump feststellen, daß der voipd tatsächlich seine eigenen DNS-Abfragen macht und damit wohl nicht auf den Resolver-Cache des multid zurückgreifen wird. Diese DNS-Abfragen erfolgen auch an den DNS-Server, der vom Provider zugewiesen wurde (an meinem DSL-Anschluß), obwohl in der Box ein DNS-Server im LAN konfiguriert ist.

Das läßt mich vermuten (nicht mit wissen verwechseln), daß der voipd diese DNS-Abfrage auf dem Interface absetzt, das er als zuständig für die Verbindung zum Registrar ansieht. In gewisser Weise würde das auch Sinn ergeben, denn es gibt bekanntermaßen FRITZ!Boxen, die mehrere logische Interfaces verwalten und da kann dann auch für solche Interfaces durchaus ein anderer DNS-Server zuständig sein. Es gibt ja einige Provider, die davon ausgiebig Gebrauch machen und die Namensauflösung für die SIP-Server ihrer Kunden nur in ihrem eigenen Netz richtig machen, bei externen Abfragen landet man dann in der Pampa.

Auch die Tatsache, daß AVM für solche DNS-Abfragen einen festen Port als Quelle verwendet (in der voip.cfg als "dnsport" konfiguriert) und daß es gesonderte QoS-Regeln genau für diesen Traffic (mit dem SIPDNS-Port als Absender) gibt, spricht für eine Sonderbehandlung, genauso wie die QoS-Chain, die sich hinter dieser Regel (aus der 7490) verbirgt:
Code:
root@FB7490:/var/media/ftp $ cat /proc/kdsld/nqos/lanset
lan:
  0: ip.proto 17 ip.tos 0xfc / 0x60 udp.dport 123 => 7
  0: ip.proto 6 ip.tos 0xfc / 0x60 tcp.dport 80 => 7
  0: ip.proto 17 => 8
  1:    ip.tos 0xfc / 0x60 udp.dport 43962 => 8
  1:    ip.tos 0xfc / 0x60 udp.dport 47806 => 8
  0: ip.proto 1 => 4
  0: ip.proto 58 => 4
  0: ip.proto 17 => 4
  1:    udp.dport 53 => 4
[COLOR="#FF0000"]  1:    udp.dport 5060 packetmatch *sip:*@tel.t-online.de* (sip) => 9[/COLOR]
  1:    udp.dport 5060 (sip) => 10
  0: => 12
Ich müßte das aber auch erst aufdröseln, welche Regeln jetzt genau für 9 als Ziel gelten:
Code:
root@FB7490:/var/media/ftp $ cat /proc/kdsld/nqos/results
results:
  0: queue 5
  1: queue 2 tos 184 vlan_prio 6
  2: queue 2 tos 0
  3: queue 2 tos 192
  4: queue 1 tos 0
  5: queue 0 tos 128 vlan_prio 4
  6: queue 0 tos 0 vlan_prio 0
  7: queue 1 tos 128
  8: queue 1 tos 96
[COLOR="#FF0000"]  9: queue 2 tos 192 appl sip[/COLOR]
 10: queue 2 tos 0 appl sip
 11: queue 6 tos 0
 12: queue 5 tos 0
Aber das könnte auch gut die Ursache sein, daß es irgendwie klemmt mit aktiviertem VPN, wobei das m.E. nur die zweite Wahl bei der möglichen Ursache wäre.

Ich würde in diesem Falle einfach darauf tippen, daß der voipd nach der Aktivierung des OpenVPN die falsche Bindung für das Interface wählt, das sollte man aber mit einem "showshringbuf sip" relativ leicht feststellen können:
Code:
root@FB7490:/var/media/ftp $ showshringbuf sip
2016-03-31 13:39:14.947 - IN: my=192.168.130.1%13:5060 peer=85.214.XXX.XXX port=5060 UDP, sipiface=none:
[...]
2016-03-31 13:39:14.952 - OUT: my=192.168.130.1%13:5060 peer=85.214.XXX.XXX port=5060 UDP, [COLOR="#FF0000"]sipiface=internet tcclass=sip_internet[/COLOR], netmark=0:
[...]
2016-03-31 13:41:14.993 - IN: my=192.168.130.1%13:5060 peer=85.214.XXX.XXX port=5060 UDP, sipiface=none:
[...]
2016-03-31 13:41:14.998 - OUT: my=192.168.130.1%13:5060 peer=85.214.XXX.XXX port=5060 UDP, [COLOR="#FF0000"]sipiface=voip tcclass=sip[/COLOR], netmark=0:
Sollte das am Ende das falsche Interface sein bzw. steht in der voip.cfg die Auswahl bei den SIP-Accounts auf "sipiface_automatic", würde ich es mal mit einer etwas gezielteren Festlegung probieren, z.B. "sipiface_internet". Mögliche Werte sind:
Code:
sipiface_automatic
sipiface_internet
sipiface_voip
sipiface_mta
sipiface_homenet
sipiface_vpn
sipiface_tunnel
, wobei der größte Teil davon eher an den DOCSIS-Anschlüssen der KNB von Interesse ist. Wenn dann die SIP-Accounts alle auf "sipiface_internet" stehen sollten und trotzdem nichts geht, wenn der OpenVPN-Tunnel aktiviert wurde, braucht es den Blick in einen Packetdump und in die Support-Daten (in erster Linie in die zum SIP, aber auch generell zur Interface-Konfiguration) und natürlich wirklich mal die OpenVPN-Konfiguration, weil da am Ende jede Kleinigkeit entscheidend sein kann.

Aber (s. die Spezialbehandlung für "tel.t-online.de" oben) es kann genauso gut sein, daß es ein generelles Problem ist, glaube ich aber eher nicht ... dafür gibt es zu viele Telekom-Kunden und zuviele Freetz-/OpenVPN-Benutzer, da muß es eine größere Schnittmenge geben und so viele Problembeschreibungen dazu haben wir nun auch wieder nicht in diesem Forum.
 
Zuletzt bearbeitet:
Habe nun folgendes ausprobiert:

Immer die Einstellungen von sipiface (showshringbuf sip | grep sipiface) kontrolliert, bei neustart, nach starten des OpenVPN, und nach einloggen vom client.
es blieb immer auf :
2016-03-31 21:34:11.993 - IN: my=192.168.178.1%14:5060 peer=217.0.23.70 port=5060 UDP, sipiface=none:
2016-03-31 21:34:16.629 - OUT: my=192.168.178.1%14:5060 peer=217.0.23.70 port=5060 UDP, sipiface=internet tcclass=sip_toi, netmark=0:

Box neugestartet:
Rufnummer abmelden / anmelden : geht

dann OpenVPN gestartet:
Rufnummer abmelden/anmelden: geht nicht mehr

dann voipd neugestartet
Rufnummer abmelden/anmelden: geht wieder


aber dafür konnte ich micht nicht mehr in OpenVPN einloggen (connection refused)

OpenVPN neugestartet, einloggen geht wieder
Rufnumer abmelden/anmelden geht immer noch
 
Wie alt ist denn die Firmware, in der es noch eine "tcclass" mit dem Namen "sip_toi" gibt?

Außerdem fehlt die Information, was nun in der voip.cfg steht (bei sipiface für die einzelnen Nummern) ... und auch der Packet-Dump wäre ja nicht ganz uninteressant - um welche DNS-Abfragen es sich handeln würde (also welchen DNS-Port eine FRITZ!Box am All-IP-Anschluß der Telekom für SIPDNS-Abfragen verwendet), steht ja auch in der voip.cfg (dachte ich bereits erwähnt zu haben).

Ferner die Routing-Tabelle mit und ohne aktivierte OpenVPN-Verbindung und die OpenVPN-Konfiguration, am besten sogar noch das OpenVPN-Log und die Ausgabe auf /dev/console, wenn die OpenVPN-Verbindung auf- oder abgebaut wird (da gibt der dsld und der multid schon noch einiges aus) ... das ist ja nicht nur reine Neugierde oder Beschäftigungstherapie, damit Du Ruhe gibst, wenn man danach fragt.

Weiterhin hast Du bei aller Systematik noch den Test vergessen, was denn mit der SIP-Registrierung passiert (die wird ohnehin regelmäßig erneuert, da würde ich gar keine weiteren Aktionen starten, die die Ab- oder Anmeldung einer Rufnummer betreffen, das verfälscht nur das Ergebnis, weil man nicht genau weiß, was dabei alles passiert), wenn Du eine OpenVPN-Verbindung aufbaust. Dann geht sie verloren, soviel habe ich schon begriffen ... aber was passiert jetzt, wenn die OpenVPN-Verbindung wieder abgebaut wird? Kann dann der SIP-Account ohne weitere Eingriffe wieder beim Registrar angemeldet werden (auch hier warten, bis es entweder klappt oder auch nicht, den Versuch siehst Du ja im Ringbuffer)?

Klappt das einwandfrei, ist es offenbar nur eine Frage des Routings der DNS-Abfragen (wenn es denn wirklich die ausbleibende Antwort auf eine SIPDNS-Abfrage ist, die erkennst Du in Deinem Packet-Dump ja am festen Absenderport bzw. die siehst Du auf "dev dsl" gar nicht, wenn die fälschlicherweise in den OpenVPN-Tunnel gehen, aber da kannst Du ja mit normalem "tcpdump" auch mitschneiden - weil das AVM-GUI wohl den TUN-Adapter nicht anbieten wird beim Paketmitschnitt).

Klappt das aber auch nach dem Abbau der OpenVPN-Verbindung nicht wieder automatisch, wird offenbar vom OpenVPN-Client irgendetwas dauerhaft verändert ... und genau dazu braucht es eben die Routing-Tabellen (als erste Verdächtige, das heißt noch lange nicht, daß es darin auch zu sehen sein muß) und OpenVPN-Protokoll/-Konfiguration.
 
Uh dazu kenn ich mich noch zuuuu wenig aus...
wenn du mir sagt welche befehle ich eigenben soll, helfe ich gerne..


Ich habe nun rc.custom laut dem Hinweis in dem anderen Thread modifiziert..
(voipd nach 60s neustarten)

und es scheint zu funktionieren...
selbst wenn ich openvpn erst manuell danach starte... das kapiere wer will...

Aktuell:
Box startet neu, nach 60 sekunden startet voipd neu.

Ein paar minuten später starte ich dann Openvpn manuell.

Und seither klappt es.. habe einige male die Sip ab und angemeldet, die Box neu verbinden lassen und nochmal sip an und abgemeldet.
Das ganze mit und ohne verbundenen VPN-Client.

Was mir jetzt noch einfällt: wird das tun device beim starten erzeigt auch wenn openvpn aus ist?


Hoffe es klappt nun.. bin aber gerne für weitere Tests bereit.



Achja zur Firmware: 6.55 Labor


VOIP.cfg:
Ich gehe per telnet auf die Box dann /var/flash
und ein nano voip.cfg zeigt nur eine leere Datei an.

PS: Alle Dateinamen sind bei ls rosa... was bedeutet das ?

EDIT:
mit cat geht es

sipiface=sipiface_automatic
und drüber noch : route always over internet = yes
 
Zuletzt bearbeitet:
Habe nun diese eine Zeile bei rc.custom eingetragen, mit der voipd nach 60 sekunden neu gestartet wird... und seitdem keine Probleme mehr.

Es ist egal ob openvpn beim start läuft oder erst später manuell gestartet wird.
Auch kann ich openvpn beliebig deaktivieren und aktivieren oder dass die VOIP-Nummern gestört werden.

Danke nochmal für den Tip.
 
Moinsen


Vorsicht

/var/flash = Ordner für Zeichenorientierte Gerätedateien
Zum Editieren gibt es das Wrapperskript: /usr/bin/nvi

cat /usr/bin/nvi
Code:
#! /bin/sh
if [ -z "$1" ] ; then
        echo "use: $0 <config-filename>"
        exit 1
fi
cat $1 >/var/nvi.tmp && vi /var/nvi.tmp && cat /var/nvi.tmp >$1
rm -f  /var/nvi.tmp
...also warst du mit cat schonmal sehr nah dran.
:rolleyes:
 
Zuletzt bearbeitet:
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.