Beiträge von kreppelesser

kreppelesser

Ich habe noch mal einige Tests gemacht und kann bestätigen, daß das Limit der offenen TCP Connections wohl irgendwo im Bereich 700-800 gleichzeitig liegt. Lädt man z.B. ubuntu über BitTorrent mit mehreren Clients herunter, droppen die Verbindungen sobald man mehr als ca. 700 gleichzeitig offene TCP Verbindungen nach außen über IPv4 hat.

Die Hotline ist natürlich keine Hilfe und wie auch schon im Thread geschrieben hat die DG sicherlich kein Interesse das Limit in irgendeiner Form anzuheben oder zu verändern.

Vielen Dank für die rege Beteiligung, vor allem die Links von @::1 haben mir sehr geholfen das Problem zu verstehen, mir war anfangs nicht bewusst, dass selbstverständlich jeder Nutzer mit einer CGNAT-IP nur einen Teil der Ports der Public-IP zugewiesen bekommt.

Ich habe es jetzt gelöst indem ich eine VM im Rechenzentrum in meiner Nähe gemietet habe, dorthin eine Wireguard-Verbindung aufbaue und sämtlichen IPv4 Traffic durch Wireguard zu dieser IP leite. Das hat den großen Vorteil, daß diese IP dann gleichzeitig meine Public-IP nach außen ist und ich dort mit SNAT nun auch über IPv4 von außen erreichbar sein kann wenn ich möchte. Wider Erwarten ist die Performance sehr gut, im DS bei ca. 900 MBit/s und der Upstream bei ca. 480MBit/s - trotz Wireguard.

kreppelesser

Es hängen nicht viele Hosts dran, evtl. ein Subnet mit vielleicht 100 Hosts.

Du hast vermutlich recht, daß die sicherlich keine Limits anheben oder verändern werden, allerdings ist das doch schon ein großer Nachteil von CGNAT.. Für was hast Du eine 1GB Verbindung wenn Du dann auf IPv4 nur mit gezogener Handbremse eine handvoll Hosts damit bedienen kannst ?

Via Wireguard Tunnel funktioniert es soweit, es ist aber schon eine "Krücke". Dummerweise gibt es hier außer der DG nichts.. Wenn es die DTAG gäbe, hätte man ja eine Alternative oder wenn die DG wenigstens echtes Dual Stack anbieten würde, gerne auch für Mehrkosten...

kreppelesser

Hmm wenn ich mit den Beitrag im Forum durchlese mit "nur" 4*256 tcp Verbindungen (gleichzeitig) per NAT-IP könnte ich mir sehr gut vorstellen, daß ich evtl. an dieses Limit komme da ich noch etliche Server etc. im Heimnetz habe die nach draußen telefonieren und viele established states haben..

Die Frage ist nur, wie erklärt man das DG bzw. wie kommt man an einen Mitarbeiter der einem dieses Limit erhöhen kann oder überhaupt erst über dieses Limit bescheid weiß

Derzeit behelfe ich mir, indem ich eine Wireguard-Verbindung zu einer VPS aufbaue und all meinen IPv4 Traffic durch diese Wireguard Verbindung jage, das klappt sehr gut, das Problem ist nur, daß die VPS IP bei vielen Anbietern wie z:B. Netflix geblockt ist wegen GeoIP.. Idealerweise muss man also eine VPS finden die NICHT in einem Blacklist-Bereich ist und man verliert natürliche in paar MBIt's bei dem Tunnel...

kreppelesser

Das dürfte dann dieser hier sein: 94.31.113.142

Code

marcel@g3-rig06:~$ curl ipv4.icanhazip.com
curl: (7) Failed to connect to ipv4.icanhazip.com port 80 after 8 ms: Couldn't connect to server
marcel@g3-rig06:~$ curl ipv4.icanhazip.com
curl: (7) Failed to connect to ipv4.icanhazip.com port 80 after 41 ms: Couldn't connect to server
marcel@g3-rig06:~$ curl ipv4.icanhazip.com
curl: (7) Failed to connect to ipv4.icanhazip.com port 80 after 8 ms: Couldn't connect to server
marcel@g3-rig06:~$ curl ipv4.icanhazip.com
94.31.113.142

