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

[addicted]

Da es für zwei Adressen aus dem Netz funktioniert, würde ich das erstmal als "geht" bezeichnen. Aber Du kannst ja mal mit tcpdump checken, ob auf dem WAN-Port ARPs (oder sonstiger Traffic) für die IPs zu sehen ist.

Übrigens kannst Du virtuelle MAC-Adressen auf Interfaces konfigurieren, damit hättest Du also auch vorher schon einfach alle IPs auf die pfSense legen können.

 

[tomcatcw]

Outbound funktioniert es auch. Aber Inbound auf, d.h. von Außen auf den Webserver, geht nicht.

Du meinst per tcpdump auf der Shell von pfSense?

Welche Virtual IP Modus erzeugt denn eine virtuelle MAC-Adresse?

 

[addicted]

Outbound funktioniert es auch. Aber Inbound auf, d.h. von Außen auf den Webserver, geht nicht.

Das spielt ja für ARP und Routing keine Rolle (weil eine ausgehende Verbindung ja auch eingehende Pakete bekommt).

Du meinst per tcpdump auf der Shell von pfSense?

Yep.

Welche Virtual IP Modus erzeugt denn eine virtuelle MAC-Adresse?

Kein Plan wie man das konkret macht, ich habe keine pfSense. In Linux kannst Du verschiedene Wege nutzen, zum Beispiel macvlan.

 

[tq1199]

Outbound funktioniert es auch.

Funktioniert es outbound auch dann, wenn Du die xx.xx.xx.43 als source-IP-Adresse verwendest/mitteilst? Z. B. so:

<i>
</i>mtr -4nr -T -i 3 -c 2 -a xx.xx.xx.43 -P 53 8.8.8.8

(oder gleichwertig).

 

[tomcatcw]

Outbound funktioniert es auch.

Funktioniert es outbound auch dann, wenn Du die xx.xx.xx.43 als source-IP-Adresse verwendest/mitteilst? Z. B. so:

<i>
</i>mtr -4nr -T -i 3 -c 2 -a xx.xx.xx.43 -P 53 8.8.8.8

(oder gleichwertig).

In der pfSense kann man das in der GUI per ping oder traceroute testen, in dem man das Interface auswählt. Hier habe ich dann die virtuelle IP .43 genommen und es hat funktioniert. Deinen Befehl von oben werde ich Abend probieren.

 

[tq1199]

In der pfSense kann man das in der GUI per ping oder traceroute testen, in dem man das Interface auswählt. Hier habe ich dann die virtuelle IP .43 genommen und es hat funktioniert.

OK. Zusätzlich kannst Du in der shell der pfSense, mit z. B.:

<i>
</i>tcpdump -vvven host 8.8.8.8 and 'tcp[tcpflags] & (tcp-syn) != 0'

nachschauen, ob die IP .43 auch als source- bzw. destination-IP-Adresse verwendet wird.

 

[tomcatcw]

Werde ich heute Abend probieren und melde mich dann.

Aber rein von der Logik: Ich sehe ich den Firewall-Logs der pfSense ja nicht mal einen Eintrag, dass ich mit einer beliebigen öffentlich IP (testweise per proxy) auf den Webseite zugreife, sodass man daraus schließen könnte, dass etwas geblockt wird. Ich sehe keinen Eintrag. Liegt es nicht näher, dass UM das Routing falsch macht? So langsam stehe ich da wie eine Kuh vorm Tor. Ich kann es auch nicht eingrenzen, woher der Fehler kommen kann.

Dagegen spricht natürlich, sollte das Routing nicht funktionieren, könnte ich ja auch keine anderen x-beliebigen Webseiten aufrufen. Ich kapiere es nicht und bin am Verzweifeln, da meine Webseite offline ist.

Bin für jeden Tipp dankbar.

 

[tq1199]

Aber rein von der Logik: Ich sehe ich den Firewall-Logs der pfSense ja nicht mal einen Eintrag, dass ich mit einer beliebigen öffentlich IP (testweise per proxy) auf den Webseite zugreife, ...

Deshalb weiter oben ja auch der Vorschlag, das in der shell der pfSense, mit tcpdump zu prüfen:

<i>
</i>tcpdump -c 5 -vvven dst host xx.xx.xx.43 and icmp

 

[addicted]

