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

[Andreas1969]

Welche dynamische IP-Adresse seiner FritzBox meinst Du?

Wenn die FB selbst ne dynamische IP bekommt, würde das so einiges erklären, ist das wirklich so :kratz:

 

[tq1199]

Wenn die FB selbst ne dynamische IP bekommt, würde das so einiges erklären, ist das wirklich so :kratz:

Lt. meinem traceroute gibt es keine dynamische IP seiner FB:

<i>
</i>:~ $ mtr -4nr -i2 -c 2 78.94.###.#1
Start: Tue Oct 3 12:14:51 2017
HOST: xxxxxx Loss% Snt Last Avg Best Wrst StDev 1.|-- ##.##.##.1 0.0% 2 9.0 8.4 7.8 9.0 0.0 2.|-- 172.30.10.117 0.0% 2 26.6 22.3 18.0 26.6 6.1 3.|-- 84.116.190.21 0.0% 2 12.0 13.8 12.0 15.6 2.4 4.|-- 84.116.196.197 0.0% 2 13.1 12.6 12.2 13.1 0.0 5.|-- 84.116.196.17 0.0% 2 11.7 11.6 11.6 11.7 0.0 6.|-- 80.69.106.210 0.0% 2 12.5 13.7 12.5 15.0 1.7 7.|-- 84.116.197.65 0.0% 2 15.8 16.7 15.8 17.6 1.0 8.|-- 84.116.196.198 0.0% 2 32.4 24.9 17.4 32.4 10.6 9.|-- 84.116.191.50 0.0% 2 16.9 19.2 16.9 21.6 3.3 10.|-- 172.30.12.34 0.0% 2 11.9 11.9 11.8 11.9 0.0 11.|-- 78.94.###.#1 0.0% 2 19.9 23.8 19.9 27.7 5.4

Hop 10 vor der externen/öffentlichen IP seiner FB, hat die private IP 172.30.12.34.

 

[tomcatcw]

Also so langsam blicke ich es nicht mehr. Warum muss das so kompliziert bei UM sein. Die FB weist auf der Startseite das GW xx.xx.xx.41 aus. Richtig so, nehme ich an.

Im Ereignis Log steht auch: Internetverbindung wurde erfolgreich hergestellt. IP-Adresse 149.xx.xx.xx, DNS-Server 80.69.96.12 und 81.210.129.4, Gateway 149.xx.xx.1

Warum steht da nun diese IP? Das ist doch Mist, was macht UM da?

 

[Andreas1969]

Im Ereignis Log steht auch: Internetverbindung wurde erfolgreich hergestellt. IP-Adresse 149.xx.xx.xx, DNS-Server 80.69.96.12 und 81.210.129.4, Gateway 149.xx.xx.1

Das ist doch eine dynamische IP :winken:

 

[tq1199]

Im Ereignis Log steht auch: Internetverbindung wurde erfolgreich hergestellt. IP-Adresse 149.xx.xx.xx, ...

