1906VA 4G Bandbreitenbegrenzung

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

Heigo

Re: 1906VA 4G Bandbreitenbegrenzung

Beitrag von Heigo »

Danke. Hier sehe ich die IP meines VPN an erster Stelle. An zweiter Stelle steht die IP des Routers meines entfernten VPN Servers. Die dritte IP gehört auch zum Subnetz meines entfernten VPN Servers.

Code: Alles auswählen

MacBook-Air:~ user$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
 1  10.0.0.1 (10.0.0.1)  42.645 ms  32.379 ms  36.611 ms
 2  9x.xx.xxx.xxx (xx.xx.xx.xx)  27.399 ms  31.612 ms  28.330 ms
 3  9xx.xx.xxx.xxx (xx.xx.xx.xxx)  37.644 ms  42.721 ms  30.295 ms
 4  ae0-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.139)  32.319 ms  37.576 ms  50.206 ms
 5  ae2-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.141)  30.619 ms  53.150 ms  34.058 ms
 6  209.85.149.86 (209.85.149.86)  56.017 ms  40.085 ms  78.578 ms
 7  * * *
 8  dns.google (8.8.8.8)  33.510 ms  44.237 ms  31.973 ms
MacBook-Air:~ user$ 
Jetzt hast du mich auf eine Idee gebracht! Stimmt hier was nicht? Das war so vorkonfiguriert:
Zuletzt geändert von Heigo am 10 Okt 2024, 12:52, insgesamt 1-mal geändert.
Dr.Einstein
Beiträge: 3222
Registriert: 12 Jan 2010, 14:10

Re: 1906VA 4G Bandbreitenbegrenzung

Beitrag von Dr.Einstein »

Der IP-Router Trace schlägt nicht an, weil du über einen VPN Tunnel gehst. Das kann der Lancom natürlich nicht sehen. Aber die Quell-IP muss auch verkehrt sein. Sonst würde deine DROP Regel greifen. Je nachdem, wie viel im Netzwerk los ist, könntest du einen ungefilterten Routing-Trace machen

trace # ip-r

Vielleicht kannst du daraus deinen MAC erkennen. Danach hast du aber dann das Problem, dass du den MAC nur als Ganzes droppen kannst. Keine einzelnen Anwendungen, wenn alles über den Tunnel läuft.
Heigo

Re: 1906VA 4G Bandbreitenbegrenzung

Beitrag von Heigo »

Der Drop sollte nur zum Test gelten, weil mir aufgefallen ist, dass die Firewall gar nicht greift. Wenn ein Drop funktionieren würde, wäre das schon mal ein Zeichen, dass der Lancom da überhaupt irgendwas macht. Ich werde deine Schritte durchgehen und bin gleich zurück.

EDIT: So hier einmal ohne VPN Verbindung und du hattest Recht, nun sehe ich das Trace:

Code: Alles auswählen

root@1906VA-4G:/
> trace # ip-router @ 8.8.8.8
IP-Router                  ON  @ 8.8.8.8

root@1906VA-4G:/
> 
[IP-Router] 2024/10/09 21:56:11,495
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 192.168.178.26, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x7e18, seq: 0x0000
Route: WAN Tx (INET_WWAN)

[IP-Router] 2024/10/09 21:56:11,510
IP-Router Rx (INET_WWAN, RtgTag: 0):
DstIP: 192.168.178.26, SrcIP: 8.8.8.8, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0x7e18, seq: 0x0000
Route: LAN-1 Tx (INTRANET)

[IP-Router] 2024/10/09 21:56:12,489
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 192.168.178.26, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x7e18, seq: 0x0001
Route: WAN Tx (INET_WWAN)

[IP-Router] 2024/10/09 21:56:12,513
IP-Router Rx (INET_WWAN, RtgTag: 0):
DstIP: 192.168.178.26, SrcIP: 8.8.8.8, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0x7e18, seq: 0x0001
Route: LAN-1 Tx (INTRANET)

[IP-Router] 2024/10/09 21:56:13,494
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 192.168.178.26, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x7e18, seq: 0x0002
Route: WAN Tx (INET_WWAN)

[IP-Router] 2024/10/09 21:56:13,519
IP-Router Rx (INET_WWAN, RtgTag: 0):
DstIP: 192.168.178.26, SrcIP: 8.8.8.8, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0x7e18, seq: 0x0002
Route: LAN-1 Tx (INTRANET)

[IP-Router] 2024/10/09 21:56:14,498
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 8.8.8.8, SrcIP: 192.168.178.26, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x7e18, seq: 0x0003
Route: WAN Tx (INET_WWAN)

[IP-Router] 2024/10/09 21:56:14,520
IP-Router Rx (INET_WWAN, RtgTag: 0):
DstIP: 192.168.178.26, SrcIP: 8.8.8.8, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0x7e18, seq: 0x0003
Route: LAN-1 Tx (INTRANET)
Dr.Einstein
Beiträge: 3222
Registriert: 12 Jan 2010, 14:10

Re: 1906VA 4G Bandbreitenbegrenzung

Beitrag von Dr.Einstein »

Dann muss jetzt die gesamte Firewall ausgeschaltet sein. Die Regel selbst trifft jetzt auf die IP zu, taucht im Trace auf, wird aber nicht blockiert.
Heigo

Re: 1906VA 4G Bandbreitenbegrenzung

Beitrag von Heigo »

Dr.Einstein hat geschrieben: 09 Okt 2024, 22:10 Dann muss jetzt die gesamte Firewall ausgeschaltet sein. Die Regel selbst trifft jetzt auf die IP zu, taucht im Trace auf, wird aber nicht blockiert.
Nein die ist definitiv an!
Zuletzt geändert von Heigo am 10 Okt 2024, 12:52, insgesamt 3-mal geändert.
Heigo

