[Problem] kein Voip über openvpn seit Labor.84.05.29-24099 und höher

[vice_pres]

Also hab für die 7390 mal einen Replace Kernel gemacht ohne weitere Anpassungen (in der Hoffnung, dass es irgendwas an der AVM Kernel Config ist - was auch immer) - aber... Kein Erfolg.

Also weiterhin keine Ahnung. Problem mit dem AVM Support:
Nicht unterstützte Änderungen etc...

 

[vice_pres]

Gibt es eigentlich eine Möglichkeit (ohne iptables) ein Portforwarding zu machen auf der Box? Ich hatte vor gefühlten Ewigkeiten mal auf ner alten Debian Büchse, aber mir fällt partou nicht mehr ein wie das Teil hieß... Wobei das aber glaub ich nur für TCP ging

Gibts denn schon ein Paket derzeit das sowas könnte?

Edith sagt: Bei mir gehts jetzt wieder

Hätte ich socat nicht unter den remove patches entfernen lassen wärs ja sogar schon drauf gewesen

das hier in die rc.custom auf der Box die die Nummer registrieren will
socat udp4-listen:4444,bind=<IP-DER-LOKALEN-BOX> udp4-connect:<IP-DER-ENTFERNTEN-BOX>:5060 & > /dev/null 2>&1

Bei der Rufnummer dann als Proxy <IP-DER-LOKALEN-BOX>:4444 eintragen und fertig.

Wichtig:
Auf der Entfernten Box muss für die Rufnummer die Anmeldung aus dem Internet erlaubt sein. Das hat den unschönen Nebeneffekt, dass die Box dann tatsächlich aus dem Internet SIP-Anmeldungen annehmen würde. Das hab ich mit AVM-Firewall dann unterbunden


Edith II sagt:
Ich habe damit noch nicht probiert zu telefonieren (da ich nicht zuhause bin derzeit) - anrufe gehen aber scheinbar raus, ich konnte per Fritz App über die Telefonnummer auf meinem zweiten Handy anrufen. Konnte aber nicht rangehen, da in dem Moment der Akku leer war...

Edith III sagt:
Telefonat wird aufgebaut, aber keine Sprachdaten werden übertragen... Da fehlen scheinbar noch ein paar Ports (ich hatte die Hoffnung, dass das richtig funktioniert und nur die Registrierung hing vorher) - jetzt wirds natürlich schwierig was die Ports angeht

Edith IV sagt:
Also ich hab jetzt zumindest rausgefunden was mit den Paketen passiert die nicht in den Tunnel gehen... Die gehen auf dem Interface dsl raus! Schlauer bin ich aber nur bedingt dadurch... Denn das passiert auch nur wenn ich eine andere LAN-IP als Proxy eintrage, ansonsten konnte ich die Pakete bisher noch nirgendwo finden...

 

[vice_pres]

Ich raffe es nicht...

root@fritz:/var/mod/root# tcpdump -i dsl -n -vvv | grep 192.168.33.33
tcpdump: listening on dsl, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    192.168.3.254.5060 > 192.168.33.33.5060: [udp sum ok] SIP, length: 609
        Route: <sip:192.168.33.33;lr>
    192.168.3.254.5060 > 192.168.33.33.5060: [udp sum ok] SIP, length: 609
        Route: <sip:192.168.33.33;lr>
    192.168.3.254.5060 > 192.168.33.33.5060: [udp sum ok] SIP, length: 609
        Route: <sip:192.168.33.33;lr>

Wie zu sehen geht das über dsl raus...

route -n sagt aber:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
10.7.0.18       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.7.0.1        10.7.0.18       255.255.255.255 UGH   0      0        0 tun0
79.224.36.93    0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.0.131   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.179.0   0.0.0.0         255.255.255.0   U     0      0        0 guest
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.33.0    10.7.0.18       255.255.255.0   UG    0      0        0 tun0
10.7.0.0        10.7.0.18       255.255.255.0   UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U     2      0        0 dsl

Traceroute klappt ja auch ohne Probleme - sowohl von der Box aus als auch von einem client. Nur die Voip Pakete laufen falsch...

 

[axleu]

Hallo vice_pres und VOIP over VPN-Leidensgenossen,

im Nachbar-Thread kommt man inzwischen auch unter der FW5.50 von außen mittels Fritz-VPN via SIP auf die Box. Gespräche können auch geführt werden!
http://www.ip-phone-forum.de/showthread.php?t=255477&

Das Abbruchproblem nach 30 sec. kann ich auch beim Zugang mittels Freetz-Openvpn bestätigen.

