.titleBar { margin-bottom: 5px!important; }

iptables - SUSE 9.3: Keine Verbindung beim BT100

Dieses Thema im Forum "Linux Software-Router" wurde erstellt von DirkHX, 8 Mai 2005.

  1. DirkHX

    DirkHX Neuer User

    Registriert seit:
    5 Mai 2005
    Beiträge:
    10
    Zustimmungen:
    0
    Punkte für Erfolge:
    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.
     
  2. pfeffer

    pfeffer Mitglied

    Registriert seit:
    26 Okt. 2004
    Beiträge:
    755
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    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.
     
  3. DirkHX

    DirkHX Neuer User

    Registriert seit:
    5 Mai 2005
    Beiträge:
    10
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  4. pfeffer

    pfeffer Mitglied

    Registriert seit:
    26 Okt. 2004
    Beiträge:
    755
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    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.

    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?

    hmmm... machst Du neben dem Telefonieren noch irgendwelche Up- oder Downloads? Emule? Bittorrent? - so etwas könnte die Ursache sein.

    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.

    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.

    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.
     
  5. DirkHX

    DirkHX Neuer User

    Registriert seit:
    5 Mai 2005
    Beiträge:
    10
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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 :)