Keine Verbindung (Sipgate+BT100+SUSE 9.3 Router+IPTables)

DirkHX

Neuer User
Mitglied seit
5 Mai 2005
Beiträge
10
Punkte für Reaktionen
0
Punkte
0
Hallo!

Seit gestern bin ich etwas am verzweifeln. Ich versuche mein BT100 (bzw. BT101) in unserem Netzwerk zu aktivieren. Einmal habe ich es geschafft, jedoch wollte es nach der DSL-Zwangstrennung dann nicht mehr. Keine Ahnung, woran das liegt... Hier zu meiner Konfiguration (anschließend zur Beschreibung):

SIP-Anbieter: sipgate.de

DSL: Tiscali DSL1000

Linux-Router (SUSE 9.3) mit IP-Tables:
* Interne IP 192.168.2.1
* Portweiterleitung: 5004-5007 und 5060 (tcp+udp) auf die IP des Telefons (192.168.2.80)

IP-Telefon Grandstream BT 100
* Product Model: BT100
* Software Version: Program-- 1.0.5.23 Bootloader-- 1.0.0.21 HTML-- 1.0.0.47 VOC-- 1.0.0.7
* IP über DHCP (immer 192.168.2.80)
* Router 192.168.2.1
* DNS-Server (192.168.2.1 und 62.27.27.62=DNS Tiscali)
* SIP Server: sipgate.de
* Outbound Proxy: (leer)
* Vocoder: PCMA, PCMU, G729, G723, ... (wie bei sipgate beschrieben)
* G723 rate: 6.3
* iLBC frame size: 20ms
* iLBC payload type: 101
* Silence Suppression: [X] No
* Voice Frames per TX: 2
* Layer 3 QoS: 8
* Layer 2 QoS: 0 / 0
* Use DNS SRV: [X] No
* User ID is phone number: [X] No
* SIP Registration: [X] Yes
* Unregister On Reboot: [X] No
* Register Expiration: 60
* Early Dial: [X] No
* Dial Plan Prefix: (leer)
* No Key Entry Timeout: 4
* Use # as Dial Key: [x] Yes
* local SIP port: 5060
* local RTP port: 5004
* Use random port: [x] No
* NAT Traversal: [x] Yes + STUN-Server = (leer)
* keep-alive interval:14
* Use NAT IP: 192.168.2.80
* Proxy-Require: (leer)
* Firmware Upgrade: Via TFTP Server 0.0.0.0
* Voice Mail UserID: (leer)
* SUBSCRIBE for MWI: [x] No
* Auto Answer: [x] No
* Offhook Auto-Dial: (leer)
* Enable Call Features: [x] No
* Disable Call-Waiting: [x] No
* Send DTMF: [x] via SIP INFO
* DTMF Payload Type: 101
* Send Flash Event: [x] No
* NTP Server: ntp.sipgate.net
* Default Ring Tone: [x] system ring tone
* Send Anonymous: [x] No
* Lock keypad update: [x] No

Soviel zu den technischen Daten.

Das Problem: Trotz eigentlich korrekter Angaben kann das Telefon anscheinend keine Verbindung zum Sipgate-Server aufbauen. Das Symbol oben links bleibt immer aus und man hörte auch kein Freizeichen.

Nach dem Lesen von zig Beiträgen in diesem Forum habe ich auch einiges ausprobiert:

* Stun-Server eintragen und nicht eintragen (inkl. NAT Traversal auf Yes und auf No stellen)
* "Use NAT-IP" mal mit und mal ohne Inhalt.

Das alles hat nicht geholfen.

Neuer Versuch - "Anderer Provider": ich habe bei nikotel.de ein Konto eingerichtet und wollte es mal so ausprobieren. Konfig wie im Nikotel-FAQ "Grandstream SIP Telefon: Wie konfiguriere ich mein Nikotel SIP Telefon?" beschrieben.... Und? Es funktionierte sofort! Verbindungslämpchen leuchtete und ich hatte auch ein Freizeichen. Das wollte mir nun gar nicht einleuchten!

Nächster Versuch - "wieder zurück zu sipgate": Sipgate-Daten erneut eingegeben und dann fuktionierte es plötzlich auch dort. Auch 2 Testanrufe waren 100%ig... (Konfig zu dem Zeitpunkt: NAT Traversal auf Yes + STUN-Server leer + NAT IP mit lokaler IP-Adresse)

