iptables - SUSE 9.3: Keine Verbindung beim BT100

DirkHX

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

Ich habe ein Problem mit meinem Grandstream BT100, meinem Linux-SUSE-Router und sipgate. Ich habe diesen Thread schon im Grandstream-Bereich begonnen. Da das Problem jedoch nicht das BT100 sondern anscheinend mein Firewall-Skript für IPTables unter SUSE 9.3 ist, poste ich meine Anfrage etwas modifiziert noch einmal hier!

Irgendetwas scheint an meinem Firewall-Script nicht zu stimmen, denn das BT100 kann keine Verbindung zu sipgate aufbauen. Hier die Details dazu:

Linux-SUSE-9.3-Router auf IP 192.168.2.1 (dsl0 = extern, eth1 = intern).
BT100-IPTelefon auf IP 192.168.2.80.

Ich benutze testweise das folgende Skript zum Einstellen von IPTables:

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

So eingestellt will mein BT100 keine Verbindung zu sipgate.de aufbauen. Ich habe schon Stunden bei google.de, hier im Forum und mit verschiedensten HOW-TOs und sonstigen Anleitungen wie "man iptables" verbracht. Leider habe ich keine Idee, warum es nicht funktionieren will.

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 :) Hat jemand eine Idee, was an dem Skript falsch ist? Oder weiss jemand wieso es nicht funktioniert? Oder hat jemand ein Beispiel-Script, mit dem das BT100 mit Sipgate funktioniert?

Gruss & schon jetzt vielen Dank,
Dirk

PS: Meinen ursprünglichen Beitrag bezüglich des Grandstream findet ihr hier. Dort sind auch Details zu den weiteren Einstellungen zu finden.
 
hmmm - uch würde sagen, eigentlich müsste es funktionieren :)

Allerdings hast Du einige Überflüssiges drin, was die Firewall evtl. irritiert.
1. Die TCP-Port werden alle nicht gebraucht für SIP.

2. die --sport-Zeilen sind für SIP alle Überflüssig.

3. versuch die Weiterleitung mal unabhängig vom Interface zu machen, z.B. so:
iptables -t nat -I PREROUTING -s ! 192.168.0.0/16 -p udp --destination-port 5060 -j DNAT --to-destination 192.168.2.80:5060

4. RTP braucht immer 2 direkt aufeinander folgende Ports. Die Ports werden ausgehandelt wzischen den Clients. Ich weiß nicht, welche das beim BT sind, wenn es 5004 ist, dann musst Du die UDP-Ports 5004 und 5005 weiterleiten.

Außerdem sieht das ARP-Zeugs etwas seltsam aus. Es gibt etwas wenige Antworten auf die ARP-Anfragen. Ich habe keine Ahnung, woran das liegen könnte. (evtl. mal den Switch neustarten.)

Gruß,
Pfeffer.
 
Hi Pfeffer!

Danke für deine Tipps! Ich habe mich heute morgen extrem gewundert, weil plötzlich das Telefon eine Verbindung angezeigt hat.... Keine Ahnung warum. Trotzdem habe ich deine Hinweise umgesetzt:

zu 1: TCP-Ports sind raus.
zu 2: --sport-Zeilen sind raus.
zu 3: Weiterleitung ist jetzt Interface-unabhängig.
zu 4: Beim BT100 kann man jeweils nur einen SIP- und RTP-Port angeben. Meinst Du, dass das Telefon trotzdem 2 RTP-Ports benötigt? Ich habe in dem Script einfach noch ein paar RTP-Ports eingefügt. Stören sollte es ja nicht.

Zum ARP kann ich nicht viel sagen - ich bin nicht so der Profi auf dem Gebiet.

Jetzt habe ich ein neues kleines Problem: Das BT100 meldet ein 482 ("Loopback detected"). Telefonieren funktioniert trotzdem, aber der Ton kommt "abgehackt" rüber. Das hört sich so an als ob irgendwie Pakete verloren gehen.

Hier zur Info mein neuer Firewall-Skript-Ausschnitt:

Code:
#                                                       
# *** iptel1 ***
#
iptables -t nat -I PREROUTING -s ! 192.168.2.0/16 -p udp --dport 5060      -j DNAT --to-destination 192.168.2.80:5060
iptables        -I FORWARD    -i dsl0             -p udp --dport 5060      -j ACCEPT
iptables -t nat -I PREROUTING -s ! 192.168.2.0/16 -p udp --dport 5004      -j DNAT --to-destination 192.168.2.80:5004
iptables -t nat -I PREROUTING -s ! 192.168.2.0/16 -p udp --dport 5005      -j DNAT --to-destination 192.168.2.80:5005
iptables -t nat -I PREROUTING -s ! 192.168.2.0/16 -p udp --dport 5006      -j DNAT --to-destination 192.168.2.80:5006
iptables -t nat -I PREROUTING -s ! 192.168.2.0/16 -p udp --dport 5007      -j DNAT --to-destination 192.168.2.80:5007
iptables        -I FORWARD    -i dsl0             -p udp --dport 5004:5007 -j ACCEPT

