8
Lancom 1781VAW frisst UDP Pakete
Hallo Alle!
was sich im Betreff so einfach anhört ist ein Phänomen welches ich mir nicht erklären kann. Vielleicht habt ihr dazu eine Idee die mich weiter bringt oder sogar eine Lösung.
Ich habe hier folgende Konstellation:
Default Router ist Lancom 1781VAW (Firmware 10.12.0382RU9 / 12.06.2018) mit zwei Internetanschlüssen: Vodafone welches direkt über ADSL2+ und Unitymedia welches über Kabel angeschlossen ist und direkt mit einer öffentlichen IP auf dem Lancom Router terminiert. Der Lancom Router macht Loadbalancing über beide Anschlüsse. Hinter dem Lancom ist direkt das interne Netz angeschlossen.
Im internen Netz steht eine Mitel Office 400 Telefonanlage (IP 192.168.1.20) welche sich bei drei SIP Providern registrieren soll: Vodafone/Arcor, Unitymedia und DUSnet.
Damit die SIP Pakete auch auf das richtige WAN-IF geleitet werden gibt es drei default Routen mit Routing Tag im Lancom:
Und dazu die entsprechenden Firewallregeln, welche die Pakete mit dem richtigen Routing Tag Markieren (Bitte Kommentare beachten):
Die Telefonanlage sendet SIP Register auf UDP Port 5060 an den Provider. Dieser antwortet mit SIP Status 200 OK. Das Antwortpaket wird vom Router Empfangen, durch die Firewall geleitet.
Im Trace des Routers sieht das ungefähr so aus:
Man sieht daß das Paket auf der Gegenstelle INTERNET hereinkommt und über LAN-1 und damit auf ETH-1 geroutet werden soll.
Nun passiert sporadisch folgendes:
Die Telefonanlage sendet das REGISTER. Der Provider antwortet. Aber der Router leitet das Paket nicht weiter:
Der komplette Teil für das absetzen des Pakets auf dem Ethernet fehlt und das Paket wird auch nicht vom Router an das interne Gerät (die Telefonanlage) gesendet.
Dieses Phänomen tritt auf nach jeglicher Konfigurationsänderung (egal welche), vermutlich nach der Zwangstrennung des Providers und zu offenbar zufälligen Zeiten.
Ich habe ein Trace mit einem Portmirror zwischen Router und Telefonanlage gemacht und hier die Zeiten notiert wann der Router die Pakete nicht weiterleitete:
Hat jemand von euch eine Idee:
- was die Ursache für die fehlenden Pakete ist
- wie ich dem Router noch mehr debugging angewöhnen kann damit er ggf. ausspuckt warum er die Pakete nicht auf ETH-1 absetzt?
Vielen Dank für eure Hilfe!
was sich im Betreff so einfach anhört ist ein Phänomen welches ich mir nicht erklären kann. Vielleicht habt ihr dazu eine Idee die mich weiter bringt oder sogar eine Lösung.
Ich habe hier folgende Konstellation:
Default Router ist Lancom 1781VAW (Firmware 10.12.0382RU9 / 12.06.2018) mit zwei Internetanschlüssen: Vodafone welches direkt über ADSL2+ und Unitymedia welches über Kabel angeschlossen ist und direkt mit einer öffentlichen IP auf dem Lancom Router terminiert. Der Lancom Router macht Loadbalancing über beide Anschlüsse. Hinter dem Lancom ist direkt das interne Netz angeschlossen.
Im internen Netz steht eine Mitel Office 400 Telefonanlage (IP 192.168.1.20) welche sich bei drei SIP Providern registrieren soll: Vodafone/Arcor, Unitymedia und DUSnet.
Damit die SIP Pakete auch auf das richtige WAN-IF geleitet werden gibt es drei default Routen mit Routing Tag im Lancom:
Und dazu die entsprechenden Firewallregeln, welche die Pakete mit dem richtigen Routing Tag Markieren (Bitte Kommentare beachten):
Die Telefonanlage sendet SIP Register auf UDP Port 5060 an den Provider. Dieser antwortet mit SIP Status 200 OK. Das Antwortpaket wird vom Router Empfangen, durch die Firewall geleitet.
Im Trace des Routers sieht das ungefähr so aus:
[TraceStarted] 2018/10/29 10:54:08,836
Used config:
# Trace config
trace + IP-Router @ +UDP +"port: 5060"
trace + IPv4-LAN-Packet @ +UDP +"port: 5060"
trace + IPv4-WAN-Packet @ +UDP +"port: 5060"
trace + Ethernet @ -Telnet/SSL +"Dest Address : 192.168.1.20"
[IP-Router] 2018/10/29 10:54:17,308 Devicetime: 2018/10/29 10:54:19,338
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.20, SrcIP: 178.15.141.135, Len: 457, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: LAN-1 Tx (INTRANET):
[Ethernet] 2018/10/29 10:54:17,308 Devicetime: 2018/10/29 10:54:19,338
Sent 471 byte Ethernet packet via LAN-1:
HW Switch Port : ETH-1
IPv4 Hdr Checksum : Dirty
-->IEEE 802.3 Header
Dest : 00:08:5d:97:80:c4
Source : 00:a0:57:2b:98:21 (LANCOM 2b:98:21)
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
ToS/DSCP : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length : 457
ID : 0
Fragment : Offset 0
TTL : 124
Protocol : UDP
Checksum : 37324 (updated by hardware)
Src Address : 178.15.141.135
Dest Address : 192.168.1.20
-->UDP Header
Src Port : SIP
Dest Port : SIP
Length : 437
Checksum : 21713 (OK)
-->SIP Packet
Header : SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.20:5060;received=92.209.xxx.xxx;branch=z9hG4bK_AI2018Oct295418482022888636608162;rport=5060
To: <sip:0228xxxxxx@0228.sip.arcor.de>;tag=aprqpjpsms9cg1c23-vf2s1q0010shf
From: <sip:0228xxxxxx@0228.sip.arcor.de>;tag=AI105B31A278E0D6A9
Call-ID: AID1235EA4A9B0B516@192.168.1.20
CSeq: 127224 REGISTER
Contact: <sip:0228xxxxxx@192.168.1.20:5060;line=AIA930EC03C93CC010>;expires=30Nun passiert sporadisch folgendes:
Die Telefonanlage sendet das REGISTER. Der Provider antwortet. Aber der Router leitet das Paket nicht weiter:
[TraceStarted] 2018/10/29 10:54:08,836
Used config:
# Trace config
trace + IP-Router @ +UDP +"port: 5060"
trace + IPv4-LAN-Packet @ +UDP +"port: 5060"
trace + IPv4-WAN-Packet @ +UDP +"port: 5060"
trace + Ethernet @ -Telnet/SSL +"Dest Address : 192.168.1.20"
[IP-Router] 2018/10/30 11:53:26,985 Devicetime: 2018/10/30 11:53:29,403
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.20, SrcIP: 178.15.141.135, Len: 523, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: LAN-1 Tx (INTRANET): Dieses Phänomen tritt auf nach jeglicher Konfigurationsänderung (egal welche), vermutlich nach der Zwangstrennung des Providers und zu offenbar zufälligen Zeiten.
Ich habe ein Trace mit einem Portmirror zwischen Router und Telefonanlage gemacht und hier die Zeiten notiert wann der Router die Pakete nicht weiterleitete:
29.10.2018
20:57-20:59
21:29-21:30
21:58-22:01
22:32-22:32
22:52-23:03
23:24-23:35
05:23-05:34
05:55-06:05
06:26-06:37
06:58-07:07
08:08-08:10
08:40-08:42
09:09-09:23
09:54-10:59
10:11-10:25
30.10.2018
11:50-12:01 (allerdings nach Konfig-Änderung)Hat jemand von euch eine Idee:
- was die Ursache für die fehlenden Pakete ist
- wie ich dem Router noch mehr debugging angewöhnen kann damit er ggf. ausspuckt warum er die Pakete nicht auf ETH-1 absetzt?
Vielen Dank für eure Hilfe!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 391095
Url: https://administrator.de/contentid/391095
Printed on: April 24, 2024 at 16:04 o'clock
8 Comments
Latest comment
Als erstes würde ich mal testweise das Load-Balancing raus werfen, nicht das das doppelte taggen zu der Situation führt das die Pakete über zwei Leitungen verteilt werden, das würde dann das Verwerfen der Pakete erklären.
Gruß l.
Gruß l.
Hallo Lummel,
gut das Du das Erwähnst, das hatte ich vergessen zu schreiben. Ich hatte das Loadbalancing auch schon deaktiviert und alles nur über die default Route laufen lassen, das hat aber leider nichts geändert. Die Pakete gehen sporadisch verloren.
Ich hatte sogar die komplette Konfiguration gelöscht und ohne Loadbalancing neu eingerichtet, was im gleichen Phänomen resultierte.
Interessant ist, daß es scheinbar nur UDP pakete von der IP Adresse der Telefonanlage trifft. Weder DNS Abfragen noch andere UDP Kommunikation (OpenVPN) von anderen Hosts scheint gestört zu sein.
gut das Du das Erwähnst, das hatte ich vergessen zu schreiben. Ich hatte das Loadbalancing auch schon deaktiviert und alles nur über die default Route laufen lassen, das hat aber leider nichts geändert. Die Pakete gehen sporadisch verloren.
Ich hatte sogar die komplette Konfiguration gelöscht und ohne Loadbalancing neu eingerichtet, was im gleichen Phänomen resultierte.
Interessant ist, daß es scheinbar nur UDP pakete von der IP Adresse der Telefonanlage trifft. Weder DNS Abfragen noch andere UDP Kommunikation (OpenVPN) von anderen Hosts scheint gestört zu sein.
Arbeitest du mit statischem Port-Forwarding für die RTP Pakete der VOIP Provider oder macht die Anlage für alle Provider STUN? Oder ist nur SIP selbst betroffen, nicht die Kommunikation?
Ich würde erst mal alle Provider nicht gleichzeitig sondern mal nacheinander hinzufügen abwarten und dann bei jedem Hinzufügen und Pause sehen ob die Fehler erneut auftreten. Nicht das die Zuordnung der SIP Pakete auf dem selben Port von unterschiedlichen Providern Probleme bereitet.
Ob der LANCom da noch irgendwelche SIP-Handling-Optionen bietet die da vielleicht in die Kommunikation rein spielen solltest du auch prüfen.
Wenn alles nichts hilft, LANCOM oder MitelSupport mal anfunken ob es da vielleicht in irgendeiner Kombination ein bekanntes Problem gibt.
Ich würde erst mal alle Provider nicht gleichzeitig sondern mal nacheinander hinzufügen abwarten und dann bei jedem Hinzufügen und Pause sehen ob die Fehler erneut auftreten. Nicht das die Zuordnung der SIP Pakete auf dem selben Port von unterschiedlichen Providern Probleme bereitet.
Ob der LANCom da noch irgendwelche SIP-Handling-Optionen bietet die da vielleicht in die Kommunikation rein spielen solltest du auch prüfen.
Wenn alles nichts hilft, LANCOM oder MitelSupport mal anfunken ob es da vielleicht in irgendeiner Kombination ein bekanntes Problem gibt.
Hast du schon die Lancom Hotline angerufen ? Die Jungs da sind sehr fit, und immer hilfsbereit.
Zitat von @137443:
Arbeitest du mit statischem Port-Forwarding für die RTP Pakete der VOIP Provider oder macht die Anlage für alle Provider STUN? Oder ist nur SIP selbst betroffen, nicht die Kommunikation?
Port 5060 ist statisch als Port-Forward eingestellt für alle Gegenstellen. Wobei ich mir nicht sicher bin was du mit statisch meinst. Ich hab den Screenshot der Config mal angehangen.Arbeitest du mit statischem Port-Forwarding für die RTP Pakete der VOIP Provider oder macht die Anlage für alle Provider STUN? Oder ist nur SIP selbst betroffen, nicht die Kommunikation?
Zitat von @137443:
Ich würde erst mal alle Provider nicht gleichzeitig sondern mal nacheinander hinzufügen abwarten und dann bei jedem Hinzufügen und Pause sehen ob die Fehler erneut auftreten. Nicht das die Zuordnung der SIP Pakete auf dem selben Port von unterschiedlichen Providern Probleme bereitet.
Ok für mich zum Verstehen: eigentlich soll der LC doch nur auf Dst Port schauen und danach die Pakete von extern nach intern blind weiterleiten. Den Inhalt der SIP Pakete muss er doch nicht prüfen und damit sollten ihm doch auch die Povider egal sein. Im Grunde auch die IPs.Ich würde erst mal alle Provider nicht gleichzeitig sondern mal nacheinander hinzufügen abwarten und dann bei jedem Hinzufügen und Pause sehen ob die Fehler erneut auftreten. Nicht das die Zuordnung der SIP Pakete auf dem selben Port von unterschiedlichen Providern Probleme bereitet.
Wenn deine These stimmt, müsste der LC NAT für die UDP-Pakete machen, dann würde mich nur wundern, warum der LC bereits im Trace beim Empfang die lokale IP zuordnet. Würde die Zuordnung nicht klappen würde das Paket schon eher verworfen werden. Oder?
Zitat von @137443:
Ob der LANCom da noch irgendwelche SIP-Handling-Optionen bietet die da vielleicht in die Kommunikation rein spielen solltest du auch prüfen.
Das einzige was mir eingefallen ist, ist SIP ALG. Auch dort macht es keinen Unterschied ob ich aktiviere oder abschalte.Ob der LANCom da noch irgendwelche SIP-Handling-Optionen bietet die da vielleicht in die Kommunikation rein spielen solltest du auch prüfen.
Zitat von @137443:
Wenn alles nichts hilft, LANCOM oder MitelSupport mal anfunken ob es da vielleicht in irgendeiner Kombination ein bekanntes Problem gibt.
Wenn alles nichts hilft, LANCOM oder MitelSupport mal anfunken ob es da vielleicht in irgendeiner Kombination ein bekanntes Problem gibt.
Zitat von @SYS64738:
Hast du schon die Lancom Hotline angerufen ? Die Jungs da sind sehr fit, und immer hilfsbereit.
Hast du schon die Lancom Hotline angerufen ? Die Jungs da sind sehr fit, und immer hilfsbereit.
Ich werde die mal kontaktieren und sie zusätzlich auf diesen Thread aufmerksam machen. Vielleicht hilft es.
Würde die Zuordnung nicht klappen würde das Paket schon eher verworfen werden. Oder?
Eigentlich Ja, kenne die LOG-Funktionsweise des Lancom jedoch nicht.
Die Ursache wurde gefunden.
Zwischen Lancom Router und Telefonanlage sitzt eine Firewall die momentan noch alle Daten blind durchleitet und nicht blockiert oder prüft, da sie noch konfiguriert werden muss. Es gibt als nur eine "Allow-All" Regel.
Was diese Regel allerdings nicht beachtet sind ARP-Pakete. Diese werden von WAN nach LAN verworfen ohne dies zu protokollieren. Testweise habe ich nun die Firewall direkt umgangen (Lancom direkt zum Switch) und siehe da, es funktioniert alles wie gedacht.
Der Lancom brauchte die MAC von der Telefonanlage. Da die FW das ARP Broadcast verworfen hatte kam das nie an der Telefonanlage an. Erst als die Telefonanlage ihrerseits einen ARP-Request zum Router schickte, hat dieser sich die MAC der Anlage gemerkt. Bis zum nächten ARP flush.
Danke für eure Hilfe!
Zwischen Lancom Router und Telefonanlage sitzt eine Firewall die momentan noch alle Daten blind durchleitet und nicht blockiert oder prüft, da sie noch konfiguriert werden muss. Es gibt als nur eine "Allow-All" Regel.
Was diese Regel allerdings nicht beachtet sind ARP-Pakete. Diese werden von WAN nach LAN verworfen ohne dies zu protokollieren. Testweise habe ich nun die Firewall direkt umgangen (Lancom direkt zum Switch) und siehe da, es funktioniert alles wie gedacht.
Der Lancom brauchte die MAC von der Telefonanlage. Da die FW das ARP Broadcast verworfen hatte kam das nie an der Telefonanlage an. Erst als die Telefonanlage ihrerseits einen ARP-Request zum Router schickte, hat dieser sich die MAC der Anlage gemerkt. Bis zum nächten ARP flush.
Danke für eure Hilfe!
Danke für die Rückmeldung, das erklärt natürlich alles 
.
.
