SPA 3000 hinter Bintec X.2300is zu 1und1

bikerede · 30 Jan 2005

Hallo,

ich habe seit Samstag einen SPA 3000. Diesen habe ich exakt lt. FAQ Grundkonfiguration SPA 3000 eingestellt, am Router sind die notwendigen Portfreigeben (5060..5062, 16384...16482) gesetzt.
Leider meldet sich der SPA bei 1und1 mit der internen IP an, obwohl auf der Infopage die korrekte IP angezeigt wird.

Code:

System started: [email protected], reboot reason:H0
        subnet mask:    255.255.255.0
        gateway ip:     192.168.10.1
        dns servers:    192.168.10.1 217.237.149.225
IDBG: st-0
[5060]STUN trying 0
[5060]STUN trying 1
[5060]STUN trying 0
[5060]STUN trying 1
[5060]STUN trying 2
[5060]STUN trying 3
[5060]STUN trying 4
fs:10190:10201:65536
fbr:1:0000:0000:14362:0006:0007:2.0.11(GWg)
fhs:01:0:0000:upg:app:0:2.0.11(GWg)
fhs:02:0:0001:upg:app:1:2.0.11(GWg)
fhs:03:0:0002:upg:app:2:2.0.11(GWg)
fhs:04:0:0003:upg:app:0:2.0.11(GWg)
fhs:05:0:0004:upg:app:1:2.0.11(GWg)
fhs:06:0:0005:upg:app:2:2.0.11(GWg)
[5060]STUN trying 5
[5060]STUN trying 6
[5060]STUN trying 7
[5060]STUN trying 8
[5060]STUN trying 0
RSE_DEBUG: reference domain:sip.1und1.de
RSE_DEBUG: reference domain:sip.1und1.de
[1:5061]->212.227.15.194:5060
[1:5061]->212.227.15.194:5060
REGISTER sip:sip.1und1.de:5061 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.4:5061;branch=z9hG4bK-5e0dc7e5;rport
From: <sip:[email protected]:5061>;tag=67bea4bbba8ee22bo1
To: <sip:[email protected]:5061>
Call-ID: [email protected]
CSeq: 1 REGISTER
Max-Forwards: 70
Contact: <sip:[email protected]:5061>;expires=3600
Warning: 399 spa "Symmetric NAT Detected"
User-Agent: Sipura/SPA3000-2.0.11(GWg)
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER
Supported: 100rel, x-sipura



[0]ExtIpChanged:0
[0]ExtSipPortChanged:0
[0]RegFail. Retry in 1200
[1:5061]<<212.227.15.194:5060
[1:5061]<<212.227.15.194:5060
SIP/2.0 479 Please don't use private IP addresses
Via: SIP/2.0/UDP 192.168.10.4:5061;branch=z9hG4bK-5e0dc7e5;rport=32800;received=
217.238.104.54
From: <sip:[email protected]:5061>;tag=67bea4bbba8ee22bo1
To: <sip:[email protected]:5061>;tag=32e930bf0f1ed484d4a78699f4ad7c11.61
d4
Call-ID: [email protected]
CSeq: 1 REGISTER
Server: Sip EXpress router (0.8.14 (i386/linux))
Content-Length: 0

[1]ExtSipPortChanged:0
RSE_DEBUG: unref domain, sip.1und1.de
RSE_DEBUG: unref domain, sip.1und1.de
RSE_DEBUG: last unref for domain sip.1und1.de
RSE_DEBUG: reference domain:sip.1und1.de
RSE_DEBUG: reference domain:sip.1und1.de
[1:5061]->212.227.15.194:5060
[1:5061]->212.227.15.194:5060
NOTIFY sip:sip.1und1.de:5061 SIP/2.0
Via: SIP/2.0/UDP 217.238.104.54:32810;branch=z9hG4bK-fdf8a70e;rport
From: <sip:[email protected]:5061>;tag=9411727b53c46f67o1
To: <sip:sip.1und1.de:5061>
Call-ID: [email protected]
CSeq: 6 NOTIFY
Max-Forwards: 70
Event: keep-alive
User-Agent: Sipura/SPA3000-2.0.11(GWg)
Content-Length: 0