kreppelesser

Da gibts nicht viel:

Code

root@g3-rig06:/home/marcel# netstat -rn
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
0.0.0.0         192.168.12.1    0.0.0.0         UG        0 0          0 enp2s0
192.168.12.0    0.0.0.0         255.255.252.0   U         0 0          0 enp2s0
root@g3-rig06:/home/marcel#

12.1 ist das Gateway welches direkt an der DG hängt.

auf der pfSense ist die default route:

default

100.84.0.1

UGS

5

1500

ix0

100.84.0.1 ist DG

kreppelesser

Also gut dann hier erstmal ein mtr:

Code

g3-rig06 (192.168.15.106) -> 82.98.127.7 (82.98.127.7)                                                                                                                                                                 2025-02-09T11:10:14+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                                                                                                                                      Packets               Pings
Host                                                                                                                                                                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. _gateway                                                                                                                                                                                          0.0%   199    0.1   0.7   0.1  62.7   6.2
2. 100.124.1.11                                                                                                                                                                                      0.0%   199    2.0   2.3   1.4   8.5   1.1
3. (waiting for reply)
4. 185.22.46.96                                                                                                                                                                                      0.0%   199    1.7   3.5   1.4  64.7   8.0
5. ipv4.de-cix.fra.de.as12306.plusline.net                                                                                                                                                           0.0%   199    2.7   3.5   1.7  64.6   7.5
6. te3-1.c302.f.de.plusline.net                                                                                                                                                                      0.0%   199    2.0   2.6   1.9  63.0   4.3
7. 82.98.103.2                                                                                                                                                                                       0.0%   199    2.3   3.7   2.1  64.7   7.5
8. 82.98.102.175                                                                                                                                                                                     0.0%   199    1.7   2.7   1.6 106.9   7.9
9. 213.83.57.150                                                                                                                                                                                     0.0%   198    2.4   2.4   1.8  43.3   2.9
10. 82.98.127.7                                                                                                                                                                                       0.0%   198    1.6   2.0   1.4  45.0   3.5

Alles anzeigen

Kein loss, nirgends.

Versucht man mit Netcat eine Verbindung herzustellen:

Code

marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
Connection to 82.98.127.7 80 port [tcp/http] succeeded!
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
Connection to 82.98.127.7 80 port [tcp/http] succeeded!
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
Connection to 82.98.127.7 80 port [tcp/http] succeeded!
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
Connection to 82.98.127.7 80 port [tcp/http] succeeded!
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
Connection to 82.98.127.7 80 port [tcp/http] succeeded!
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
Connection to 82.98.127.7 80 port [tcp/http] succeeded!
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host
marcel@g3-rig06:~$ nc -z -v 82.98.127.7 80
nc: connect to 82.98.127.7 port 80 (tcp) failed: No route to host

Alles anzeigen

Per IPv6 wiederum okay.

kreppelesser

Hier noch ein paar Logs.

Gemacht unter Linux, einfach mit "curl -v http://212.53.215.173"

Normalerweise sollte jedes Mal ein ganz normaler Reply from Webserver kommen, allerdings, wie man im Log sieht, geht es nur sporadisch jedes 3-4 mal.

Zwischen den einzelnen Sessions lasse ich ca. 10 Sekunden Pause:

HTML

marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* connect to 212.53.215.173 port 80 from 192.168.15.112 port 59578 failed: No route to host
* Failed to connect to 212.53.215.173 port 80 after 1 ms: Couldn't connect to server
* Closing connection
curl: (7) Failed to connect to 212.53.215.173 port 80 after 1 ms: Couldn't connect to server
marcel@rigtr12:~$ date
Sat Feb  8 17:23:32 UTC 2025
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* connect to 212.53.215.173 port 80 from 192.168.15.112 port 44664 failed: No route to host
* Failed to connect to 212.53.215.173 port 80 after 1 ms: Couldn't connect to server
* Closing connection
curl: (7) Failed to connect to 212.53.215.173 port 80 after 1 ms: Couldn't connect to server
marcel@rigtr12:~$ date
Sat Feb  8 17:23:39 UTC 2025
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* Connected to 212.53.215.173 (212.53.215.173) port 80
> GET / HTTP/1.1
> Host: 212.53.215.173
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Sat, 08 Feb 2025 17:23:46 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Content-Type: text/html
< 
<!doctype html>
<html>
</html>
<!-- AF:1739035389:OK -->
* Connection #0 to host 212.53.215.173 left intact
marcel@rigtr12:~$ date
Sat Feb  8 17:23:48 UTC 2025
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* Connected to 212.53.215.173 (212.53.215.173) port 80
> GET / HTTP/1.1
> Host: 212.53.215.173
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Sat, 08 Feb 2025 17:23:55 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Content-Type: text/html
< 
<!doctype html>
<html>
</html>
<!-- AF:1739035389:OK -->
* Connection #0 to host 212.53.215.173 left intact
marcel@rigtr12:~$ date
Sat Feb  8 17:23:56 UTC 2025
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* Connected to 212.53.215.173 (212.53.215.173) port 80
> GET / HTTP/1.1
> Host: 212.53.215.173
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Sat, 08 Feb 2025 17:24:06 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Content-Type: text/html
< 
<!doctype html>
<html>
</html>
<!-- AF:1739035389:OK -->
* Connection #0 to host 212.53.215.173 left intact
marcel@rigtr12:~$ date
Sat Feb  8 17:24:09 UTC 2025
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* Connected to 212.53.215.173 (212.53.215.173) port 80
> GET / HTTP/1.1
> Host: 212.53.215.173
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Sat, 08 Feb 2025 17:24:17 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Content-Type: text/html
< 
<!doctype html>
<html>
</html>
<!-- AF:1739035448:OK -->
* Connection #0 to host 212.53.215.173 left intact
marcel@rigtr12:~$ date
Sat Feb  8 17:24:19 UTC 2025
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* Connected to 212.53.215.173 (212.53.215.173) port 80
> GET / HTTP/1.1
> Host: 212.53.215.173
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Sat, 08 Feb 2025 17:24:29 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Content-Type: text/html
< 
<!doctype html>
<html>
</html>
<!-- AF:1739035448:OK -->
* Connection #0 to host 212.53.215.173 left intact
marcel@rigtr12:~$ date
Sat Feb  8 17:24:32 UTC 2025
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* Connected to 212.53.215.173 (212.53.215.173) port 80
> GET / HTTP/1.1
> Host: 212.53.215.173
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Sat, 08 Feb 2025 17:24:50 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Content-Type: text/html
< 
<!doctype html>
<html>
</html>
<!-- AF:1739035448:OK -->
* Connection #0 to host 212.53.215.173 left intact
marcel@rigtr12:~$ date
Sat Feb  8 17:24:52 UTC 2025
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* Connected to 212.53.215.173 (212.53.215.173) port 80
> GET / HTTP/1.1
> Host: 212.53.215.173
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Sat, 08 Feb 2025 17:25:00 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Content-Type: text/html
< 
<!doctype html>
<html>
</html>
<!-- AF:1739035448:OK -->
* Connection #0 to host 212.53.215.173 left intact
marcel@rigtr12:~$ date
Sat Feb  8 17:25:02 UTC 2025
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* Connected to 212.53.215.173 (212.53.215.173) port 80
> GET / HTTP/1.1
> Host: 212.53.215.173
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Sat, 08 Feb 2025 17:25:04 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Content-Type: text/html
< 
<!doctype html>
<html>
</html>
<!-- AF:1739035448:OK -->
* Connection #0 to host 212.53.215.173 left intact
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* connect to 212.53.215.173 port 80 from 192.168.15.112 port 53754 failed: No route to host
* Failed to connect to 212.53.215.173 port 80 after 1 ms: Couldn't connect to server
* Closing connection
curl: (7) Failed to connect to 212.53.215.173 port 80 after 1 ms: Couldn't connect to server
marcel@rigtr12:~$ date
Sat Feb  8 17:25:08 UTC 2025
marcel@rigtr12:~$ curl -v http://212.53.215.173
*   Trying 212.53.215.173:80...
* Connected to 212.53.215.173 (212.53.215.173) port 80
> GET / HTTP/1.1
> Host: 212.53.215.173
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Sat, 08 Feb 2025 17:25:12 GMT
< Server: Apache
< Upgrade: h2,h2c
< Connection: Upgrade
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Content-Type: text/html
< 
<!doctype html>
<html>
</html>
<!-- AF:1739035507:OK -->
* Connection #0 to host 212.53.215.173 left intact
marcel@rigtr12:~$ date
Sat Feb  8 17:25:13 UTC 2025