Und hier noch ein tcpdump-Mitschnitt:

Code:
10:07:42.780018 arp who-has 192.168.2.1 (ff:ff:ff:ff:ff:ff) tell 192.168.2.80
10:07:44.460075 arp who-has 192.168.2.1 tell 192.168.2.80
10:07:44.461043 arp who-has 192.168.2.1 tell 192.168.2.80
10:07:44.461124 arp who-has 192.168.2.1 tell 192.168.2.80
10:07:44.461453 arp who-has 192.168.2.1 tell 192.168.2.80
10:07:45.481460 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 4
10:07:46.948420 IP 192.168.2.80.26789 > 192.168.2.1.53:  32064+ A? sipgate.de. (28)
10:07:46.948817 IP 192.168.2.1.53 > 192.168.2.80.26789:  32064 1/6/0 A 217.10.79.9 (150)
10:07:49.450890 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 422
10:07:49.553999 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 624
10:07:49.573300 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 616
10:07:49.686568 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 519
10:07:49.944966 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 644
10:07:50.058567 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 582
10:07:50.480118 arp who-has 192.168.2.80 tell 192.168.2.1
10:07:50.480326 arp reply 192.168.2.80 is-at 00:0b:82:01:5d:15
10:07:54.458191 IP 192.168.2.80.26789 > 192.168.2.1.53:  32068+ A? time.nist.gov. (31)
10:07:54.458569 IP 192.168.2.1.53 > 192.168.2.80.26789:  32068 1/13/0 A 192.43.244.18 (258)
10:07:59.458056 IP 192.168.2.80.9876 > 192.43.244.18.123: NTPv4 client, strat 0, poll 4, prec -6
10:07:59.687564 IP 192.43.244.18.123 > 192.168.2.80.9876: NTPv4 server, strat 1, poll 4, prec -18
10:08:01.261148 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 4
10:08:04.057759 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 4
10:08:16.892817 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 4
10:08:18.057310 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 4
10:08:32.056855 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 4
10:08:32.744951 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 4

Jetzt aber nochmal zu dem "482 - Loopback detected": Seltsamerweise sendet sipgate die Sprachdaten an den Port 5006, obwohl in der Konfig des BT100 eindeutig 5004 steht:

local SIP port: 5060 (default 5060)
local RTP port: 5004 (1024-65535, default 5004)

Hier der Mitschnitt aus tcpdump:

Code:
10:46:03.035415 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 533
10:46:03.041055 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 599
10:46:03.104524 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 854
10:46:03.106216 IP 217.10.79.48.36676 > 192.168.2.80.5006: UDP, length: 172
10:46:03.112517 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 617
10:46:03.118553 IP 217.10.79.48.36676 > 192.168.2.80.5006: UDP, length: 172
10:46:03.129782 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 715
10:46:03.138378 IP 217.10.79.48.36676 > 192.168.2.80.5006: UDP, length: 172
10:46:03.139411 IP 192.168.2.80.5006 > 217.10.79.48.36676: UDP, length: 172
10:46:03.150316 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 492
10:46:03.158390 IP 217.10.79.48.36676 > 192.168.2.80.5006: UDP, length: 172

Schon komisch... Kann es denn sein, dass bei sipgate.de die Eintragung der Portdaten nicht sofort aktualisiert wird? Die Vermutung liegt ja nahe, denn heute morgen lief es ja auch urplötzlich....

Ich warte jetzt einfach nochmal ein paar Stunden. Vielleicht erledigt sich das Thema ja auch von selbst :)

Gruss,
Dirk
 
DirkHX schrieb:
zu 4: Beim BT100 kann man jeweils nur einen SIP- und RTP-Port angeben. Meinst Du, dass das Telefon trotzdem 2 RTP-Ports benötigt? Ich habe in dem Script einfach noch ein paar RTP-Ports eingefügt. Stören sollte es ja nicht.
ja, RTP sieht immer 2 direkt aufeinander folgende Ports vor. Der zweite Port ist zum Austausch von Verbindungs- und Kontrollinformationen. Dafür wird das sog. RTCP verwendet. Es funktioniert meist auch ohne den 2. Port, aber besser ist es mit.

DirkHX schrieb:
Zum ARP kann ich nicht viel sagen - ich bin nicht so der Profi auf dem Gebiet.
hast Du mal den Stecker aus dem Switch gezogen, wie ich empfohlen hatte, um den Switch neu zu starten?
Oder hast Du unendlich viel Traffic auf Deinem Netzwerk, so dass schon bei Dir Pakete verloren gehen?

DirkHX schrieb:
Jetzt habe ich ein neues kleines Problem: Das BT100 meldet ein 482 ("Loopback detected"). Telefonieren funktioniert trotzdem, aber der Ton kommt "abgehackt" rüber. Das hört sich so an als ob irgendwie Pakete verloren gehen.
hmmm... machst Du neben dem Telefonieren noch irgendwelche Up- oder Downloads? Emule? Bittorrent? - so etwas könnte die Ursache sein.

