evil2000
Goto Top

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:
2018-10-30_000064

Und dazu die entsprechenden Firewallregeln, welche die Pakete mit dem richtigen Routing Tag Markieren (Bitte Kommentare beachten):
2018-10-30_000066

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=30
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:
[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): 
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:
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!

Content-ID: 391095

Url: https://administrator.de/contentid/391095

Ausgedruckt am: 14.11.2024 um 13:11 Uhr

137443
137443 30.10.2018 aktualisiert um 17:33:50 Uhr
Goto Top
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.
Evil2000
Evil2000 30.10.2018 um 17:48:17 Uhr
Goto Top
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.
137443
Lösung 137443 30.10.2018 aktualisiert um 18:01:11 Uhr
Goto Top
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.
SYS64738
Lösung SYS64738 31.10.2018 um 07:10:59 Uhr
Goto Top
Hast du schon die Lancom Hotline angerufen ? Die Jungs da sind sehr fit, und immer hilfsbereit.
Evil2000
Evil2000 31.10.2018 aktualisiert um 10:16:14 Uhr
Goto Top
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.
2018-10-31_000067
RTP ist ebenso eingestellt, von der Problematik aber vermutlich nicht betroffen. Aber ich kann RTP ja eh nicht testen wenn SIP nicht geht, also ist das ungewiss.

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

Zitat von @137443:
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.

Ich werde die mal kontaktieren und sie zusätzlich auf diesen Thread aufmerksam machen. Vielleicht hilft es.
137443
137443 31.10.2018 um 10:29:22 Uhr
Goto Top
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.
Evil2000
Evil2000 05.11.2018 um 18:54:08 Uhr
Goto Top
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!
137443
137443 05.11.2018 aktualisiert um 20:06:52 Uhr
Goto Top
Danke für die Rückmeldung, das erklärt natürlich alles face-smile.