Trage ich die erhaltene IP unter SIP/externe IP ein, funktioniert alles, aber leider nur bis zur nächsten IP-Vergabe.

besten Dank für die Hilfe

exim · 30 Jan 2005

"NAT Mapping enable: yes"?

bikerede · 31 Jan 2005

Ja, NAT MAPPING ist enable

Netview · 31 Jan 2005

Außer NAT wird auch der stun-server benötigt:
stun.1und1.de:3478 und enablen!

outbound-proxy abschalten und Feld leer lassen.

bikerede · 31 Jan 2005

Hallo,

habe ich lt. Forum schon alles so eingestellt. Offensichtlich wird ja auch die richtige IP in der Infoseite angezeigt, aber bei der Übermittlung nicht verwendet.

Netview · 1 Feb 2005

sind folgende Felder so eingestellt?

EXT IP: <leer>
NAT Keep Alive Intvl: 15

bikerede · 1 Feb 2005

Hallo,
ist alles so eingestellt, funktioniert nur leider nicht.

bikerede · 1 Feb 2005

Hallo.
hier noch ein Debug vom Router

06:54:23 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:6437/217.238.106.158:32880 -> 217.237.149.225:53
06:54:23 DEBUG/INET: dnsd: qry from 192.168.10.4:6437 id 1 "ntp1.belwue.de." A 1
06:54:23 DEBUG/INET: dnsd: cache 129.143.2.23 for ntp1.belwue.de.
06:54:23 DEBUG/INET: dnsd: rsp to 192.168.10.4:6437 id 1 "ntp1.belwue.de." A 1/0
/0
06:54:23 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:65385/217.238.106.158:32881 -> 129.143.2.23:123
06:54:29 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
6.158:135 <- 217.238.169.179:4472
06:54:30 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
6.158:135 <- 217.238.169.179:4472
06:54:30 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
6.158:135 <- 217.238.169.179:4472
06:54:33 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:20460/217.238.106.158:32882 -> 217.237.149.225:53
06:54:33 DEBUG/INET: dnsd: qry from 192.168.10.4:20460 id 1 "stun.1und1.de." A 1
06:54:33 DEBUG/INET: dnsd: cache 212.227.15.200 for stun.1und1.de.
06:54:33 DEBUG/INET: dnsd: rsp to 192.168.10.4:20460 id 1 "stun.1und1.de." A 1/0
/0
06:54:33 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:5060/217.238.106.158:32883 -> 212.227.15.200:3478
06:54:33 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32883 <- 212.227.15.201:3479
06:54:33 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32883 <- 212.227.15.201:3479
06:54:33 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32883 <- 212.227.15.201:3479
06:54:34 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32883 <- 212.227.15.201:3479
06:54:35 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32883 <- 212.227.15.201:3479
06:54:36 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32883 <- 212.227.15.201:3479
06:54:38 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32883 <- 212.227.15.201:3479
06:54:39 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32883 <- 212.227.15.201:3479
ropo:> debug all
07:01:00 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 217.238.106.158:10
26/217.238.106.158:32889 <-> 217.237.149.225:53
07:01:01 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:31609/217.238.106.158:32890 -> 217.237.149.225:53
07:01:01 DEBUG/INET: dnsd: qry from 192.168.10.4:31609 id 1 "ntp1.belwue.de." A
1
07:01:01 DEBUG/INET: dnsd: cache 129.143.2.23 for ntp1.belwue.de.
07:01:01 DEBUG/INET: dnsd: rsp to 192.168.10.4:31609 id 1 "ntp1.belwue.de." A 1/
0/0
07:01:01 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:14742/217.238.106.158:32891 -> 129.143.2.23:123
07:01:03 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
6.158:135 <- 217.238.25.243:2998
07:01:03 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
6.158:135 <- 217.238.25.243:2998
07:01:04 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
6.158:135 <- 217.238.25.243:2998
07:01:06 DEBUG/INET: NAT: delete session on ifc 10001 prot 6 192.168.10.5:4157/2
17.238.106.158:33313 <-> 217.160.220.106:80
07:01:06 DEBUG/INET: NAT: delete session on ifc 10001 prot 6 192.168.10.5:4162/2
17.238.106.158:33318 <-> 195.126.99.94:80
07:01:11 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:28489/217.238.106.158:32892 -> 217.237.149.225:53
07:01:11 DEBUG/INET: dnsd: qry from 192.168.10.4:28489 id 1 "stun.1und1.de." A 1
07:01:11 DEBUG/INET: dnsd: fwd 192.168.10.4:28489 id 1 to 217.237.149.225:53 id
19048 "stun.1und1.de." A
07:01:11 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 217.238.106.
158:1026/217.238.106.158:32893 -> 217.237.149.225:53
07:01:11 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:5060/217.238.106.158:32894 -> 212.227.15.200:3478
07:01:11 DEBUG/INET: dnsd: rsp from 217.237.149.225:53 id 19048 "stun.1und1.de."
A 0 1/0/0
07:01:11 INFO/INET: dnsd: cache add 212.227.15.200 for stun.1und1.de.
07:01:11 DEBUG/INET: dnsd: rsp to 192.168.10.4:28489 id 1 "stun.1und1.de." A 1/0
/0
07:01:11 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32894 <- 212.227.15.201:3479
07:01:11 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32894 <- 212.227.15.201:3479
07:01:11 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32894 <- 212.227.15.201:3479
07:01:12 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32894 <- 212.227.15.201:3479
07:01:12 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32894 <- 212.227.15.201:3479
07:01:13 DEBUG/IPSEC: IKE_INVALID_COOKIE: 19300422003257: Source addr:0.0.0.0
Destination addr:212.185.162.10
07:01:14 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32894 <- 212.227.15.201:3479
07:01:15 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
6.158:135 <- 217.238.30.61:3989
07:01:15 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 192.168.10.4:5061/
217.238.106.158:32879 <-> 212.227.15.194:5060
07:01:15 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 192.168.10.4:5060/
217.238.106.158:32878 <-> 212.227.15.194:5060
07:01:16 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32894 <- 212.227.15.201:3479
07:01:16 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
6.158:135 <- 217.238.30.61:3989
07:01:17 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32894 <- 212.227.15.201:3479
07:01:17 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 192.168.10.4:31609
/217.238.106.158:32890 <-> 217.237.149.225:53
07:01:18 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
6.158:135 <- 217.238.30.61:3989
07:01:19 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
06.158:32894 <- 212.227.15.201:3479
07:01:20 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:5060/217.238.106.158:32895 -> 212.227.15.201:3479
07:01:20 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:39800/217.238.106.158:32896 -> 217.237.149.225:53
07:01:20 DEBUG/INET: dnsd: qry from 192.168.10.4:39800 id 1 "sip.1und1.de." A 1
07:01:20 DEBUG/INET: dnsd: cache 212.227.15.194 for sip.1und1.de.
07:01:20 DEBUG/INET: dnsd: rsp to 192.168.10.4:39800 id 1 "sip.1und1.de." A 1/0/
0
07:01:20 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:5060/217.238.106.158:32897 -> 212.227.15.194:5060
07:01:20 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
:5061/217.238.106.158:32898 -> 212.227.15.194:5060
07:01:31 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 192.168.10.4:14742
/217.238.106.158:32891 <-> 129.143.2.23:123