Gruß
Axleu

 

[vice_pres]

Naja - das war ja kein Hexenwerk, so weit war ich auch schon - Telefonieren über FRITZBOX vpn ist ja auch nicht weiter schwierig - es geht hier aber um Openvpn, und da laufen die Pakete wie oben gesehen definitiv übers falsche Interface raus...

Ihr solltet aber bedenken, dass dann der Voip Port nach aussen offen ist von der Box. Setz dich mal an nen anderen Rechner und mach mal nen Telnet auf deine öffentliche IP auf Port 5060. Das hab ich dann mit der avm-firewall wieder zugemacht, denn der Haken "Anmeldung aus dem Internet erlauben" sorgt dafür, dass auf dem Port fleissig auf Anmeldeversuche reagiert wird.

Edit:
Und soweit ich deinen Hinweis deuten kann sieht es ja so aus, als ob du dich als Client auf die Box als Server verbindest. Hier gehts imho aber um getrennte Netze die geroutet werden

 

[elmo4410]

Kurzer Hinweis - vielleicht hilft das noch zusätzlich den SIP-Bug der 74.05.50 zu verstehen.
Wenn ich mich über PhonerLite und den Fritz-VPN anmelde, wie schon gesagt, dann kann man telefonieren (PhonerLite --> FritzVPN --> FritzBox OK)
Aber seit dem Update auf x.05.50 ist ein angerufen werden (also andere Richtung) nicht mehr möglich. Die Box leitet das SIP-Protokoll nicht mehr zurück zu PhonerLite.

 

[vice_pres]

Wenn du tcpdump auf der Box hättest dann dürftest du da das gleiche sehen wie ich auch hier in Beitrag 23 gepostet hab: Die Pakete dürften auf dem falschen Interface (dsl) rausgehen statt zum VPN Client, daher kommen die da nicht an.

 

[elmo4410]

Könnte man die denn nicht über das dsl-Interface "abfangen"? Also VPN rein und DSL raus? Geht das?

 

[vice_pres]

Ich hab keine Box mehr die nicht auf 5.50 läuft, mir ist aber eben was aufgefallen auf einer 5.50er Box und ich weiß nicht ob das vorher auch schon so war:

dsl       Link encap:Point-to-Point Protocol
          inet addr:192.168.3.254  P-t-P:192.168.3.254  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:24434 errors:0 dropped:0 overruns:0 frame:0
          TX packets:145752 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:3064469 (2.9 MiB)  TX bytes:27169224 (25.9 MiB)

Das dsl interface hat ja auch die IP-Adresse vom LAN - laufen die Pakete daher vielleicht falsch? Aber dummerweise auch nur genau die VOIP Pakete, bisher ist mir noch nix anderes aufgefallen...

 

[boxbenutzer]

Gibt es hier schon Neuigkeiten? Ich stecke an exakt identischer Stelle fest: socat ermöglicht mir zumindest eine Registrierung, ich kann also rauswählen und beim Empfänger klingelt es.
Ich höre aber keinen Ton, ebenso gehen keine Gespräche rein.

 

[vice_pres]

Leider nein,

Ich hab letzte Woche ne Mail von AVM bekommen nochmal als Nachfrage wie genau die Situation ist (hatte vorher schon drauf hingewiesen, dass die Box gefreezt ist und das openvpn direkt auf der Box läuft) - aber ich rechne nicht wirklich damit, dass da was passiert.

Gruß
Peter

 

[boxbenutzer]

Mein Problem ist, dass die Pakete anscheinend wirklich im Nirwana verschwinden.

Das Szenario:

FB mit OpenVPN-Client <-> Router mit OpenVPN-Server <-> Internet <-> Router im Ausland <-> Asterisk mit OpenVPN-Client

FB kann den Server mit Asterisk einwandfrei über das VPN pingen etc., also das läuft definitiv sauber.
Die FB hat allerdings, da sie hier im lokalen LAN steht, gar kein dsl-Interface, d.h. tcpdump zeigt mir keine Pakete an, die falsch rausgehen. Ideen, wo ich noch suchen kann?
Ein Smartphone mit SIP-Client und OpenVPN-Client kann sich (verbunden im lokalen WLAN hier) zum Asterisk übers VPN verbinden und auch telefonieren.

 

[vice_pres]

Macht die Fritzbox NAT oder hängt die einfach nur im Netz?

 

[elmo4410]

