Bridge oder LAN? Vorteile und Nachteile?

Bob.Dig

@jegr Welcher Cron job wäre dass denn genau, Ich hätte Interesse.

Bob.Dig

Auch die Gatewaygruppe hat nicht geholfen. Ipv6 Gateway ist wieder nur "pending" nach dem reconnect.

JeGr

@bob-dig said in Bridge oder LAN? Vorteile und Nachteile?:

@jegr Welcher Cron job wäre dass denn genau, Ich hätte Interesse.

Jener mit dyndns im Namen :)

Bob.Dig

@jegr said in Bridge oder LAN? Vorteile und Nachteile?:

Jener mit dyndns im Namen :)

Ok, aber der macht bei mir wirklich nur das und hilft nicht beim pending gateway.

JeGr

@bob-dig said in Bridge oder LAN? Vorteile und Nachteile?:

Ok, aber der macht bei mir wirklich nur das und hilft nicht beim pending gateway.

Öh ja richtig, was anderes hatte ich nie behauptet :)

Bob.Dig

@jegr Wie auch immer, Du scheinst ja von dem Problem nicht betroffen zu sein, trotz täglichem reconnect oder Du hast IPv6 aus.

nonick

@bob-dig Ich hatte solche Probleme noch nie gehabt. Früher bei 1&1 nicht und jetzt bei der Telekom auch nicht. Benutze aber auch keine Fritzbox als Modem und die Sense ist nicht virtualisiert. Alle die ich kenne haben einen ähnlichen Aufbau und auch da funktioniert das reibungslos.

Bob.Dig

@nonick Deswegen würden mich mal die Unterschiede interessieren. Meine pfSense ist zwar virtualisiert, aber die WAN-NIC ist eine durchgereichte von intel, daran sollte es also nicht liegen. Was wäre die Erklärung?

nonick

@bob-dig Im Zweifel immer die Fritzbox , oder ein Konfigurationsproblem.

Bob.Dig

@bob-dig said in Bridge oder LAN? Vorteile und Nachteile?:

@jegr Welcher Cron job wäre dass denn genau, Ich hätte Interesse.

Wer sucht der findet und ein erster Versuch mittels eines cron-jobs (/usr/bin/nice -n20 /etc/rc.reload_all) sieht schon mal vielversprechend aus, um die IPv6 Konnektivität wieder herzustellen.

Nun hatte ich leider den dyndns.update cron-job verstellt gehabt, kann mir jemand sagen, was da die defaults waren? Denn mein Problem konnte der nicht lösen und ich hätte gerne wieder den Standard.

JeGr

@bob-dig Word of warning: reload all mag zwar dabei helfen lädt aber bei Trigger ALLES neu, da fliegt dir dann auch VPN und was weiß ich was alles weg.

Bob.Dig

@jegr Ist jetzt um 5 Uhr morgens nicht das Problem bei mir. Wenn Du einen weniger invasiven Befehl kennst, gerne her damit.
PS: VPN fliegt zwar weg, kommt aber auch zeitig wieder von allein zurück.
rc.newwanipv6 klingt noch vielversprechend, aber ob das ohne Argumente auskommt?

Bob.Dig

rc.reload_all hat gut funktioniert, dieses Problem ist also gelöst.

Was mich aber weiterhin beschäftigt, sind diese Firewall-Ereignisse. Ich verstehe immer noch nicht, was private IPs an meinem Anschluss zu suchen haben. Müssten diese Verbindungen nicht vom Provider selbst kommen? Und wenn ja, warum? Und wenn nein, was passiert da genau?

JeGr

@bob-dig Lesen - hatte ich geschrieben.

@jegr said in Bridge oder LAN? Vorteile und Nachteile?:

Port 445 - stink normaler Netbios Windows File Bla Gedöns Port. So unbekannt ist das nicht. Kann auch schlicht wieder ein Zugriff sein von IPs, die sich direkt ins DSL einwählen ohne Firewall, deren Kiste dann auch kein Filtering nach RFC1918 machen. Dürfte nicht auf dem DSL Interface auftauchen, tuts aber oft trotzdem keine Ahnung was da Leute teils machen. Und 445er Requests gehen eben teils an Broadcast, dann werden die ohne Filtering (obwohl das die Telekom eigentlich tun müsste aber hey...) halt an alle lauschenden IP Adressen am Verteiler oder in dem Netzsegment rausgehauen. Murks aber was willste machen.