RB · 2 Feb 2005

Moin!

Zu den Sipuras kann ich nichts sagen, aber meinen Senf zu dem syslog-Mitschnitt abegeben...

Also aus meiner Sicht sieht das alles soweit OK aus.

Wie aus dem Protokoll zu erkennen ist, läßt der Bintec die Antworten vom Zwillings-STUN-Server (Source Port 3479) nicht durch

07:01:11 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4:5060/217.238.106.158:32894 -> 212.227.15.200:3478
...
07:01:11 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.106.158:32894 <- 212.227.15.201:3479

Die Antwort vom Haupt-STUN-Server kommt anscheinend ja durch, da keine Beschwerden zu sehen sind. Ein Stück weiter unten greift der STUN-Algorithmus vom Sipura dann selbst auf den Zwillings-Server zu

07:01:20 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4:5060/217.238.106.158:32895 -> 12.227.15.201:3479

Auch da kommen keine Fehler, also wird die Antwort dann wohl durchkommen. Das sollte eigentlich ausreichen, damit der STUN-Algorithmus den Typ der Firewall erkennt. Die externe IP-Adresse muß er auf jeden Fall mitgekriegt haben.

Ich hab's bei mir mit WinStun (winziges kleines Hilfsprogrämmchen zum STUN-Test) mal ausprobiert: Er sagt: "Symmetric Firewall" und meine externe IP-Adresse. Sollte also eigentlich zumindest dafür klappen...

