VOIP Bug in 10.32.RU4 mit 2. Netzen

[langewiesche]

Ich habe einen R800V und habe gerade festestellt, das für den Sprachaufbau RTSP (codes) per VPN immer das 2. Netzwerk (DMZ) verwendet wird.
Die SIP Session steht aber auf dem 1. Interface (Intranet). Somit kann man leider nicht telefonieren.
Schaltet man das DMZ Netzwerk aus geht alles.
Da heute keiner Onside ist woll ich keine RC Firmware testen.

Froehes Fest ...

[ittk]

Hi,

da mir das Szenario etwas unklar erscheint, einfach ein paar Fragen:

Du bist per VPN-Client eingewaehlt und meldest Dich dann als SIP-Benutzer an? Dabei funktioniert ein Telefonat nicht?
Welches IP-Netzwerk (IP-Adresse) verteilt denn der LANCOM an den VPN-Client? Nicht, dass es IP-Adressen aus dem DMZ-Netzwerk sind!!!

Oder nutzt Du ein Site-to-Site VPN? Wann ja, welches Netz / mit oder ohne aktivierter IP-Maskierung?

Ist die SIP-Provider-Leitung das Routing-Tag 0 oder andere Routing-Tags zugeordnet?
Werden noch andere, weitere SIP-Leitungen, Typen, SIP-PBX Leitungen genutzt?

Wie schaut Deine Routing-Tabelle aus?

Wie schaut Deine IP-Netzwerke Tabelle aus?

Und ggfs. Deine LAN-Bridge Einstellungen --> Port-Tabelle usw....

Nuzt Du irgendwelche Firewall-Regeln, die ggfs. Routing-Tags nutzen?

M. E. sollte die LCOS 10.40RC1 in dieser Hinsicht keine Veraenderungen bringen....

Ebenfalls ruhige und erholsame Feiertage....

[langewiesche]

sorry ist ein site2site vpn
Das DMZ netz wird nicht geroutet von der anderen seite ...

der Upstream Telco ist 1und1 in der default route.

192.168.0.253 ist lancom
192.168.1,254 dmz lc


192.168.188.x die gegenstelle per site2site ikev1

firewall schau ich nach dem feste ....

[ittk]

Setzt Du ein N:N Nat ein?

Tritt der Fehler nur auf, wenn Du mit einem SIP-Client aus dem per VPN verbundenen Netzwerk kommst?
Sprich mit einer 192.168.188.xxx IP-Adresse?

Tritt der Fehler somit NICHT auf, wenn Du direkt - OHNE VPN - mit einem SIP-Client aus dem LAN (z .B. IP-Adresse 192.168.0.xxx) gleiches ausprobierst?
Tritt der Fehler AUF, wenn Du direkt - OHNE VPN - mit einem SIP-Client aus der DMZ (z .B. IP-Adresse 192.168.1.xxx) gleiches ausprobierst?

sorry ist ein site2site vpn
Das DMZ netz wird nicht geroutet von der anderen seite ...

der Upstream Telco ist 1und1 in der default route.

192.168.0.253 ist lancom
192.168.1,254 dmz lc


192.168.188.x die gegenstelle per site2site ikev1

firewall schau ich nach dem feste ....

[ittk]

Schaltet man das DMZ Netzwerk aus geht alles.

Was genau meinst Du damit --> abschalten?

Wie schaut bei Dir die IP-Netzwerke-Tabelle aus?
Per Default ist INTRANET auf LAN-1 und die DMZ auf LAN-2 gebunden.... oder kein ETH-Port auf LAN-2 gebunden, nur per BRG-1 sind die LAN2 bis 3 zugeordnet...

z. B.


cd /Setup/TCP-IP/Network-list
# Network-name IP-Address IP-Netmask VLAN-ID Interface Src-check Type Rtg-tag Comment
# ==================-----------------------------------------------------------------------------------------------------------------------------------------------------------------
add "INTRANET" {IP-Address} 192.168.50.1 {IP-Netmask} 255.255.255.0 {VLAN-ID} 0 {Interface} LAN-1 ODER BRG-1 {Src-check} loose {Type} Intranet {Rtg-tag} 0 {Comment} "local intranet"
add "DMZ" {IP-Address} 0.0.0.0 {IP-Netmask} 255.255.255.0 {VLAN-ID} 0 {Interface} LAN-2 {Src-check} loose {Type} DMZ {Rtg-tag} 0 {Comment} "demilitarized zone"

[Jirka]

Hallo zusammen,

