Unitymedia Firewall hinter FB 6490 und die richtigen IP Settings / Umstellung auf RIP FW 6.75

[thomas_lange]

Hä?

Welche IPv4 bekommt der Server? Wohl eine Private aus dem 192.168.1/24 Netz sonst wäre kein exposted host nötig.

Das ist natürlich völliger quatsch und statisch ist die IPv4 nicht.

Gesendet von meinem SM-G935F mit Tapatalk

Die IP muss bei RIP statisch am Server eingetragen werden (siehe oben eth0 xx.62)

 

[tq1199]

Es kommt mir so vor, als wäre SSH auf die statische IP vom FB LAN aus in der FB geblockt... ... bloß wo? Jedenfalls nicht von meinem Server.

Nein, dass kann nicht sein, denn wenn auf der FB geblockt wird dann alles. D. h. auch die Ports 80 bzw. 443, aber die sind lt. deiner Aussage ja offen bzw. erreichbar.

Warum postest Du den externen Zugriff auf den Port 22 und dann noch auf diese Art und Weise anonymisiert?

Verwende den richtigen Filter für tcpdump (wenn Du den Zugriff aus dem LAN der FB sniffen willst), starte tcpdump (auf dem Server) schon vor dem Portscan und poste die Ausgabe von tcpdump richtig bzw. brauchbar anonymisiert. Hast Du nur ssh-Zugang zum Server? Wenn ja, dann verbinde zwecks Start von tcpdump, von einem anderen fremden Internetanschluss.

<i>
</i>tcpdump -c 40 -vvven port 22 and host <source-Host-aus-dem-internen-FB-Netz>

"<source-Host-aus-dem-internen-FB-Netz>" kannst Du durch sniffen (auf dem server) des Portscans auf Port 80 aus dem Internen Netz der FB, feststellen:

<i>
</i>tcpdump -c 40 -vvven port 80

 

[thomas_lange]

Tja, dass das nicht sein kann, darüber bin ich schon hinaus .. - es ist aber so!

Hier der Beweis:

tcpdump auf port 21

<i>
</i> tcpdump -c 40 -vvven port 21 and host 192.168.10.123
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:43:15.085215 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:78:55, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 127, id 21698, offset 0, flags [DF], proto TCP (6), length 52) 192.168.10.123.60289 > XXX.XXX.XXX.62.21: Flags [S], cksum 0x0138 (correct), seq 619731104, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:43:15.087536 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:78:55, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 127, id 21699, offset 0, flags [DF], proto TCP (6), length 40) 192.168.10.123.60289 > XXX.XXX.XXX.62.21: Flags [.], cksum 0x0e2e (correct), seq 619731105, ack 1394858650, win 256, length 0
11:43:15.104638 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:78:55, ethertype IPv4 (0x0800), length 75: (tos 0x0, ttl 127, id 21700, offset 0, flags [DF], proto TCP (6), length 61) 192.168.10.123.60289 > XXX.XXX.XXX.62.21: Flags [P.], cksum 0xde91 (correct), seq 0:21, ack 66, win 256, length 21: FTP, length: 21
11:43:15.106790 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:78:55, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 127, id 21701, offset 0, flags [DF], proto TCP (6), length 40) 192.168.10.123.60289 > XXX.XXX.XXX.62.21: Flags [.], cksum 0x0dc6 (correct), seq 21, ack 84, win 256, length 0
11:43:15.107212 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:78:55, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 127, id 21702, offset 0, flags [DF], proto TCP (6), length 43) 192.168.10.123.60289 > XXX.XXX.XXX.62.21: Flags [P.], cksum 0xe9bb (correct), seq 21:24, ack 87, win 256, length 3: FTP, length: 3
11:43:15.163870 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:78:55, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 127, id 21703, offset 0, flags [DF], proto TCP (6), length 40) 192.168.10.123.60289 > XXX.XXX.XXX.62.21: Flags [.], cksum 0x0dbd (correct), seq 24, ack 90, win 256, length 0
11:43:22.091059 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:78:55, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 127, id 21704, offset 0, flags [DF], proto TCP (6), length 44) 192.168.10.123.60289 > XXX.XXX.XXX.62.21: Flags [P.], cksum 0x32c7 (correct), seq 24:28, ack 90, win 256, length 4: FTP, length: 4 quit[!ftp]
11:43:22.091096 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:78:55, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 127, id 21705, offset 0, flags [DF], proto TCP (6), length 42) 192.168.10.123.60289 > XXX.XXX.XXX.62.21: Flags [P.], cksum 0x00a5 (correct), seq 28:30, ack 90, win 256, length 2: FTP, length: 2
11:43:22.095561 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:78:55, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 127, id 21706, offset 0, flags [DF], proto TCP (6), length 40) 192.168.10.123.60289 > XXX.XXX.XXX.62.21: Flags [.], cksum 0x0da8 (correct), seq 30, ack 105, win 256, length 0
11:43:22.098040 cc:ce:1e:a5:15:bd > XX:XX:XX:XX:78:55, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 127, id 21707, offset 0, flags [DF], proto TCP (6), length 40) 192.168.10.123.60289 > XXX.XXX.XXX.62.21: Flags [F.], cksum 0x0da7 (correct), seq 30, ack 105, win 256, length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