DirkHX schrieb:
Hier zur Info mein neuer Firewall-Skript-Ausschnitt:
Das sieht ok aus. Sollte so gehen. Mir fällt gerade ein:
Wenn Du nur Sipgate verwendest und beim BT _keinen_ STUN-Server angibst, dann müsste es ohne jegliche Portweiterleitung klappen. Du müsstest natürlich nur die Firewall für die entprechenden Ports öffnen. Also alles raus, außer den -j ACCEPT-Zeilen müsste mit sipgate funktionieren. Allerdings nicht mit anderen Providern wie GMX.

DirkHX schrieb:
Und hier noch ein tcpdump-Mitschnitt:

Code:
10:07:42.780018 arp who-has 192.168.2.1 (ff:ff:ff:ff:ff:ff) tell 192.168.2.80
10:07:44.460075 arp who-has 192.168.2.1 tell 192.168.2.80
10:07:44.461043 arp who-has 192.168.2.1 tell 192.168.2.80
10:07:44.461124 arp who-has 192.168.2.1 tell 192.168.2.80
10:07:44.461453 arp who-has 192.168.2.1 tell 192.168.2.80
10:07:45.481460 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 4
10:07:46.948420 IP 192.168.2.80.26789 > 192.168.2.1.53:  32064+ A? sipgate.de. (28)
10:07:46.948817 IP 192.168.2.1.53 > 192.168.2.80.26789:  32064 1/6/0 A 217.10.79.9 (150)
10:07:49.450890 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 422
10:07:49.553999 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 624
10:07:49.573300 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 616
10:07:49.686568 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 519
10:07:49.944966 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 644
10:07:50.058567 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 582
10:07:50.480118 arp who-has 192.168.2.80 tell 192.168.2.1
10:07:50.480326 arp reply 192.168.2.80 is-at 00:0b:82:01:5d:15
10:07:54.458191 IP 192.168.2.80.26789 > 192.168.2.1.53:  32068+ A? time.nist.gov. (31)
10:07:54.458569 IP 192.168.2.1.53 > 192.168.2.80.26789:  32068 1/13/0 A 192.43.244.18 (258)
10:07:59.458056 IP 192.168.2.80.9876 > 192.43.244.18.123: NTPv4 client, strat 0, poll 4, prec -6
10:07:59.687564 IP 192.43.244.18.123 > 192.168.2.80.9876: NTPv4 server, strat 1, poll 4, prec -18
10:08:01.261148 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 4
10:08:04.057759 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 4
10:08:16.892817 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 4
10:08:18.057310 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 4
10:08:32.056855 IP 192.168.2.80.5060 > 217.10.79.9.5060: UDP, length: 4
10:08:32.744951 IP 217.10.79.9.5060 > 192.168.2.80.5060: UDP, length: 4
und wieder das seltsame ARP-Problem. Dein Router antwortet irgendwie nicht anständig auf ARP-Anfragen. Ich kann nicht überblicken, ob das was mit den Firewall-Einstellungen zutun hat.

DirkHX schrieb:
Jetzt aber nochmal zu dem "482 - Loopback detected": Seltsamerweise sendet sipgate die Sprachdaten an den Port 5006, obwohl in der Konfig des BT100 eindeutig 5004 steht:
(...)
Schon komisch... Kann es denn sein, dass bei sipgate.de die Eintragung der Portdaten nicht sofort aktualisiert wird? Die Vermutung liegt ja nahe, denn heute morgen lief es ja auch urplötzlich....
Selstam. Da kann ich mir auch keinen Reim drauf machen. Es könnte höchstens sein, dass das an dem connection-tracking Deines Routers liegt. - neu booten sollte das Problem beheben. Sipgate "aktualisiert" den Port garantiert sofort.

Gruß,
Pfeffer.
 
Hallo Pfeffer,

vielen Dank nochmal für dein Feedback! Ohne das Forum hier hätte ich sicher einiges länger gebraucht! Das wesentliche Problem lag jetzt am Ende wohl beim Connection-Tracking. Seit dem Neustart des Servers lief es ziemlich problemlos... :) :)

Vielleicht hat ja jemand noch einen Tipp für mich: Wie kann ich das "Connection-Tracking" resetten, ohne den ganzen Server neu starten zu müssen? Gibt es da einen Befehl für iptables? Oder kann ich das Modul einfach neu laden?

Vielen Dank & noch ein schönes Pfingstwochenende,
Dirk

PS: Und jetzt wo beide BT100 hinter dem Router laufen, versuche ich mich an der nächsten Aufgabe: Asterisk :)
 

Statistik des Forums

Themen
244,695
Beiträge
2,216,692
Mitglieder
371,315
Neuestes Mitglied
jack-mack
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.