Re: 1906VA 4G Bandbreitenbegrenzung

Beitrag von Heigo »

Ich weiß nicht genau was passiert ist, da ich eine Zeit nichts mehr in der LANconfig verändert habe, aber nun hat die DROP Regel auf gegriffen und sämtlichen Verkehr vom Mac ins Internet blockiert. Ich sagte bereits, die Firewall macht was sie will.

EDIT 1: Hier einmal erste Erkenntnisse. Die Filterregeln hängen fest. In der Verbindungsliste sind die Clients und die entsprechenden Regeln zu sehen. Der Timeout der Clients läuft nicht ab und erneuert sich ständig, insbesondere beim Mac und beim SBC (VM auf dem Mac). Die Filterregel bleibt also die alte. Starte ich aber den Router neu, greifen die Regeln. Allerdings tue ich mich noch immer schwer beim Konfigurieren der Regeln, denn; Wenn ich nur für den SBC eine Regel anlege, z.B. 5% der gesamten Bandbreite und auf ACCEPT, dann überträgt der SBC irgendwann keine Daten mehr. Ebenso wird die Verbindung auf dem Mac/SBC die Verbindung nach einer gewissen Zeit Unterbrochen, wenn ich beide AppleTVs in eine Regel nehme mit 80% Bandbreitenreservierung ACCEPT. Ich komme dann nur wieder ins Internet, wenn ich die Regeln lösche und lange warte oder den Router neu starte.

Ich habe in den Regeln keine Empfangs- oder Senderichtung angehakt sondern ausgelassen, da ich mir im Unklaren bin aus welcher Sicht die Richtung zu betrachten ist.

EDIT 2: Fertig mit Lancom und nie wieder! Ich bin so sauer, deshalb erspare ich mir einige Worte oder Anspielungen, die hier zu nichts führen werden und gehe auch nicht auf weiteres ein. Wer ein Lancom 1906VA 4G benötigt, meldet sich bei mir.
Dr.Einstein
Beiträge: 3222
Registriert: 12 Jan 2010, 14:10

Re: 1906VA 4G Bandbreitenbegrenzung

Beitrag von Dr.Einstein »

Dr.Einstein hat geschrieben: 09 Okt 2024, 21:18 Bedenke, dass bestehende Sessions noch weiter funktionieren nachdem du eine Regelangepasst/hinzugefügt hast. Erst neue Sessions wandern durch die geänderten Firewallregeln.
Genau das hatte ich dir ja geschrieben. Angepasste Firewallregeln greifen erst für völlig neue Sessions. Alternativ Router neustarten oder die WAN Verbindung trennen. Ist Work as Designed. Gibt genug Leute, wo bestehende Sessions nicht getrennt werden sollen, nur weil man Regelwerk ergänzt. Man muss es nur wissen, dass Lancom so reagiert.

Bei dem Aktionsobjekt gibt es die Flags logische und physikalische Richtung. Logisch betrachtet die Aufbaurichtung der Session, physikalisch halt den Anschluss, über den es dann übertragen wird.

Die Herangehensweise, ACCEPT + Trigger zu setzen, ist meines Wissens nach keine gültige Konfiguration. Entweder kannst du mittels QoS Objekt eine Mindestdatenraten definierten, oder via DROP Objekt + Trigger eine Datenratendeckelung definieren. Von QoS ist bei deinem Aufbau abzuraten, da LTE keine festen Datenraten besitzt. Diese sind aber für QoS essenziell.

Ich kann nachvollziehen, dass du mit Lancom aufgibst. Viele Sachen erscheinen unlogisch und sind über Jahrzehnte historisch gewachsen. Ich hoffe, deine neue Lösung wird so funktionieren, wie du es brauchst.
Heigo

Re: 1906VA 4G Bandbreitenbegrenzung

Beitrag von Heigo »

Alles, was du sagst, ergibt Sinn. Sollte aber auch irgendwo stehen. Mir wird das mit Lancom leider alles zu ungenau. Es heißt, dass Downstream nur bei FTTH effektiv greift. Diese Aussage kommt hier aus dem Forum und leider nicht von Lancom. Ausgedacht wird’s wohl nicht sein, doch warum steht das nicht in der Anleitung? Oder ist das allgemein bei jedem Hersteller so, sodass es nicht erwähnenswert ist? Jedenfalls konnte ich nichts dergleichen in den bereits überholten Dokus finden. Die letzte Alternative wäre, die Fritzbox mit SIM für die Streams zu betreiben und den Lancom mit einer separaten SIM. Ich hätte ja noch eine, allerdings ist die auf 500 GB beschränkt, was reichen sollte. Dann muss ich schauen, wie ich das mit dem SBC mache, weil das Cisco direkt an den Lancom soll und der SBC aber über WLAN über die Fritzbox läuft. Das ginge also nicht, wenn ich den Lancom von der FritzBox trenne. Dann bräuchte ich doch ein Raspberry Pi – wieder eine zusätzliche Anschaffung, wobei ein Glasfaseranschluss alle Probleme lösen würde. Ich muss jetzt aber erst mal aus dem Vertrag rauskommen, der läuft noch 2 Jahre…Nie hätte ich gedacht, wie schwer es ist, ein paar kBytes im Downstream zu berücksichtigen.

Edit: Die Leitung ist bestellt, ich bin gespannt! Angefangen erst einmal mit dem kleinsten FTTH Tarif 200/100 Mbit/s. Morgen werde ich mir die Box einmal genauer ansehen - ist ein DiaLink. Ich benötige wahrscheinlich ein GPon Modul.
Antworten