Und hier der Tote dump auf Port 22 bis zum Timeout:

<i>
</i>tcpdump -c 40 -vvven port 22 and host 192.168.10.123
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Wie gesagt,- Firwall ist am Client und am Server aus ..


Und nun kommst Du :zwinker:

 

[tq1199]

Und hier der Tote dump auf Port 22 bis zum Timeout:

Wie gesagt,- Firwall ist am Client und am Server aus ..

Welche Betriebssysteme (Versionen) hast Du auf Client bzw. Server?

EDIT:

Kannst Du von deinem Client, den Port 22 der IP-Adresse 213.95.41.4 erfolgreich scannen?

 

[thomas_lange]

Und hier der Tote dump auf Port 22 bis zum Timeout:

Wie gesagt,- Firwall ist am Client und am Server aus ..

Welche Betriebssysteme (Versionen) hast Du auf Client bzw. Server?

EDIT:

Kannst Du von deinem Client, den Port 22 der IP-Adresse 213.95.41.4 erfolgreich scannen?

ssh 213.95.41.4
The authenticity of host '213.95.41.4 (213.95.41.4)' can't be established.
ECDSA key fingerprint is SHA256:tm7uaL1TahDPG1DZ6Je9eihsNadlAQDwbZWlS8OeM7E.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '213.95.41.4' (ECDSA) to the list of known hosts.
Permission denied (publickey).

 

[tq1199]

Are you sure you want to continue connecting (yes/no)? ...

OK, dann bleibt m. E. nur noch die Infrastruktur für dein "HP MicroServer Gen8 mit ESXi 6.0 und Debian 9 VM für OwnCloud" übrig.

 

[thomas_lange]

Are you sure you want to continue connecting (yes/no)? ...

OK, dann bleibt m. E. nur noch die Infrastruktur für dein "HP MicroServer Gen8 mit ESXi 6.0 und Debian 9 VM für OwnCloud" übrig.

Da passt alles. Ich denke das ist in der FB Firmware ein Fehler. Ich habe ein Ticket bei AVM aufgemacht
Wie geschrieben, die gleiche Hardware/Software (FB 6490, Feste IP, HP ESXi Debian) läuft an Standort 2 perfekt, einziger Unterschied, FB FW 6.50 und Bridged Mode

Ich finde es ne Schweinerei von UM das die so eine buggi FW auf ihre Business Kunden loslassen :sauer:

 

[Gast20846]

Hallo,

das gleiche Problem habe ich mit RIP auch. Ich gehe auch davon aus, dass es sich um ein Firmware Problem handelt. Mein Ticket bei AVM ist ca. eine Woche offen, bisher keine Rückmeldung. AVM hat sich meinen Thread dazu angesehen. Verweise AVM doch auch mal hierher, vielleicht hilft in der Kram weiter oben ja.

Gruß
vsnap

 

[tq1199]

... läuft an Standort 2 perfekt, einziger Unterschied, FB FW 6.50 und Bridged Mode