OK, dann ist mit dynamischer IP, die IP 149.xx.xx.xx gemeint. Diese dynamische IP wird bei meinem traceroute vom UM-Anschluss auf die statische IP (78.94.###.#1) der FB, (als Hop) nicht angezeigt.

 

[tomcatcw]

Vom Webserver selbst komme ich raus. Das sieht dann so aus:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 10.0.40.1 (10.0.40.1) 0.219 ms 0.237 ms 0.253 ms 2 b2b-xx-xx-xx-xx.unitymedia.biz (xx.xx.xx.41) 0.585 ms 0.651 ms 0.638 ms 3 HSI-KBW-134-3-248-1.hsi14.kabel-badenwuerttemberg.de (134.3.248.1) 10.984 ms 17.021 ms 17.070 ms 4 172.30.12.89 (172.30.12.89) 18.025 ms 18.010 ms 18.004 ms 5 de-fra01b-rc1-ae32-0.aorta.net (84.116.191.49) 26.969 ms 26.047 ms 26.950 ms 6 de-fra03b-ri1-ae10-0.aorta.net (84.116.132.178) 38.912 ms 37.704 ms 19.196 ms 7 213.46.177.42 (213.46.177.42) 24.377 ms 27.101 ms 27.088 ms 8 * 108.170.251.193 (108.170.251.193) 20.541 ms 108.170.251.129 (108.170.251.129) 25.181 ms 9 216.239.59.187 (216.239.59.187) 25.254 ms 72.14.239.109 (72.14.239.109) 25.173 ms 216.239.48.79 (216.239.48.79) 25.156 ms
10 google-public-dns-a.google.com (8.8.8.8) 23.852 ms 25.003 ms 23.776 ms

Dagegen bei

traceroute to xx.xx.x.41 (xx.xx.xx.41), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *

Habt ihr keine Idee? Kann man es nicht eingrenzen, Stück für Stück?

Mit der Eintragung eines Reverse-DNS-Eintrags hat es doch nichts zu tun oder?

 

[Andreas1969]

So, wie ich das sehe, bekommt die FB eine dynamische IP und Gateway und darüber werden dann die statischen Adressen geroutet.
Die Bridge selber bekommt aber auch eine dynamische IP und Gateway, welches sich aber von der dynamischen IP der FB unterscheidet.
Dummerweise wird aber im LOG der FB nur die dynamische IP der FB angezeigt, nicht aber die der Bridge (ist bei mir auch so).
Versuch doch mal folgendes:
- alle Netzwerkgeräte von der FB trennen
- einen Rechner per DHCP an die Bridge der FB hängen

Normalerweise müsste sich der jetzt die dynamische IP und das Gateway der Bridge ziehen.
Dann wären wir schon mal einen Schritt weiter.

 

[tq1199]

Vom Webserver selbst komme ich raus. Das sieht dann so aus:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 10.0.40.1 (10.0.40.1) 0.219 ms 0.237 ms 0.253 ms 2 b2b-xx-xx-xx-xx.unitymedia.biz (xx.xx.xx.41) 0.585 ms 0.651 ms 0.638 ms

Wie sind auf dem Webserver die Ausgaben von:

<i>
</i>ip a
route -n
arp -av
dig +short myip.opendns.com @208.67.222.222

oder statt dig:

<i>
</i>nslookup myip.opendns.com 208.67.222.222

?

 

[tomcatcw]

ip a

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever
91: eth0@if92: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:25:d3:d9:0e:2d brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.0.40.12/24 brd 10.0.40.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::e425:d3ff:fed9:e2d/64 scope link valid_lft forever preferred_lft forever

route -n

route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.40.1 0.0.0.0 UG 0 0 0 eth0
10.0.40.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

arp -av

arp -av
? (10.0.40.1) at 00:0d:b9:3f:e0:a0 [ether] on eth0
Entries: 1 Skipped: 0 Found: 1

dig +short myip.opendns.com @208.67.222.222

dig +short myip.opendns.com @208.67.222.222
xx.xx.xx.43

nslookup myip.opendns.com 208.67.222.222

nslookup myip.opendns.com 208.67.222.222
Server: 208.67.222.222
Address: 208.67.222.222#53
Non-authoritative answer:
Name: myip.opendns.com
Address: xx.xx.xx.43

 

[tomcatcw]

So, wie ich das sehe, bekommt die FB eine dynamische IP und Gateway und darüber werden dann die statischen Adressen geroutet.
Die Bridge selber bekommt aber auch eine dynamische IP und Gateway, welches sich aber von der dynamischen IP der FB unterscheidet.
Dummerweise wird aber im LOG der FB nur die dynamische IP der FB angezeigt, nicht aber die der Bridge (ist bei mir auch so).
Versuch doch mal folgendes:
- alle Netzwerkgeräte von der FB trennen
- einen Rechner per DHCP an die Bridge der FB hängen

Normalerweise müsste sich der jetzt die dynamische IP und das Gateway der Bridge ziehen.
Dann wären wir schon mal einen Schritt weiter.

Das hatte ich schon mal probiert, bekomme aber keine IP per DHCP zugewiesen.

 

[Andreas1969]

Das hatte ich schon mal probiert, bekomme aber keine IP per DHCP zugewiesen.

Vielleicht kann man das ja im erweiterten LOG der FB sehen, muss ich auch selbst mal nachschauen.

 

[Andreas1969]

Bei mir sieht das folgendermaßen aus:

Die FB bekommt die dynamische IP 62.143.xxx.yyy / Gateway 62.143.120.1
Die Bridge bekommt die dynamische IP 5.146.xxx.yyy / Gateway 5.146.16.1


Wie man sieht, ist das Gateway für die Bridge ein ganz anderes.

 

[tomcatcw]

Hast du denn auch einen UM-Business-Anschluss mit fester zugeordneter IP mit Gateway und allem genannt bekommen? Nicht das wir Äpfel mit Birnen vergleichen.

 

[Andreas1969]

Hast du denn auch einen UM-Business-Anschluss mit fester zugeordneter IP mit Gateway und allem genannt bekommen? Nicht das wir Äpfel mit Birnen vergleichen.

Nein, Privatanschluss mit 2 dynamischen IP'S
Könnte mir aber vorstellen, dass die Bridge bei den neuen Business Anschlüssen ähnlich läuft.

 

[addicted]

Andreas: Dein Anschluss ist grundverschieden. Businessanschlüsse mit RIP haben keine Bridge für den nachgelagerten Router.

Wenn RIP aktiviert ist, wie es angeblich ja sein sollte, dann fungiert die FB für den nachgelagerten Router als Nexthop/Default-Gateway. D.h. auf der pfSense ist die Konfiguration der WAN-Schnittstelle so:

<i>
</i>ip .42
netzmaske .40/29
default-gw .41

Die .41/29 ist auf der LAN-Seite der Fritzbox auf den Ports für das Kundennetz konfiguriert. Dass das geht, sieht man ja daran, dass ausgehende Verbindungen klappen.

Die pfSense bekommt keine IP vom Kabelnetz, weil es eben dort keine Bridge hin gibt. Stattdessen arbeitet die FB als Router (aber halt ohne NAT, wie man das ja möchte).

Eingehende Verbindungen auf diese IPs sollten nun eigentlich über die (dynamische) IP der FB geroutet werden. Zum Beispiel sieht man das, wenn man die interne IP der FB traced:

<i>
</i># traceroute -f11 -T -p 80 <IP.41>
traceroute to <IP.41> (<IP.41>), 30 hops max, 60 byte packets
11 84.116.191.50 (84.116.191.50) 18.801 ms 20.305 ms 19.739 ms
12 172.30.12.34 (172.30.12.34) 16.981 ms 17.471 ms 17.629 ms
13 HSI-KBW-149-172-<dynIP>.hsi13.kabel-badenwuerttemberg.de (149.172.<dyn-IP>) 26.741 ms !X 25.927 ms !X 26.408 ms !X

Da kommt das Prohibited-Signal von der dynamischen IP der Box.

Leider funktioniert das nicht mehr, wenn man die .43 nimmt:

<i>
</i># traceroute -f11 -T -p 80 <IP.43>
traceroute to <IP.43> (<IP.43>), 30 hops max, 60 byte packets
11 84.116.191.50 (84.116.191.50) 22.673 ms 19.686 ms 27.438 ms
12 172.30.12.34 (172.30.12.34) 16.620 ms 17.698 ms 16.276 ms
13 * * *
14 *^C

Der letzte Router bei UM meint also vielleicht, dass die IPs direkt anliegen, und nicht hinter einem Nexthop, wie es bei RIP sein sollte.
Mir ist bloß nicht klar, wieso es dann für ausgehende Verbindungen funktioniert. Daher ist für mich die wahrscheinlichste Ursache die Firewall in der Fritzbox.


Man vergleiche mit dem Netznachbarn ein /29 höher:

<i>
</i># traceroute -f11 -T -p 80 <IP.49>
traceroute to <IP.49> (<IP.49>), 30 hops max, 60 byte packets
11 172.30.21.158 (172.30.21.158) 16.681 ms 17.079 ms 24.744 ms
12 HSI-KBW-37-49-<dyn-IP>.hsi14.kabel-badenwuerttemberg.de (37.49.<dyn.IP>) 29.067 ms !X 26.735 ms !X 27.395 ms !X

# traceroute -f11 -T -p 80 <IP.50>
traceroute to <IP.50> (<IP.50>), 30 hops max, 60 byte packets
11 172.30.21.158 (172.30.21.158) 17.467 ms 17.560 ms 29.356 ms
12 b2b-<IP-50>.unitymedia.biz (<IP.50>) 27.445 ms 33.116 ms 27.614 ms
13 b2b-<IP-50>.unitymedia.biz (<IP.50>) 26.085 ms 25.167 ms 26.183 ms

Da ist die FB auch nicht mit Ihrer IP involviert.
Aber ich weiß natürlich nicht, ob dieser Kunde RIP aktiv hat oder die klassische Bridge mit im KC hinterlegten MAC-Adressen.

 

[tomcatcw]

Ok das klingt logisch, aber wo in der FB könnte eine Firewall aktiviert sein? Die ist ja erart beschnitten, dass man kaum was einstellen kann.

 

[tq1199]

Eingehende Verbindungen auf diese IPs sollten nun eigentlich über die (dynamische) IP der FB geroutet werden. Zum Beispiel sieht man das, wenn man die interne IP der FB traced:

<i>
</i># traceroute -f11 -T -p 80 <IP.41>
traceroute to <IP.41> (<IP.41>), 30 hops max, 60 byte packets
11 84.116.191.50 (84.116.191.50) 18.801 ms 20.305 ms 19.739 ms
12 172.30.12.34 (172.30.12.34) 16.981 ms 17.471 ms 17.629 ms
13 HSI-KBW-149-172-<dynIP>.hsi13.kabel-badenwuerttemberg.de (149.172.<dyn-IP>) 26.741 ms !X 25.927 ms !X 26.408 ms !X

Da kommt das Prohibited-Signal von der dynamischen IP der Box.

Ja, aber nur weil auf dem TCP-Port 80 der <IP.41> nicht gelauscht wird. Versuch mal einen tcp-traceroute auf den lauschenden TCP-Port 8089 der <IP.41>.
Dann sollte die dynamische IP der FB, als Hop nicht (mehr) angezeigt werden.

 

[tomcatcw]

Ich habe mal spaßenshalber probiert die GUI der pfSense freizugeben. Dazu 1:1 NAT an xx.xx.xx.42, die IP über die aktuell auch surfe bzw. bei wieistmeineip.de angezeigt bekomme.

Aber es funktioniert nicht. Scheinbar komme ich nicht weiter als bis zur .41 (Gateway).

Das kann doch aber alles nicht sein. 5 freie IP nichts funktioniert mit dem RIP. Bin am Verzweifeln.

 

[tq1199]

Scheinbar komme ich nicht weiter als bis zur .41 (Gateway).

Hast Du die pfSense (IP .42) so konfiguriert, dass diese, aus dem Internet ankommende Pings (icmp echo requests) ignoriert?

 

[tomcatcw]

Scheinbar komme ich nicht weiter als bis zur .41 (Gateway).

Hast Du die pfSense (IP .42) so konfiguriert, dass diese, aus dem Internet ankommende Pings (icmp echo requests) ignoriert?

Nein seitens der pfsense ist alles scheunentor mäßig offen: any/any.


Gesendet von iPhone mit Tapatalk

 

[addicted]

Ja, aber nur weil auf dem TCP-Port 80 der <IP.41> nicht gelauscht wird. Versuch mal einen tcp-traceroute auf den lauschenden TCP-Port 8089 der <IP.41>.
Dann sollte die dynamische IP der FB, als Hop nicht (mehr) angezeigt werden.

Indeed:

# traceroute -f11 -T -p 8089 <IP.41>
traceroute to <IP.41> (<IP.41>), 30 hops max, 60 byte packets
11 84.116.191.50 (84.116.191.50) 23.725 ms 22.539 ms 20.144 ms
12 172.30.12.34 (172.30.12.34) 25.716 ms 18.537 ms 26.523 ms
13 b2b-<IP-41>.unitymedia.biz (<IP.41>) 34.490 ms 27.763 ms 27.458 ms
# curl -D- <IP.41>:8089
HTTP/1.1 404 Not Found
Content-Length: 0

Klappt auch - das zeigt mal wieder, dass AVM nicht weiß, wofür administratively prohibited steht
Und was macht der TE jetzt damit?
Ich hab ja Port 80 auf der IP.43 ausprobiert, da war doch der Webserver, oder nicht?
Sieht für mich immer mehr wie ein Problem in der FB aus.

Oder vielleicht ist der RIP-Modus in der Konfig, aber nicht im Nexthop auf UM-Seite aktiv?
Dann würde die ausgehende Verbindung klappen, weil sich das CMTS beim ersten SYN die MAC merkt (quasi statt ARP), und die Antwortpakete fließen dann zurück, weil HTTP nur kurz offen ist, bevor der Router die MAC wieder verwirft?
Vielleicht klappt die eingehende Verbindung auf die .43 dann, wenn der TE einen Dauerping mitlaufen lässt?

 

[tq1199]

Nein seitens der pfsense ist alles scheunentor mäßig offen: any/any.

Wie sind auf der pfSense die Ausgaben von:

<i>
</i>ip a
route -n
arp -av
ip n s

?

 

[tomcatcw]

Die Befehle kennt pfSense leider nicht. Aber ich habe mal

netstat -nr

Routing tables
Internet:
Destination Gateway Flags Netif Expire
default x.xx.xx.41 UGS re1
10.0.8.0/24 10.0.8.2 UGS ovpns1
10.0.8.1 link#12 UHS lo0
10.0.8.2 link#12 UH ovpns1
10.0.10.0/24 link#10 U re0_vlan
10.0.10.1 link#10 UHS lo0
10.0.20.0/24 link#11 U re0_vlan
10.0.20.1 link#11 UHS lo0
10.0.30.0/24 link#8 U re0_vlan
10.0.30.1 link#8 UHS lo0
10.0.40.0/24 link#9 U re0_vlan
10.0.40.1 link#9 UHS lo0
10.74.63.0/24 link#1 U re0
10.74.63.9 link#1 UHS lo0
xx.xx.xx.40/29 link#2 U re1
xx.xx.xx.42 link#2 UHS lo0
xx.xx.xx.43 link#2 UHS lo0
80.69.100.174 xx.xx.xx.41 UGHS re1
127.0.0.1 link#7 UH lo0

 

[tomcatcw]

Mich wundert irgendwie auch, dass wenn ich ein Ping mache auf xx.xx.xx.43 scheine ich innerhalb des LAN zu bleiben, da die Antwortzeiten ziemlich kurz sind:

PING xx.xx.xx.43 (xx.xx.xx.43) from 10.0.40.1: 56 data bytes
64 bytes from 78.94.203.43: icmp_seq=0 ttl=64 time=0.275 ms
64 bytes from 78.94.203.43: icmp_seq=1 ttl=64 time=0.264 ms
64 bytes from 78.94.203.43: icmp_seq=2 ttl=64 time=0.226 ms

 

[tomcatcw]

Es ist auch folgendes zu beobachten: bevor ich von Bridge auf Rip umgestellt wurde, lief die pfsense am gebridgten LAN 4 der FB und erhielt per DHCP die statische öffentliche IP. hierfür musste man im Kundencenter die MAC Adresse hinterlegen. In dem Fall die des WAN Ports der pfsense.

In den Firewall Regeln konnte man dann unter States Traffic bzw. ankommende Anfragen beobachten. Das sah etwa so aus: 20KB/100kb.

Jetzt nach Umstellung steht nur noch 0B/0B da. Da kommt einfach nichts mehr an.

Die pfsense hängt jetzt immer noch am LAN 4 der FB. LAN 2 bis 4 sind automatisch im Bridge Modus. Also eigentlich müsste er doch alles durchleiten. Eine Firewall dürfte im Bridge Modus nicht aktiv sein.

Man bekommt von UM auch überhaupt keine Hilfe.

Habt ihr noch Ideen?


Gesendet von iPhone mit Tapatalk