ich kann den Bug zumindest bestätigen. Ist mir am 27.11. bei einem Kunden mit einem R883+ genauso aufgefallen. Der hatte eine NetPhone in der Cloud von der Telekom eingerichtet bekommen (Anbindung per VPN-Verbindung) und wollte von mir noch ein zweites Netz (Gastnetz), was per Schnittstellen-Tag vom Intranet getrennt werden sollte und per VLAN getrennt den LANCOM verlassen sollte. Es führte kein Weg rein, das wie gehabt durchzuziehen. SIP-Leitung(en) mit Routing-Tag, die VPN-Verbindung in der Routing-Tabelle mit Routing-Tag, der LANCOM wollte nicht, auch mit Enterprise-Option nicht, auch mit Sortierung der Netze nicht. Ich habe es dann aufgegeben und anders eine Lösung geschaffen. Immer etwas peinlich, wenn der IT-ler einem über die Schulter schaut, aber was soll's. Ich habe gesagt, dass das sicherlich bis RU10 beseitigt sein wird.

Viele Grüße,
Jirka

[langewiesche]

Bitte Leute ich mache das schon 14 Tage
Im letzen Monat glaube ich 4 Mal

[ittk]

Hi Jirka,

hast Du den Bug schon ueber die offiziellen Kanaele gemeldet, sodass der auch ordnungsgemaess dokumentiert ist?

Vielleicht interessiert dem User langewiesche auch Dein "Workaround"?

Hallo zusammen,

ich kann den Bug zumindest bestätigen. Ist mir am 27.11. bei einem Kunden mit einem R883+ genauso aufgefallen.....

[langewiesche]

das 2. Interface abschalten ist halt .. doof wenn man es braucht ... (zum glück ist das nur gast WLAN da)
Schau mache ein trace # 2020 ...

[Jirka]

Hallo ittk,

hast Du den Bug schon ueber die offiziellen Kanaele gemeldet, sodass der auch ordnungsgemaess dokumentiert ist?

nein, ich hätte da so einen schlechten Support-Level, dass der Aufwand mit dem Nutzen in keinem sinnvollen Verhältnis steht. Da wird früher oder später schon ein Platinum-Partner-Azubi drauf stoßen.

Vielleicht interessiert dem User langewiesche auch Dein "Workaround"?

Ach Lars hat ja meine Telefonnummer oder E-Mail-Adresse. Und ein Hexenwerk ist der Workaround ja auch nicht. Schnittstellen-Tags vermeiden, zumindest im Intranet, alles über Firewall-Regeln aufsetzen. Und das DMZ-Netzwerk kann man auch rausschmeißen, man muss es nur konsequent machen und dann ein zweites Gastnetz anlegen.

Viele Grüße,
Jirka

[ittk]

Moin Jirka,

hoert sich irgendwie nach einer "Vorgeschichte" an, dass Du den Bug nicht mehr melden magst.. Ich wuerde mich nicht drauf verlassen, dass jemand Anderes einen Bug meldet - unabhaengig vom Support-Level.....So waere es zumindest offiziell erfasst, wie lange dann die Behebung dauert, steht auf einem anderen Blatt....

Was ist im Uebrigen aus der umfangreichen T.38 Thematik geworden? Funktioniert das LANCOM T.38 nun zuverlaessig bspw. mit DTAG SIP-Anschluessen?
viewtopic.php?f=42&t=16439&p=101148#p101148

Zu dem Workaround und die DMZ loeschen:

Weshalb steht in diesem aelterem KB noch etwas davon? Vermutlich wird dieser Hinweis dann keinerlei Gueltigkeit / Relevanz mehr aufweisen ?!?

https://www2.lancom.de/kb.nsf/675ae5e65 ... enDocument

Code: Alles auswählen

Hinweis: Bitte die Enträge für Intranet und DMZ nicht löschen !!!!

In diesem Sinne: ein frohes Fest.

[langewiesche]

Das mit dmz Netz kannste werfen wenn du weisst was du machst ... Aber es gibt so viel wo man aufpassen muss .. leider fehlt mir derzeit die Zeit mich mit heissen neuen Scheiss in der Firmware zu beschäftigen ... Ich nutze das seit der 6.04 so ...

[Dr.Einstein]

Bekommst du das Problem weg, indem du die SIP Leitung auf ein festes Loopback Interface bindest (geht leider nur bei SIP Lines; CLI)?

Gruß Dr.Einstein

[ittk]

Muss dazu nicht auch unter LCOS Menuebaum: Setup --> TCP-IP --> Loopback-List noch ein Eintrag erstellt werden?
Und die Loopback-Adresse kann man wohl tatsaechlich nur per CLI / Webconfig ueberhaupt konfigurieren....

LCOS Menu Tree: Setup/Voice-Call-Manager/Lines/SIP-Provider/Line (Loopback-Address)

Bekommst du das Problem weg, indem du die SIP Leitung auf ein festes Loopback Interface bindest (geht leider nur bei SIP Lines; CLI)?

Gruß Dr.Einstein

[hyperjojo]

hi,

Bekommst du das Problem weg, indem du die SIP Leitung auf ein festes Loopback Interface bindest (geht leider nur bei SIP Lines; CLI)?

wäre auch meine erster Gedanke gewesen! Einfach das Intranet dort angeben:
set /Setup/Voice-Call-Manager/Lines/SIP-Provider/Line/T-123456 {loopback} INTRANET

Gruß hyperjojo