Naja, wir vergleichen nicht den "Bridge Mode" mit RIP, sondern wir fragen uns, warum bei _RIP_ (und deiner Konstellation) die Ports 21, 80 und 443 _funktionieren_ aber der Port 22 nicht funktioniert (d. h. nicht durchgereicht wird)? Ist das evtl. deshalb so, weil die FB auch auf den Ports 21, 80, 443 lauscht?

Du könntest auch andere Ports (z. B. 23 oder 4444), mit einem Portscanner (nicht mit einem Client-daemon!) und tcpdump testen. Die FB sollte jeden Port (oder gar keinen Port) "durchlassen".

 

[thomas_lange]

Also heute hatte ich mit AVM und UM Kontakt.

AVM empfieht die neuste Firmware .... Es ist bekannt, das bei der 6.75 Probleme bestehen ....

UM hat meine Box heute testweise auf Dualstack und damit auf Bridged Mode umgestellt, und schon waren die IPv6 Probleme behoben. UM geht von einem Defekt der FB aus, zumal ja nicht nur e i n Problem vorliegt. Die FB macht im RIP Mode kein gescheites Routing - Umsetzung auf 6to4 geht nicht, und vermutlich ist daher auch das SSH Routing fehlerhaft.

Melde mich wieder wenn die Box getauscht worden ist.

 

[thomas_lange]

Nachtrag:
Nach längerem tüfteln kann ich zwei Punkte (2,3) von meiner Liste streichen.

1. FB verliert Konfig nach reboot - FW Problem - abwarten
4. IPv6 nicht erreichbar in RIP Modus - FB Tausch abwarten

2. DNS Probleme - da die FB den DNS nich gescheit auflösen tut, habe ich einen eigenen DNS Server aufgesetzt, den weise ich per DHCP den Clients zu. Sowohl für IPv4 als auch für IPv6.

3. Mit Punkt 2 wurde erstaunlicherweise auch das SSH Problem behoben. Logisch erklären kann ich mir das aber nicht. Schließlich ging die SSH auf den Server auch auf IP nicht durch. Aber mit meinem eigenen DNS Server im FB Netz und im Server mit fester IP geht nun alles durch. Nicht vergessen sollte ich das ich unter Heimnetz IPv4 Routen für das Server Subnetz die FB IP als Gateway rein habe.

Bin gespannt ob mit der neuen FB das IPv6 geht. Vermutlich wird sich bei funktionierendem IPv6 das DNS Problem lösen und der interne DNS Server obsolet.

 

[tq1199]

3. Mit Punkt 2 wurde erstaunlicherweise auch das SSH Problem behoben. Logisch erklären kann ich mir das aber nicht.

Das wird, wie bereits vermutet, etwas mit deiner sshd-Konfiguration zu tun haben. Z. B.:

UseDNS

Specifies whether sshd(8) should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is 'yes'.

Schließlich ging die SSH auf den Server auch auf IP nicht durch.

Hast Du zum scannen, nur den ssh-Client verwendet oder auch mal einen _richtigen_ Portscanner, wie z. B. nmap (oder gleichwertig)?

Vermutlich wird sich bei funktionierendem IPv6 das DNS Problem lösen und der interne DNS Server obsolet.

Welche (v4/v6)DNS-Server deine FritzBox konfiguriert hat bzw. benutzt, kannst Du z. B. mit:

<i>
</i>host -t A dns.fritz.box <interne-IP-Adresse-FritzBox>
host -t AAAA dns.fritz.box <interne-IP-Adresse-FritzBox>

(ohne spitze Klammern) aus deinem W/LAN feststellen.

Die "query time" für einen (v4/v6)DNS-Server kannst Du z. B. mit:

<i>
</i>dig -4 a @<IPv4-Adresse-DNS-Server> heise.de | grep msec -A1
dig -6 aaaa @<IPv6-Adresse-DNS-Server> heise.de | grep msec -A1

(ohne spitze Klammern) feststellen.

Ob ein (v4/v6)DNS-Server gerade erreichbar ist, kannst Du auch per (v4/v6)TCP-Portscan feststellen. Z. B.:

<i>
</i>nc -zv 9.9.9.9 53
nc -zv -6 2620:0:ccc::2 53

 

[thomas_lange]

Zu Punkt 1. Bleibt zu hoffen, dass das hier Abhilfe schafft: https://community.unitymedia.de/articles/neuigkeiten-zum-fritzbox-6490-firmware-update

Zu Punkt 2-4:
Das mit dem IPv6 was nicht stimmt ist definitiv so.

Der UM Techniker hat die Box auf Dual Stack umgestellt und sofort hat das IPv6 (6to4) funktioniert. Nach dem zurückstellen auf RIP ist die FB auf ihrer IPv6 nicht erreichbar. Sie bekommt eine IPv6 (2002:xxxx) aber die ist weder von extern erreichbar noch setzt die FB das 6to4 um. "Leider" gibt die FB per DHCP im FB LAN sich selbst als DNS Server raus (auch im IPv6), da das IPv6 aber nicht geht, bekommen Clients die sowohl IPv4 und IPv6 haben Probleme. Daher mein eigener DNS Server, den gebe ich per DHCP im IPv4 und IPv6 raus und schon klappt intern IPv4 und IPv6. Da meine externe Verbindung für IPv6 aber TOD ist (vermutlich deshalb RIP), ist da halt Schluss. Mal abwarten was mit der neuen FB passiert.

 

[tq1199]

Der UM Techniker hat die Box auf Dual Stack umgestellt und sofort hat das IPv6 (6to4) funktioniert.

Aber mit Dual Stack hat man doch _natives_ IPv6. Bist Du sicher, dass es das 6to4-IPv6 war, das mit Dual Stack funktioniert hat?

 

[thomas_lange]

Ja, laut UM.

 

[tq1199]

Ja, laut UM.

Wieso lt. UM? Wenn Du eine FritzBox mit Dual Stack hast und Du willst statt Dual Stack das 6to4-IPv6 verwenden, dann musst doch Du als user/Kunde das auch in deiner FritzBox so konfigurieren, oder?

Hast Du das native IPv6 deaktiviert und in deiner FritzBox, das 6to4-IPv6 konfiguriert?

 

[thomas_lange]

Die Box ist im RIP Modus. IPv6 ist auch aktiv.

Techniker hat die Box getestet, macht keine 6to4 Umsetzung. Die Box bekommt zwar eine IPv6 aber das war's. Ein und ausgehende IPv6 Anfragen sterben in der Box.

Morgen kommt die neue Box (hoffentlich).

 

[tq1199]

Techniker hat die Box getestet, macht keine 6to4 Umsetzung. Die Box bekommt zwar eine IPv6 aber das war's. Ein und ausgehende IPv6 Anfragen sterben in der Box.

OK, das ist ja Alles schön und gut, aber was hat das mit folgender Aussage von dir, zu tun?

Ja, laut UM.

(siehe oben).

Wenn Du statt "laut UM." geschrieben hättest, dass Du das mit Hilfe des IPv6-Präfixes der öffentlichen IPv6-Adresse der FB festgestellt hast, wäre alles OK gewesen.

 

[thomas_lange]

Der UM Techniker hat die Box auf Dual Stack umgestellt und sofort hat das IPv6 (6to4) funktioniert.

Aber mit Dual Stack hat man doch _natives_ IPv6. Bist Du sicher, dass es das 6to4-IPv6 war, das mit Dual Stack funktioniert hat?

Ja, laut UM. Er hat sie auf Dualstack gestellt. Da ging IPv6 und dann wieder in RIP = Tod.

 

[thomas_lange]

Also neue FB ist da. Wieder mit FW 6.75. Die behält ihre Settings auch nach dem Reboot. Routing auf die statische (öffentliche) IP geht auch durch - so weit so gut!