Aber jetzt, nachdem heute Mittag die DSL-Zwangstrennung stattfand, will Sipgate wieder nicht mehr. Zuerst habe ich nur das Gerät resettet und anschließend habe Ich wieder alle möglichen Einstellungen ausprobiert. Die Firewall-Konfig nochmal geprüft... Aber das BT100 will keine Verbindung aufbauen und auch das Freizeichen ist nicht zu hören.

Da muss irgendeine Kleinigkeit falsch sein und ich habe keine Ahnung was!

Ursprünglich wollte ich sogar zwei BT100 bei uns im Netz laufen lassen (demnächst bekommen wir dafür eine schnellere Leitung). Aber bei den aktuellen Problemen kann ich mir das wohl erstmal abschminken!

Wenn jemand einen Rat weiss, wäre ich sehr dankbar :)

Danke schon jetzt + Gruss,
Dirk
 
Hast Du denn den Port 10000 in Deiner Firewall freigegeben ? Den braucht das Telefon für den STUN Server.

Ich würde Dir empfehlen, einfach mal mit ausgeschalteter Firewall zu testen, ob das Telefon dann funktioniert - und schon hast Du die Fehlerursache eingegrenzt.
 
betateilchen schrieb:
Hast Du denn den Port 10000 in Deiner Firewall freigegeben ? Den braucht das Telefon für den STUN Server.

Ich würde Dir empfehlen, einfach mal mit ausgeschalteter Firewall zu testen, ob das Telefon dann funktioniert - und schon hast Du die Fehlerursache eingegrenzt.

Vielen Dank für den Tipp! Ein kurzer erster Test war leider nicht erfolgreich. Aber ich werd nachher mal kurz einen anderen Router ausprobieren... Ich vermute nämlich im Moment auch ganz stark, dass meine Firewall-Einstellungen nicht ganz ok sind. Melde mich nachher nochmal....

Gruss, Dirk
 
Hallo!

Meine Tests habe ich am Wochenende fortgesetzt und habe festgestellt, dass es eigentlich nur an der Firewall liegen kann. Ich habe statt des Linux-PCs einen CNet-DSL-Router eingesetzt und dort lief es mit einer Weiterleitung von Port 5004 und 5060 sofort und ohne Probleme. STUN war nicht notwendig. Selbst das zweite BT100 auf Port 5005 und 5061 funktionierte auf Anhieb.

Die gleiche Telefon-Konfig (mit geänderter DNS- und Gateway-Adresse) funktionierte dann aber mit dem Linux-PC nicht mehr.

Gestern habe ich den halben Tag nach Infos gesucht, was an meinem Firewall-Script falsch sein könnte. Hier der letzte Stand meines Testscripts:
("dslo" ist der externe Adapater, "eth1" der interne.)

Code:
#!/bin/sh

# Alte Firewallregeln loeschen
iptables -F
iptables -X
iptables -F
iptables -t nat -F

# IP Forwarding aktivieren
echo "1" > /proc/sys/net/ipv4/ip_forward

# Das Modul für Network Addrestranslation (NAT) bzw: Masquerading
# laden und Masquerading einschalten.
modprobe iptable_nat
iptables -t nat -A POSTROUTING -o dsl0 -j MASQUERADE

# MTU Paketgroesse wir fuer routing anpassen
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Enfache Firewallregeln zur Blockade eingehender Verbindungen
iptables -A INPUT -i dsl0 -m state --state NEW,INVALID -j DROP
iptables -A FORWARD -i dsl0 -m state --state NEW,INVALID -j DROP

# Firewallregeln fuer SSH zulassen
iptables -I INPUT -i dsl0 -p tcp --dport 22 -j ACCEPT
iptables -I INPUT -i dsl0 -p tcp --sport 22 -j ACCEPT

# Weiterleitung der Ports 5004 & 5060 auf 192.168.2.80 (IPTel)
iptables -I FORWARD -i dsl0 -p tcp --dport 5060 -j ACCEPT
iptables -I FORWARD -i dsl0 -p tcp --sport 5060 -j ACCEPT
        iptables -t nat -I PREROUTING -i dsl0 -p tcp --dport 5060 -j DNAT --to 192.168.2.80
        iptables -t nat -I PREROUTING -i dsl0 -p tcp --sport 5060 -j DNAT --to 192.168.2.80