Aber rein von der Logik: Ich sehe ich den Firewall-Logs der pfSense ja nicht mal einen Eintrag, dass ich mit einer beliebigen öffentlich IP (testweise per proxy) auf den Webseite zugreife, sodass man daraus schließen könnte, dass etwas geblockt wird. Ich sehe keinen Eintrag. Liegt es nicht näher, dass UM das Routing falsch macht? So langsam stehe ich da wie eine Kuh vorm Tor. Ich kann es auch nicht eingrenzen, woher der Fehler kommen kann.

Nein, es liegt näher, dass Du das falsch konfiguriert hast.
Das Routing klappt, sonst hättest Du auch keine ausgehende Konnektivität.

Kann aber durchaus sein, dass Die Fritzbox die Firewall für Dein geroutetes Netz spielt. Sollte sie halt nicht.

 

[tomcatcw]

Also ich bin am Verzweifeln. Ich komme hier definitiv nicht weiter.

Ich habe Squid und Reverse Proxy zur Sicherheit komplett deaktiviert. Per 1:1 NAT habe ich den Webserver an der Virtual IP .43 und in den Firewallrules freigeben.

Es funktioniert einfach nicht und ich behaupte weiterhin, dass es an UM liegt. Soviel kann man in der pfSense nicht einstellen. Ich habe mittlerweile alle Kombinationen durchprobiert.

Und nun das seltsame Phänoment: Ich komme von Außen definitiv nicht drauf, noch ist sie anpingbar. Aber von Intern kann ich www.meinedomain.de aufrufen.

 

[tq1199]

Und nun das seltsame Phänoment: Ich komme von Außen definitiv nicht drauf, noch ist sie anpingbar. Aber von Intern kann ich www.meinedomain.de aufrufen.

Das ist nicht seltsam, denn intern wird NAT-Loopback gemacht.

 

[addicted]

Es funktioniert einfach nicht und ich behaupte weiterhin, dass es an UM liegt. Soviel kann man in der pfSense nicht einstellen. Ich habe mittlerweile alle Kombinationen durchprobiert.

Joa, aber wenn Du nicht mal ein paar der Sachen ausprobierst, die wir hier vorschlagen, nimmt Dich irgendwann niemand mehr ernst und dieser Thread gammelt am Ende nurnoch rum, weil Dir keiner mehr helfen will.

Ruf halt den Businesskunden-Support an, wenn Du meinst es läge an UM.

 

[tomcatcw]

mtr -4nr -T -i 3 -c 2 -a xx.xx.xx.43 -P 53 8.8.8.8

habe ich eingegeben. Kennt pfSense nicht: command not found.

das ist das Ergebnis von

[2.3.4-RELEASE][[email protected]]/root: tcpdump -vvven host 8.8.8.8 and 'tcp[tcpflags] & (tcp-syn) != 0'
tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
81 packets received by filter
0 packets dropped by kernel

und das das Ergebnis von

[2.3.4-RELEASE][[email protected]]/root: tcpdump -c 5 -vvven dst host xx.xx.xx.43 and icmp
tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
21508 packets received by filter
0 packets dropped by kernel

Ich kann damit überhaupt nichts anfangen.

Mit UM habe ich in der Zwischenzeit telefoniert. Die sagen natürlich, dass es an mir liegt. Mag auch sein, aber mir gehen die Ideen aus.

Ich habe spaßenshalber mal in der pfSense unter Outband das Standard-WAN .42 auf .43 umgestellt. Und fortan zeigte mir wieistmeineip.de die .43 an. Aber warum komme ich nicht auf den Server.

Ich bin wirklich für jede Idee aufgeschlossen.

 

[addicted]

Der erste tcpdump ergibt nur Sinn parallel zum mtr-Befehl. Dann sollte er die Syn-Pakete des "Verbindungsaufbaus" zeigen.
Da wir aber mittlerweile wissen, dass es ausgehend klappt, brauchen wir das ansich nicht mehr testen.

Der zweite tcpdump ist dafür da, um eingehende ICMP-Pakete auf der IP-Adresse darzustellen (die hast Du hoffentlich nicht als xx.xx.xx.43 im Befehl gehabt, sondern die echte benutzt).
Das bedingt natürlich, dass in dem Moment ICMP-Pakete ankommen müssen, also musst Du parallel dazu was machen, was diese Pakete auslöst. Idealerweise (in diesem Fall) die IP von aussen anpingen.