Und warum bekomme ich beim traceroute dann was ganz anderes geliefert?

Weil das kein Broadcast sondern direkte Kommunikation ist. DIE geht dann zu deinem Uplink Gateway das dann korrekterweise RFC1918 nicht routet wie es im RFC steht. Aber wenn du DSL direkt an irgend nen Gerät hängst und das dann halt Broadcasts via WAN rausballert - kommt sowas schon vor.

Was die Telnets angeht, gute Frage. Kann aber trotzdem vom "Provider" kommen, wenn einer sich da direkt einwählt und ne interne IP bekommt. Oder es ist gespooft. Gibt schon nen Grund, warum man RFC1918 am WAN blockt :)

JeGr

@bob-dig said in Bridge oder LAN? Vorteile und Nachteile?:

@jegr Ist jetzt um 5 Uhr morgens nicht das Problem bei mir. Wenn Du einen weniger invasiven Befehl kennst, gerne her damit.
PS: VPN fliegt zwar weg, kommt aber auch zeitig wieder von allein zurück.
rc.newwanipv6 klingt noch vielversprechend, aber ob das ohne Argumente auskommt?

Du könntest auch einfach mal testweise deine Konfig sichern, ggf. irgendwelche manuellen Sachen sichern und dir 2.5 Snapshot raufzwirbeln und da einfach mal "relativ" default das IPv6 lassen. Das verhält sich bei mir im Test nämlich angenehm besser als bei 2.4.x, gerade was refreshs bei neuer Prefix Delegation angeht. Hatten im Dev Forum schon ein paar Stimmen bestätigt, dass sie mit Dingen wie IPv6 Zuweisung und Delegation weit weniger Probleme hatten bei 2.5 da neuer Kram von Upstream FreeBSD besser läuft.

Bob.Dig

@jegr said in Bridge oder LAN? Vorteile und Nachteile?:

Was die Telnets angeht, gute Frage. Kann aber trotzdem vom "Provider" kommen, wenn einer sich da direkt einwählt und ne interne IP bekommt. Oder es ist gespooft. Gibt schon nen Grund, warum man RFC1918 am WAN blockt :)

Aber Spoofing würde bedeuten, dass derjenige keinen Antwort bekommen kann, oder? Dann wäre doch der Nutzen gleich 0.

Ich habe hier auch meine manuelle Blockregel gemacht, da ja in den docs zu lesen ist, man solle mit einem privaten Netzwerk am WAN eben nicht RFC1918 blocken. Weiß jemand, ob das nur für den Fall gilt, dass man tatsächlich doch Traffic aus dem privaten "WAN-Net" bekommen will oder gilt das quasi immer?

Frage mich auch, ob nicht die Telekom dahinter steckt, warum auch immer...

JeGr

@bob-dig said in Bridge oder LAN? Vorteile und Nachteile?:

Aber Spoofing würde bedeuten, dass derjenige keinen Antwort bekommen kann, oder? Dann wäre doch der Nutzen gleich 0.

Wenn du spoofst, willst du ggf. auch gar keine Antwort.

NOCling

Ich glaube wir müssen hier erst mal sauber definieren was die Sense als WAN definiert.

Ich denke:
WAN ist ja für die Sense eher alles andere als RFC1918, denn sonst ist das ja kein echtes WAN mehr sondern eher ein MAN oder LAN Interface.

Ich habe den Filter bei mir drauf und komme trotzdem an mein Modem über die 192.168.100.1.
Die IP darf mir aber auf dem WAN per DHCP auch keine IP vergeben.

Bob.Dig

@nocling WAN-Net ist einfach das Netz am WAN Port für die pfSense. Ich habe einen Block sowohl eingehend als auch ausgehend für RFC1918, aber halt mit der Ausnahme des WAN-Net, welches bei mir ein privates ist. Brauch ich überhaupt die Ausnahme für irgendwas, was ich nicht weiß (DHCP, etc.) oder könnte ich RFC1918 in meinem Falle komplett blocken und ggf. Ausnahmen machen für DNS oder ähnlichem.

NOCling

Das ist doch soweit ich das verstehe ein eingehender Block wenn das aktiv ist.

Wie gesagt ich blocke das auf WAN weg, kann aber mit meinem Modem auf der 192.168.100.1 sprechen.