iptables -I FORWARD -i dsl0 -p tcp --dport 5004 -j ACCEPT
iptables -I FORWARD -i dsl0 -p tcp --sport 5004 -j ACCEPT
        iptables -t nat -I PREROUTING -i dsl0 -p tcp --dport 5004 -j DNAT --to 192.168.2.80
        iptables -t nat -I PREROUTING -i dsl0 -p tcp --sport 5004 -j DNAT --to 192.168.2.80
iptables -I FORWARD -i dsl0 -p udp --dport 5060 -j ACCEPT
iptables -I FORWARD -i dsl0 -p udp --sport 5060 -j ACCEPT
        iptables -t nat -I PREROUTING -i dsl0 -p udp --dport 5060 -j DNAT --to 192.168.2.80
        iptables -t nat -I PREROUTING -i dsl0 -p udp --sport 5060 -j DNAT --to 192.168.2.80
iptables -I FORWARD -i dsl0 -p udp --dport 5004 -j ACCEPT
iptables -I FORWARD -i dsl0 -p udp --sport 5004 -j ACCEPT
        iptables -t nat -I PREROUTING -i dsl0 -p udp --dport 5004 -j DNAT --to 192.168.2.80
        iptables -t nat -I PREROUTING -i dsl0 -p udp --sport 5004 -j DNAT --to 192.168.2.80

Und weil ich absolut nicht weiter wusste, habe ich mit "tcpdump" eine seltsame Beobachtung gemacht (tcpdump -n -i eth1 | grep 192.168.2.8):

Code:
19:14:41.398582 arp who-has 192.168.2.1 tell 192.168.2.80
19:14:41.401270 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 452
19:14:41.401301 IP 192.168.2.1.5060 > 192.168.2.80.5060: UDP, length: 452
19:14:41.401328 arp who-has 192.168.2.1 tell 192.168.2.80
19:14:41.405185 IP 192.168.2.80.5060 > 192.168.2.80.5060: UDP, length: 333
19:14:41.405196 IP 192.168.2.1.2215 > 192.168.2.80.5060: UDP, length: 333
19:14:46.404135 arp who-has 192.168.2.80 tell 192.168.2.1
19:14:46.433845 arp who-has 192.168.2.1 (ff:ff:ff:ff:ff:ff) tell 192.168.2.80
19:14:48.113933 arp who-has 192.168.2.1 tell 192.168.2.80
19:14:48.114814 arp who-has 192.168.2.1 tell 192.168.2.80
19:14:48.114971 arp who-has 192.168.2.1 tell 192.168.2.80
19:14:48.115039 arp who-has 192.168.2.1 tell 192.168.2.80
19:14:50.602245 IP 192.168.2.80.26789 > 192.168.2.1.53:  30343+ A? sipgate.de. (28)
19:14:50.865710 IP 192.168.2.1.53 > 192.168.2.80.26789:  30343 1/13/0 A 217.10.79.9 (255)
19:14:53.104903 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 450
19:14:53.104943 IP 192.168.2.1.5060 > 192.168.2.80.5060: UDP, length: 450
19:14:53.108807 IP 192.168.2.80.5060 > 192.168.2.80.5060: UDP, length: 331
19:14:53.108816 IP 192.168.2.1.2215 > 192.168.2.80.5060: UDP, length: 331
19:14:55.864697 arp who-has 192.168.2.80 tell 192.168.2.1
19:14:55.864906 arp reply 192.168.2.80 is-at 00:0b:82:01:5d:15
19:14:58.102025 IP 192.168.2.80.26789 > 192.168.2.1.53:  30346+ A? time.nist.gov. (31)
19:14:58.621658 IP 192.168.2.1.53 > 192.168.2.80.26789:  30346 1/13/0 A 192.43.244.18 (258)

Am meisten hat mich dieser Ausschnitt verwundert:

IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 450
IP 192.168.2.1.5060 > 192.168.2.80.5060: UDP, length: 450

Hier wird ein UDP-Paket an Sipgate.de gesendet und die Antwort kommt vom Router (statt von sipgate.de) wieder zurück. In einem anderen Netzwerk (in dem das alles funktioniert) kommt die Antwort von sipgate.de zurück. Also in etwa so:

IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 450
IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 450

Meine Vermutung ist im Moment, dass meine Firewall die UDP-Pakete vom Telefon direkt wieder zurück ans Telefon schickt. Nur warum?

Es wäre toll, wenn jemand eine Idee hätte und mir helfen könnte :)

Gruss & schon jetzt vielen Dank,
Dirk

PS: Oder sollte ich danach lieber im Bereich "Software-Router" fragen?
 
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.