ABER: IPv6 geht immer noch nicht,- schnellerer Anschluss, neuer Vertrag, neue FB, - aber neueste Technik (IPv6) Fehlanzeige. UM prüft gerade warum die FB kein 6to4 macht, nicht mal innerhalb des UM Netzes. Alle aus- oder eingehenden IPv6 Anfragen sterben an der FB. Intern werden den Clients (wie auch der FB) IPv6 Adressen (2002 zugewiesen. Und intern ist auf IPv6 auch alles erreichbar. Aber sobald es über die FB raus gehen soll ist Ende - Gelände.....


Für alle die sich fragen wie die statisch IP bei RIP zu vergeben ist, hier eine Anleitung:

1. Internet > Zugangsart > Portkonfiguration > LAN auswählen an dem der eigene Router/Server hängt
2. Internet > Zugangsart > Portfreigaben > dein eigenen Server/Router als "Exposed Host" einrichten
# der Schritt ist nur nötig wenn der Server in der "DMZ" auch vom LAN erreichbar sein soll
3. Heimnetz > Heimnetzübersicht > Netzwerkeinstellungen > IPv4 Routen > Route auf Server/Router Subnetz und GW auf FB IP

Viel Spaß!

PS: Ich bin gespannt was UM herausfindet wegen dem IPv6 Bug!

 

[tq1199]

Intern werden den Clients (wie auch der FB) IPv6 Adressen (2002 zugewiesen. Und intern ist auf IPv6 auch alles erreichbar. Aber sobald es über die FB raus gehen soll ist Ende - Gelände.....

Teste mal ob das gateway über seine Anycast-IP-Adresse 192.88.99.1 erreichbar ist:

<i>
</i>ping -c 3 -W 2 192.88.99.1

und ob als 2. hop, (nach der IPv6 der FB) diese 6to4-IPv6-Adresse 2002:c058:6301::1 in einem traceroute, angezeigt wird:

<i>
</i>mtr -6nr -c 1 heise.de

(oder gleichwertig).

 

[thomas_lange]

<i>
</i>ping -c 3 -W 2 192.88.99.1
PING 192.88.99.1 (192.88.99.1) 56(84) bytes of data.
64 bytes from 192.88.99.1: icmp_seq=1 ttl=50 time=24.8 ms
64 bytes from 192.88.99.1: icmp_seq=2 ttl=50 time=31.6 ms
64 bytes from 192.88.99.1: icmp_seq=3 ttl=50 time=23.0 ms
--- 192.88.99.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 23.081/26.540/31.653/3.689 MS
mtr -6nr -c 1 heise.de
Start: Fri Feb 16 10:41:42 2018
HOST: oc Loss% Snt Last Avg Best Wrst StDev 1.|-- 2002:xxxx:xxxx:xxxx:xxxx:6df 0.0% 1 0.5 0.5 0.5 0.5 0.0 2.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0

 

[tq1199]

mtr -6nr -c 1 heise.de

<i>
</i>Start: Fri Feb 16 10:41:42 2018
HOST: oc Loss% Snt Last Avg Best Wrst StDev 1.|-- 2002:####:####:0:464e:6df 0.0% 1 0.5 0.5 0.5 0.5 0.0 2.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0

OK, dann geht es nicht.
BTW: Anonymisieren die 6to4-IPv6-Adresse deiner FB, denn damit kann man die jetzige externe IPv4-Adresse deiner FB ermitteln.

 

[Gast20846]

Update von AVM: Es liegt wohl daran, dass meine 7490 am LAN Port 3 der 6490 hängt. Dort geht der Zugriff auf die 6490 dann wohl nicht. Ich müsste die 7490 auf Port 1 hängen. Das geht aber nicht, weil Unitymedia mit nur Port 2-4 für die statische IP erlaubt. Port 1 ist in der Auswahl nicht vorhanden. Bin gespannt auf das Feedback von AVM.

 

[thomas_lange]

Der UM Techniker hat die Box auf Dual Stack umgestellt und sofort hat das IPv6 (6to4) funktioniert.

Aber mit Dual Stack hat man doch _natives_ IPv6. Bist Du sicher, dass es das 6to4-IPv6 war, das mit Dual Stack funktioniert hat?

Ja, in dem Modus kann ich beides auswählen, natives IPv6 oder 6to4 ... beides geht.
Ich bekomme entweder eine 2c01 oder 2002 Adresse ....