tcpdump ist ein Monitor, das muss laufen, während Du etwas anderes durchführst. Es zeigt dann (je nach Filter) an, welche Netzwerkpakete auf dem Interface ankommen.
Was noch wichtig wäre: Der muss das WAN-Interface nehmen. Das ist nicht immer automatisch das erste, was er findet. In diesem Fall zeigt er "re0" an, kannst Du bestätigen, dass das die WAN-Seite der pfSense ist?

 

[tomcatcw]

Moin,

Der zweite tcpdump ist dafür da, um eingehende ICMP-Pakete auf der IP-Adresse darzustellen (die hast Du hoffentlich nicht als xx.xx.xx.43 im Befehl gehabt, sondern die echte benutzt).
Das bedingt natürlich, dass in dem Moment ICMP-Pakete ankommen müssen, also musst Du parallel dazu was machen, was diese Pakete auslöst. Idealerweise (in diesem Fall) die IP von aussen anpingen.

Statt der xx habe ich die richtige öffentliche statische IP (die 2. mir zur Verfügung verwendet).

tcpdump ist ein Monitor, das muss laufen, während Du etwas anderes durchführst. Es zeigt dann (je nach Filter) an, welche Netzwerkpakete auf dem Interface ankommen.
Was noch wichtig wäre: Der muss das WAN-Interface nehmen. Das ist nicht immer automatisch das erste, was er findet. In diesem Fall zeigt er "re0" an, kannst Du bestätigen, dass das die WAN-Seite der pfSense ist?

re0 ist falsch. Ich habe gewechselt auf re1. Sieht dann aber nicht besser:

[2.3.4-RELEASE][[email protected]]/root: tcpdump -i re1 -vvven host 8.8.8.8 and 'tcp[tcpflags] & (tcp-syn) != 0'
tcpdump: listening on re1, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
10669 packets received by filter
0 packets dropped by kernel

[2.3.4-RELEASE][[email protected]]/root: tcpdump -i re1 -c 5 -vvven dst host xx.xx.xx.43 and icmp
tcpdump: listening on re1, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
12869 packets received by filter
0 packets dropped by kernel

 

[tq1199]

Da wir aber mittlerweile wissen, dass es ausgehend klappt, brauchen wir das ansich nicht mehr testen.

Ja, aber wir wissen nicht mit welche source-IP, das ausgehend klappt und mit tcpdump wird das angezeigt.
Aber so weit ich weiß, wird für die Firewall der pfSense eine "spezielle" Regel benötigt.

Was noch wichtig wäre: Der muss das WAN-Interface nehmen. Das ist nicht immer automatisch das erste, was er findet. In diesem Fall zeigt er "re0" an, kannst Du bestätigen, dass das die WAN-Seite der pfSense ist?

Mit "-i" kann man für tcpdump das Interface festlegen.

 

[tq1199]

re0 ist falsch. Ich habe gewechselt auf re1. Sieht dann aber nicht besser:

[2.3.4-RELEASE][[email protected]]/root: tcpdump -i re1 -c 5 -vvven dst host 78.94.###.## and icmp
tcpdump: listening on re1, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
12869 packets received by filter
0 packets dropped by kernel

Von einem UM-Anschluss geht das traceroute (icmp) bis zur IP-Adresse 172.30.12.34:

<i>
</i>:~ $ mtr -4nr -c 3 -i 2 78.94.###.##
Start: Tue Oct 3 10:14:22 2017
HOST: xxxxxx Loss% Snt Last Avg Best Wrst StDev 1.|-- ##.##.##.1 0.0% 3 10.6 9.9 8.0 11.0 1.4 2.|-- 172.30.10.117 0.0% 3 15.5 12.3 10.5 15.5 2.6 3.|-- 84.116.190.21 0.0% 3 17.7 13.6 11.3 17.7 3.5 4.|-- 84.116.196.197 0.0% 3 11.9 12.7 11.9 13.4 0.0 5.|-- 84.116.196.17 0.0% 3 14.1 12.7 11.8 14.1 1.2 6.|-- 80.69.106.210 0.0% 3 16.3 13.3 11.2 16.3 2.5 7.|-- 84.116.197.65 0.0% 3 18.6 17.8 15.5 19.4 1.9 8.|-- 84.116.196.198 0.0% 3 15.5 16.3 15.5 16.8 0.0 9.|-- 84.116.191.50 0.0% 3 20.0 19.0 18.0 20.0 0.7 10.|-- 172.30.12.34 0.0% 3 15.8 14.5 12.2 15.8 2.0 11.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0