Als interime Lösung hatte ich darüber nachgedacht mich mit meiner FB7113 via dem nun offenen SIP der FB7270 einfach anzumelden. Auch wenn es erstmal nicht die sicherste Variante ist.
Über PhonerLite geht das prima, aber auch nur, weil man unter domain/realm: "fritz.box" eintragen kann.
Nun die Frage: Unter Internetrufnummern bzw. Eigene Rufnummern --> Anderer Anbieter gibt es leider kein domain/realm Eintrag. Der ist aber notwendig um sich bei der anderen Box anzumelden.
Gibt es hier eine Möglichkeit die realm-Information in die Rufnummeranmeldung einzubringen, den Eintrag realm noch hinzuzufügen, oder sowas über eine Kombination bei Benutzernamen? (realmname@benutzername...???)

 

[vice_pres]

Also wenn die Fritzbox den Openvpn tunnel nicht selber aufbaut und kein NAT macht für daran angeschlossene Clients sollte es eigentlich keine Probleme geben (sei es nun eine andere Fritzbox davor die die Verbindung aufbaut, ein Linux-Router o.ä.)

Leider ist das quasi nie der Fall

 

[elmo4410]

Ja Genau - das Problem ist nur. Über ne VPN Verbindung ist kein domain/realm Eintrag notwendig. Da funktioniert die Nummer-Registerierung ganz normal ohne realm. Aber ohne VPN - mit der neunen offenen SIP will die FB7270 mit x.5.50 einen realm-Eintrag haben, sonst wird die Anmeldung nicht akzeptiert. Aber leider gibt es bei der FB7113 keinen realm-Eintrag in der "Rufnummern-Anmeldung" unter "Andere Anbieter". Nun die Frage wie kann man die realm-Information mit senden, damit die Anmeldung gelingt?

 

[vice_pres]

Hab gerade mal die aktuelle Labor Version gebaut - Verhalten bleibt leider ganz

root@fritz:/var/mod/root# tcpdump -i dsl -n -vvv | grep 192.168.33.33
tcpdump: listening on dsl, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    192.168.3.254.5060 > 192.168.33.33.5060: [udp sum ok] SIP, length: 579
        REGISTER sip:192.168.33.33 SIP/2.0
        From: <sip:[email protected]>;tag=946672804
        To: <sip:[email protected]>
    192.168.3.254.5060 > 192.168.33.33.5060: [udp sum ok] SIP, length: 579
        REGISTER sip:192.168.33.33 SIP/2.0
        From: <sip:[email protected]>;tag=946672804
        To: <sip:[email protected]>
    192.168.3.254.5060 > 192.168.33.33.5060: [udp sum ok] SIP, length: 579
        REGISTER sip:192.168.33.33 SIP/2.0
        From: <sip:[email protected]>;tag=946672804
        To: <sip:[email protected]>
    192.168.3.254.5060 > 192.168.33.33.5060: [udp sum ok] SIP, length: 579
        REGISTER sip:192.168.33.33 SIP/2.0
        From: <sip:[email protected]>;tag=946672804
        To: <sip:[email protected]>

 

[MaxMuster]

Meine Vermutung ist: Alles, was nicht "LAN" ist, schickt die Box über DSL raus.
Also, ich vermute mal es ginge, wenn du in der OpenVPN-Config TAP nutzt, was natürlich alle "Schwierigkeiten" des Bridgings mit sich bringt.

Vielleicht könntest du mal einen "Trick" versuchen?!?
Für die TCP-Dump Config (VPN ist 192.168.33.0):

# eine freie IP aus dem VPN-Netz auf lan
ifconfig lan:2 192.168.33.254 
# ... und schnell das Routing wieder wegnehmen
route del -net 192.168.33.0/24 dev lan


# ... und falls das nicht reicht, mit "schlechterer Metric" wieder hinzu
route add -net 192.168.33.0/24 dev lan metric 200

Geht es dann durchs tun-interface?!?

 

[vice_pres]

Hat leider nichts gebracht - zumal ja auch nicht aller Traffic über DSL rausgeschickt wird. Ich mache von der Box aus z.B. FTP auf einen Host in dem anderen Netz (zum ablegen der automatischen Backups nachts), Ping von der Box aus geht, etc... pp

Das einzige was nicht passt ist der blöde SIP traffic...

 

[MaxMuster]

Es scheint für VoIP ja nicht per "normalem Routing" zu laufen, also war meine Vermutung, dass sich der SIP-Registrar irgendwo die Info "holen" muss, was denn "sein LAN" ist.
Hast du denn "per Internet" für diesen SIP-Eintrag aktiviert?