VCM verwechselt "Source IP"...!?!

[cpuprofi]

Hallo an Alle,

hat sich was beim VCM geändert? Wurde dort die Programmierung geändert? Denn ich habe seit geraumer Zeit ein Problem:

VCM verwechselt anscheinend die "Source IP" bei der SIP-Leitung von SIPGATE:

Code: Alles auswählen

Received SIP message from invalid source

Actual Source IP .......: 109.233.129.13
Expected Source IP .....: 217.10.79.9
Actual Dest IP .........: 100.119.78.112
Expected Dest IP .......: 100.119.78.112
Local UDP Port .........: 10670
Actual Remote UDP Port .: 5060
Expected Remote UDP Port: 5060
Actual Routing Tag .....: 0
Expected Routing Tag ...: 0
Line Name ..............: SIPGATE

Die "109.233.129.13" = sip.messagenet.it (Italienischer SIP Provider), von MESSAGENET habe ich auch einen Account unter SIP-Leitungen, aber dieser sollte nicht bei der SIP-Leitung von SIPGATE antworten bzw. auf dem SIPGATE Account landen...

Weiter passiert so etwas auch bei der SIP-Leitung von DNS-NET:

Code: Alles auswählen

Received SIP message from invalid source

Actual Source IP .......: 92.60.210.92
Expected Source IP .....: 79.140.113.2
Actual Dest IP .........: 100.119.78.112
Expected Dest IP .......: 100.119.78.112
Local UDP Port .........: 14521
Actual Remote UDP Port .: 5060
Expected Remote UDP Port: 5060
Actual Routing Tag .....: 0
Expected Routing Tag ...: 0
Line Name ..............: DNS-NET

Dort passiert das gleiche "92.60.210.92" = nfon AG (Deutscher SIP Provider), von NFON habe ich auch einen Account unter SIP-Leitungen, aber dieser sollte nicht bei der SIP-Leitung von DNS-NET antworten bzw. auf dem DNS-NET Account landen...

Weiter ebenso bei DUSNET1:

Code: Alles auswählen

Actual Source IP .......: 92.60.210.92
Expected Source IP .....: 83.125.8.71
Actual Dest IP .........: 100.119.78.112
Expected Dest IP .......: 100.119.78.112
Local UDP Port .........: 10093
Actual Remote UDP Port .: 5060
Expected Remote UDP Port: 5060
Actual Routing Tag .....: 0
Expected Routing Tag ...: 0
Line Name ..............: DUSNET1

Auch dort das gleiche "92.60.210.92" = nfon AG (Deutscher SIP Provider), antwortet bzw. landet auf dem DUSNET1 Account...

Bei DUSNET2 und DUSNET3 ist wieder MESSAGENET dran:

Code: Alles auswählen

Actual Source IP .......: 109.233.129.13
Expected Source IP .....: 83.125.8.73
Actual Dest IP .........: 100.119.78.112
Expected Dest IP .......: 100.119.78.112
Local UDP Port .........: 10074
Actual Remote UDP Port .: 5060
Expected Remote UDP Port: 5060
Actual Routing Tag .....: 0
Expected Routing Tag ...: 0
Line Name ..............: DUSNET2

Code: Alles auswählen

Actual Source IP .......: 109.233.129.13
Expected Source IP .....: 83.125.8.71
Actual Dest IP .........: 100.119.78.112
Expected Dest IP .......: 100.119.78.112
Local UDP Port .........: 12562
Actual Remote UDP Port .: 5060
Expected Remote UDP Port: 5060
Actual Routing Tag .....: 0
Expected Routing Tag ...: 0
Line Name ..............: DUSNET3

"109.233.129.13" = sip.messagenet.it (Italienischer SIP Provider), antwortet bzw. landet auf dem DUSNET2 und DUSNET3 Accounts...

Und so geht es immer weiter.

Wie kann man das Lösen ohne den Schalter "SIP-Nachrichten nur vom Registrar erlauben" zu deaktivieren...?

Grüße
Cpuprofi

[Dr.Einstein]

Ich glaube, da hilft nur ein Supportticket. Sieht so aus, als wenn Lancom keine Quell-Portzuordnung mit protokolliert für dieses Sicherheitsfeature.

[cpuprofi]

Guten Morgen Dr.Einstein,

ich hoffe ja noch, dass AWI oder MoinMoin diesen Thread lesen und das zu was sagen können.

Grüße
Cpuprofi

[awi]

Guten Morgen zusammen,

das sieht alles etwas seltsam aus.
Eine Erklärung habe ich dafür im Moment nicht.

Könnten mal für den ganzen Vorgang Traces angefertigt werden?

Dazu am besten zunächst alle Leitungen deaktivieren.
LANCOM neu starten.
Nach Neustart Traces SIP-Packet, Callmanager, VCM-DNS, Sip-Connection und DNS einschalten.
Die Leitungen wieder aktivieren.
Ob die Reihenfolge dabei eine Rolle spielt kann ich nicht sagen, ist aber nicht auszuschließen.

Dann sollte wohl ein Callaufbau von extern erfolgen.
Hoffentlich tritt das Verhalten dann wieder auf.

Gruß
Awi

[awi]

Vielleicht kann aber vorab vom aktuellen Zustand ein Trace gemacht werden?
Also Sip-Packet, Callmanager, VCM-DNS, Sip-Connection und DNS einschalten und
Call von extern aufbauen, der dann ja fehlschlagen sollte.
Vielleicht lässt sich da schon was erkennen.

Danach dann die Traces mit Neustart, wie vorher beschrieben.
So haben wir dann wenigstens schonmal ein paar Traces vom Fehlerzustand
falls der Fall nach Neustart evtl. nicht auftritt.

Gruß
Awi

[tschonn]

Guten Morgen,
habe das identische Problem.
Mein Anschluss ist von der Deutschen Glasfaser mit CGNAT - könnte es damit zusammenhängen bzw. @cpuprofi: Ist das bei Dir auch so?
Gruß Tschonn

[cpuprofi]

Hallo awi,

ich bin seit 13.01. im Urlaub, somit kann ich keine Untersuchungen und Trace machen (Zugriff auf die Geräte habe ich schon, aber es bringt nichts, wenn ich versuche über 9000km einen Trace zu erstellen)

Hallo tschonn,

auch mein Hauptanschluß ist von der Deutschen Glasfaser mit CGNAT. Zusätzlich habe ich aber auch noch einen Tunnel für eine Feste IP und einen LTE Anschluß (normalerweise als Backup gedacht).

Wenn ich wieder zurück bin, kann ich ja mal die ganzen SIP-Leitungen über die Feste IP oder LTE schicken. mal sehen was dann da passiert...

Grüße
Cpuprofi