Bei der FB auch, aber diese wird erreicht:

<i>
</i>:~ $ mtr -4nr -c 3 -i 2 78.94.###.#1
Start: Tue Oct 3 10:14:08 2017
HOST: xxxxxx Loss% Snt Last Avg Best Wrst StDev 1.|-- ##.##.##.1 0.0% 3 9.7 9.5 9.3 9.7 0.0 2.|-- 172.30.10.117 0.0% 3 9.7 11.8 9.7 13.3 1.7 3.|-- 84.116.190.21 0.0% 3 38.2 34.5 11.9 53.5 21.0 4.|-- 84.116.196.197 0.0% 3 12.6 13.1 12.6 13.3 0.0 5.|-- 84.116.196.17 0.0% 3 14.1 13.9 12.2 15.4 1.6 6.|-- 80.69.106.210 0.0% 3 19.9 15.2 12.8 19.9 4.0 7.|-- 84.116.197.65 0.0% 3 17.7 17.7 17.3 18.1 0.0 8.|-- 84.116.196.198 0.0% 3 15.8 18.9 15.8 20.6 2.6 9.|-- 84.116.191.50 0.0% 3 17.8 18.8 16.8 21.7 2.5 10.|-- 172.30.12.34 0.0% 3 11.6 13.2 11.6 14.9 1.4 11.|-- 78.94.###.## 0.0% 3 21.8 23.0 20.7 26.4 3.0

<i>
</i>:~ $ nc -zv 78.94.###.## 8089
Connection to 78.94.###.## 8089 port [tcp/*] succeeded!

Aus dem Telekom-Netz geht der Ping auf die .41, aber nicht der traceroute (wegen der 172.er-IP-Adresse). Der TCP-Port 8089 der FB, ist aus dem Telekom-Netz nicht erreichbar.

 

[tomcatcw]

auf re1 (WAN-Port an der pfSense) habe ich mittels -i umgestellt.

Also das heißt doch, dass sich nach der Fritzbox .41 die Spur auflöst. Dahinter kommt nichts mehr. Ich kappiere es nicht. Sorry, ich bin kein Netzwerktechniker. Ich will nur, dass es funktioniert.

Bei wem liegt der Fehler. In der pfSense kann man nicht soviel einstellen und mittlerweile habe ich auch alle Kombinationen durch.

Was und wie kann ich noch testen?

 

[tq1199]

Also das heißt doch, dass sich nach der Fritzbox .41 die Spur auflöst.

Nein, die Spur löst sich (schon) vor der .41 auf. Lt. traceroute, fungiert die .41 nicht als gateway für die .43.

 

[tomcatcw]

Ok, was kann man daraus schließen? Fehler UM oder bei mir?

 

[tq1199]

... oder bei mir?

Ich denke, dass Du Schwierigkeiten mit der Konfiguration der pfSense hast, ... denn bis jetzt konntest Du den Traffic mit tcpdump noch nicht sniffen.

 

[addicted]

Wenn ich Deine .41 mit nem traceroute verfolge, kommt von der dynamischen IP Deiner Fritzbox "administratively prohibited". Das ist soweit richtig.

Wenn ich das mit der .43 mache, kommt nix. Da die Fritzbox normalerweise auskunftsfreudig ist, sollte die da als HOP auftauchen. Du hast ja in der FB nichts deaktiviert oder per Firewall weggesperrt, oder?

Setz mal die FB auf Werkseinstellungen zurück, vielleicht hakt da bloß was.

 

[tomcatcw]

Ok, mache ich gleich. Melde mich sobald es durch ist.

 

[tomcatcw]

Ok, ist durchgelaufen.

 

[tq1199]

Wenn ich Deine .41 mit nem traceroute verfolge, kommt von der dynamischen IP Deiner Fritzbox "administratively prohibited".

Welche dynamische IP-Adresse seiner FritzBox meinst Du?