Ich habe übrigens kein Port-Forwarding für 3478+3479 eingerichtet, damit die STUN-Tests nicht verfälscht werden.

Wenn die IP-Adresse trotzdem nicht stimmt, kann das Problem eigentlich nur im Sipura selbst irgendwo liegen.

bikerede · 2 Feb 2005

Hallo,
besten Dank für die Info; ich selbst habe auch den Port3478/9 auf dem Router nicht eingerichtet.
Woran kann es denn jetzt noch liegen?

bikerede · 2 Feb 2005

Hallo,
ich habe den Router mit WinStun getestet:

Symetric - VOIP will NOT work
Does not preserve port number
Does not supports hairpin of media
Public IP address: xxx.238.106.xxx

Liegt hier das Problem?

RB · 2 Feb 2005

Wenn die Public IP Address stimmt, sollte das eigentlich reichen. Bei mir kommt exakt die gleiche Aussage über die Firewall (könnte daran liegen, daß ich auch einen Bintec-Router habe :wink: )

Sowohl mein Cisco-Telefon, als auch SIPPS / X-Lite haben schon damit funktioniert (z.Z. telefoniere ich nur noch über das Cisco). Ich habe auch nur brav meine Port-Forwardings für SIP- und RTP-Ports gemacht, sonst nichts in der Richtung. Ach doch: Weil PURtel etwas anders als andere mit den Ports umgeht, habe ich in den NAT-Einstellungen auch von drinnen nach draußen den SIP-Port festgenagelt. Soll heißen, daß der externe Port für 5060/UDP auch 5060/UDP ist, und kein zufällig gewählter, wie für NAT sonst üblich. Das war aber, wie gesagt, nur für PURtel nötig.

Ich vermute eher, daß der Sipura aus irgendwelchen Gründen nicht damit zufrieden ist, daß es diese Art Firewall ist. Eine weitere Möglichkeit wäre natürlich, daß der 1und1-STUN-Server sich irgendwie anders verhält, als erwartet. Schon mal irgendeinen anderen versucht?

Ansonsten müssen die Sipura-Cracks jetzt hier was zu sagen...

bikerede · 2 Feb 2005

Hallo,

habe soeben larry.gloo.net getestet, gleicher Fehler.
Da, wie im obersten Log aufgeführt, mein Adapter versucht, sich mit der internen IP sich bei sip.... anzumelden, kann es doch nicht reichen, obwohl sie ja auf der Infopage eangezeigt wird.

bikerede · 4 Feb 2005

Hallo,
ich habe mein Problem an Bintec weitergeleitet; mal sehen,ob der kostenlose First-Level-Support hilft.

RB · 6 Feb 2005

@bikerede
Wie gesagt, ich denke nicht, daß das ein Bintec-Problem sein kann! Bei mir kommen die gleichen Meldungen und Zustände, aber es funktioniert halt trotzdem. Der wesentliche Unterschied ist, daß ich keinen Sipura habe. Ich denke mal, wenn schon, sollte man bei Sipura nachfragen.

Der Router macht, was er soll: Unerwünschten bzw. unerwarteten Traffic blocken. Andere Wünsche müssen ihm kundgetan werden.

bikerede · 8 Feb 2005