Alles anzeigen

Oben schön zu sehen, die ersten Versuche schlagen fehl, dann funktionieren einige, dann schlägt wieder eine Fehl und die danach funktioniert wieder. Resetted wird die Verbindung mit einem "No route to host" aus dem DG Netz.. Das ist vermutlich dann der NAT Server o.ä. der meldet dass keine Ports mehr frei sind ?

Mit MTR sieht der Trace sauber aus zu dem jeweiligen host - das ist aber immer so.

Über IPv6 gibt es keine Probleme.

Mein Router ist eine pfSense Box die selbstverständlich auch NAT'ed.

kreppelesser

Nope, wenn die Verbindung mal steht ist alles okay, allerdings bricht sie bei mtr z.b. sporadisch irgendwann mal mit dem genannten "Host unreachable" ab. Es fühlt sich so an, als wäre z.B. der AFTR am Limit und kann keine weitere Verbindungen mehr handlen und sendet dann einfach ein "Host unreachable" zurück. Es ist dann immer der Host 94.31.72.86 im DG Netz der diesen Reset auslöst - wenn man wüsste was der macht.

kreppelesser

Hi,

ca. 1 1/2 Jahre lief DG bei mir problemlos. Sowie IPv4 / CGNAT als auch IPv6. Speeds waren auch immer top.

Realisiert ist das alles bei mir über ein Nokia ONT mit einer pfSense FW und ubqiuti / unifi switches/wifi Router.

Seit ca. 3 Wochen habe ich über Nacht das Problem, daß ausschließlich bei IPv4 Verbindungen connection resets auftreten d.h.

ein Router im Netz von DG meldet "host unreachable" und damit bricht die Verbindung ab. Schön zu sehen wenn man z.B. auf http://www.bild.de geht und dort viele kleine Werbeanzeigen bzw. externe Bilder geladen werden - ca. 50% der Bilder werden nicht geladen und mit einer Fehlermeldung markiert. Refresht man dann einfach werden genau diese Bilder dann geladen, andere dafür aber nicht d.h. es wird immer nur ein Teil geladen und die anderen requests abgebrochen.

Wireshark hab ich mal laufen lassen und der Host im Netz der DG 94.31.72.86 meldet "Destination unreachable" und bricht somindest die Verbindung ab. Bei einem einfach Reload klappt die Verbindung dann wieder, beim nächsten Reload ist sie wieder unreachable. Wireshark schreibt dazu noch "Communication administratively filtered". das geschieht NUR bei IPv4, IPv6 funzt immer problemlos.

Selbstverständlich sind alle Versuche dieses Fehlerbild bei der DG Hotline zu schildern unmöglich - Wireshark kennt an der Hotline keiner, laut deren gibt es keine Störung im Netz und alles ist okay. Ich soll meinen Router neu starten, den ONT für 24h stromlos machen und es neu versuchen usw.

Hat jemand noch eine Idee wie ich an einen 2nd Level Support kommen kann um evtl. denen mal das Problem zu schildern ?

Beiträge von kreppelesser

Routing-Probleme IPv4(!) Deutsche Glasfaser (connection resets)

Routing-Probleme IPv4(!) Deutsche Glasfaser (connection resets)

Routing-Probleme IPv4(!) Deutsche Glasfaser (connection resets)

Routing-Probleme IPv4(!) Deutsche Glasfaser (connection resets)

Routing-Probleme IPv4(!) Deutsche Glasfaser (connection resets)

Routing-Probleme IPv4(!) Deutsche Glasfaser (connection resets)

Routing-Probleme IPv4(!) Deutsche Glasfaser (connection resets)

Routing-Probleme IPv4(!) Deutsche Glasfaser (connection resets)

Routing-Probleme IPv4(!) Deutsche Glasfaser (connection resets)

Wir respektieren Deine Privatsphäre

Cookie-Einstellungen