Hallo,
nach mehreren Rückfragen bei Bintec habe ich letztendlich die Aussage erhalten, das dies der Router noch nicht kann; ev. ist im Laufe des Jahres mit dieser Funktion zu rechnen. Für einen doch in der "höheren" Region angesiedelten Router ist dies doch wohl eine sehr unbefriedigende Antwort.
Der Zustand beim SPA ist unverändert, ich trage täglich die neue IP von Hd. ein.

RB · 8 Feb 2005

Was soll er denn nun nicht können?
Und mit welcher Funktion soll eventuell im Laufe des Jahres zu rechnen sein?

Wenn das Sipura nicht in der Lage ist, nach einer STUN-Abfrage über eine symmetrische NAT die öffentliche IP-Adresse korrekt einzutragen, kann das doch nicht Aufgabe des Routers sein, dem die Arbeit abzunehmen. Die Erkennung der Adresse scheint ja zu funktionieren. Wie Du schreibst, steht sie ja in der Übersicht drin. Wenn sie dann trotzdem nicht verwendet wird, ist das ja wohl eine Macke beim Sipura.

Das scheint jedenfalls das Problem zu sein, soweit ich das bisher rauslesen konnte.

Mein 7960 funktioniert jedenfalls problemlos. SIPPS und X-Lite/X-Pro ebenfalls. Nur SJPhone habe ich mit genau den gleichen Effekten wie bei Dir mit dem Sipura nicht ans Laufen bekommen, was ja wohl darauf hindeutet, daß es unterschiedliche Implementationen der STUN-Abfragen gibt. Die eine Variante funktioniert, die andere eben nicht...

Nebenbei bemerkt: im Business-Bereich gilt SIP immer noch häufig als "Spielkram" (warum auch immer). Dort wird nach wie vor eher auf H.323 gesetzt. Und dafür haben zumindest die 1200er dann auch konsequenterweise einen Gatekeeper implementiert. Wenn die Akzeptanz von SIP im Business-Umfeld steigt (was ja der Fall zu sein scheint), werden die wahrscheinlich auch für SIP entsprechende Hilfen ( Proxy? ) einbauen.

bikerede · 9 Feb 2005

Hallo,
gemeint war, daß ein Unterstützung für STUN in der Firmware vorgesehen ist. Leider war bei Bintec nicht mehr zu erfahren, da alle kostenlosen Anfragen über den Firstlevelsupport erfolgen müssen; diese aber meine Anfragen per Mail nicht beantworten.
Zurück zu meinem Problem: Mittlerweilen habe ich keinen Ansatz mehr zur Lösung. Fakt ist, daß SIP ohne Probleme nach einem manuellen Eintrag funktioniert.
Sipura habe ich auch unter [email protected] angeschrieben, aber keinerlei Antwort erhalten. Gibt es hier ev. einen anderen Weg?
Da lt. Forum der SPA 2000 hinter einem X.1200 funktioniert, habe ich mal meine Firmware auf die 6er Version zurückgesetzt, aber auch hier keine Änderung.
Gibt es ev. eine andere Möglichkeit dem SPA meine IP zu übermitteln, da ich dyndns benutze?

bikerede · 9 Feb 2005

Hallo,
Problem erledigt; habe soeben eine neue Firmware 2.0.13 aufgespielt.
Nach einer ersten Fehlregistrierung erfolgt nach 30s eine fehlerfreie Anmeldung. Dieser Zustand bleibt auch nach einem Neustart von Router und/oder SPA erhalten, hoffentlich sehr sehr lange.

bikerede · 9 Feb 2005

bikerede schrieb:
Hallo,
Problem erledigt; habe soeben eine neue Firmware 2.0.13 auf den SPA aufgespielt.
Nach einer ersten Fehlregistrierung erfolgt nach 30s eine fehlerfreie Anmeldung. Dieser Zustand bleibt auch nach einem Neustart von Router und/oder SPA erhalten, hoffentlich sehr sehr lange.

SPA 3000 hinter Bintec X.2300is zu 1und1

Neuer User

Admin a.D.

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Neuer User

Neuer User

Statistik des Forums