[solved] IPv6 Port Forwarding tatsächlich möglich

slu

So ich habe auch schon 3x CE Edition und einmal eine SG-1100 durch, soweit keine Probleme.

Bob.Dig

Bin wieder zurück auf 2.4.5. Neben dem DDNS Widget ging auch nicht mehr der HE-Tunnel und einige der VPN-Clients von alleine hoch, musste hier immer manuell nachhelfen. Hatte inplace geupgraded, davor nur alle Packages deinstalliert. Und obwohl der erste Eindruck nicht schlecht war, haben mich dann doch die auftretenden Probleme soweit verunsichert, dass ich zurück bin.

Ich würde ja auch alles von scratch neu einrichten, wenn ich wüsste, dass dann alles tatsächlich funktionieren würde.
Und bin nicht mehr dazu gekommen, mir die IPv6 Portforwards näher anzuschauen.

JeGr

@bob-dig said in Neue pfSense Version erschienen:

Und ich hab gleich eine Frage dazu:
Added support for IPv6 Port Forwards #10984

Gibt es jetzt port forwards ohne NAT?
Oder anders gefragt, ich habe teilweise die Standard-Ports nach außen geändert, nach innen diese aber weiter genutzt. Das fiel mir dann bei IPv6 auf die Füße...

Port Forwards sind mit pf redirection/rewrite Regeln realisiert. Das ist per Definition nicht zwangsweise auch NAT. Somit streng genimmen lediglich ein Feature eine IP/Port Kombo eben auf ein anderes Ziel umzuleiten. Ist eben problematisch, weil im Sprachgebrauch jeder bei allem irgendwie NAT zu sagt. NAT (ausgehend) - also maquerading - ist aber was anderes als port forwards.

Scheint sich noch keiner ranzutrauen an die 2.5. :)

Quark, ich bin schon seit Monaten auf 2.5 und einige Kunden migriere/update ich gerade. Nur weil einige (laute) Zwischenrufer gern Panik schreien muss das nicht so sein. Die sind nur einfach lauter, deshalb hört man von den vielen, bei denen es "einfach geht" nichts - warum auch, die würden ja eh nur schreiben "jop, ging alles gut, nichts zu melden". :)

JeGr

@bob-dig said in Neue pfSense Version erschienen:

Ich würde ja auch alles von scratch neu einrichten, wenn ich wüsste, dass dann alles tatsächlich funktionieren würde.

Keine Ahnung was bei dir läuft, aber wie gesagt, ich bin seit Monaten auf 2.5 ohne Problem.

So ich habe auch schon 3x CE Edition und einmal eine SG-1100 durch, soweit keine Probleme.

Die SG1100 war etwas dreckig, die musste ich dann neu installieren. Keine Ahnung was letzte Woche DO/FR los war, aber der Update von 180 Paketen war derart lahm, das kam nach Stunden nicht zum Ende (obwohl es langsam weiterlief, hing also nichts, war nur zu langsam).

Da kenne ich ganz andere Szenarien bei anderen FW Herstellern. Ich hoffe, die Qualität bei den künftigen Updates bleibt erhalten, auch wenn man demnächst zweigleisig fährt.

Ohja kann ich bestätigen. Gerade erst tollen Spaß mit Juniper Geräten gehabt. Wer macht bitte auch Hardware, deren Speicher so FU***NG klein ist, dass das eigene Firmware Update nicht reingeschrieben werden kann, sondern man das auf nen USB Stick auslagern muss. WTF?!

Bob.Dig

@jegr said in Neue pfSense Version erschienen:

Port Forwards sind mit pf redirection/rewrite Regeln realisiert. Das ist per Definition nicht zwangsweise auch NAT. Somit streng genimmen lediglich ein Feature eine IP/Port Kombo eben auf ein anderes Ziel umzuleiten. Ist eben problematisch, weil im Sprachgebrauch jeder bei allem irgendwie NAT zu sagt.

Anders gesagt, das geht schon die ganze Zeit, auch im GUI, dann wohl unter Firewall / NAT / Port Forward? Wenn ja, auf welches Interface müsste so ein Portforward für IPv6?

slu

@jegr said in Neue pfSense Version erschienen:

Wer macht bitte auch Hardware, deren Speicher so FU***NG klein ist, dass das eigene Firmware Update nicht reingeschrieben werden kann, sondern man das auf nen USB Stick auslagern muss. WTF?!

lach so etwas habe ich auch noch nicht gehört.
Die Antwort auf deine Frage: Der Kaufmann

Kenne ich von anderen Projekten, da wird 5% Hardware gespart aber man hat damit die nächsten Jahre 100% eine Freude ähm Bremse.

JeGr

@bob-dig said in Neue pfSense Version erschienen:

@jegr said in Neue pfSense Version erschienen:

Port Forwards sind mit pf redirection/rewrite Regeln realisiert. Das ist per Definition nicht zwangsweise auch NAT. Somit streng genimmen lediglich ein Feature eine IP/Port Kombo eben auf ein anderes Ziel umzuleiten. Ist eben problematisch, weil im Sprachgebrauch jeder bei allem irgendwie NAT zu sagt.

Anders gesagt, das geht schon die ganze Zeit, auch im GUI, dann wohl unter Firewall / NAT / Port Forward? Wenn ja, auf welches Interface müsste so ein Portforward für IPv6?

Hö? Auf welches Interface? Wer von uns beiden ist nun verwirrt? Was hat Interface mit IP4/6 zu tun? Na aufs gleiche wie bisher auch, oder was verstehe ich davon jetzt gerade nicht? :)

JeGr

@slu said in Neue pfSense Version erschienen:

Die Antwort auf deine Frage: Der Kaufmann

Eher der Einkauf oder die, die aufm Geld sitzen. Aber bspw. Juniper Switchstacks 3000er oder 2000er Reihe sind mit so wenig internem Flash bestückt, dass man das FW Update entweder aufsplitten muss in 2 Teile (die beide dann geil an die Wand laufen können) oder man muss einen Stick stecken der dann als temp Speicher genutzt wird, weil die f**** firmware weder in RAM noch im Flash genug Platz hat und der das sonst nicht gewuppt bekommt. Unglaublich.

Bob.Dig

@jegr Also so ginge das z.B. für IPv6?

Der einzige Unterschied zu IPv4 wäre hier, dass zweimal der selbe Host angegeben würde?
Ich bin nicht verwirrt, nur ahnungslos.

JeGr

@bob-dig Möglich, aber so eine seltsame Umschreibung hab ich noch nie gebraucht. Warum auch, die IP ist public, warum also nicht public direkt den anderen Port aufrufen? Macht keinen Sinn für mich.

Bei Redirection gehts um IP UND Port in Kombination. Bspw. eben DNS umschreiben auf localhost, damit ich DNS lokal abfange und bearbeite und keiner einfach nen externen DNS nutzt und dann jammert, dass seine Hosts nicht aufgelöst werden können. Sowas kann man mit RDR lösen. Ja eingehend geht das dann ggf. auch, aber da macht es eben keinen gesteigerten Sinn gerade für mich in dem Beispiel. :)

Bob.Dig

@jegr Mir geht es darum, andere Ports nach außen zu verwenden als die oft gescannten Standard-Ports. Mit NAT easy und intern kann alles auf den Standard-Ports bleiben, mit IPv6 war das dann zeitgleich aber problematisch. Wenn das jetzt einfach so geht wie gezeigt, das fände ich klasse. Ich benutze eh SRV Records im DNS um die Ports zu "publizieren".
Werde es gleich mal testen, allerdings unter 2.4.5...

NOCling

Mein Eindruck ist, auf x86 Plattformen scheint es auch relativ wenig Probleme zu geben.

Die Umstellung auf der ARM Seite scheint noch ein wenig zu hackeln.
Egal was ich versucht hatte, den S2S Tunnel habe ich nach Neuanlage zwar stabil up bekommen, aber Daten gingen nicht durch.
Bin dann am WE wieder runter auf 2.4.5p1 und warte jetzt den ersten Patch ab.

Gerade gelesen das auf dem SG-1100 wohl der Crypto Treiber fehlerhaft ist.

Scheint aber auf beide zu zu treffen. Denn auch als nur die SG-3100 auf 21.02 war, wollte da nix laufen.
Der Tunnel zur Fritz lief mach Neuanlage.

Na wird schon mit ein wenig Geduld.

Bob.Dig

@bob-dig said in Neue pfSense Version erschienen:

@jegr Mir geht es darum, andere Ports nach außen zu verwenden als die oft gescannten Standard-Ports. Mit NAT easy und intern kann alles auf den Standard-Ports bleiben, mit IPv6 war das dann zeitgleich aber problematisch. Wenn das jetzt einfach so geht wie gezeigt, das fände ich klasse.

Funktioniert tatsächlich auch für IPv6, danke @JeGr !
Und das trotz NAT in der Überschrift.

Bob.Dig

@bob-dig said in Neue pfSense Version erschienen:

Funktioniert tatsächlich auch für IPv6, danke @JeGr !

Aber "leider" geht auch der "alte" Port noch genauso, bringt mir also tatsächlich so doch nix.

Bob.Dig

@jegr said in Neue pfSense Version erschienen:

Bei Redirection gehts um IP UND Port in Kombination.

Und das geht ebenfalls mit IPv6? Ist das dann nicht doch NAT?

Edit: Heilige Makkaroni, man scheint ja tatsächlich IPv6 wie IPv4 NATen zu können.
Mein Problem dabei, das NAT-Ziel ist ebenfalls immer auch unter dem ursprünglichen Port von außen erreichbar...

Edit2: Man kann damit aber das DDNS-Problemchen umgehen, indem man halt von der pfSense NATet.

JeGr

@bob-dig said in Neue pfSense Version erschienen:

@jegr Mir geht es darum, andere Ports nach außen zu verwenden als die oft gescannten Standard-Ports. Mit NAT easy und intern kann alles auf den Standard-Ports bleiben, mit IPv6 war das dann zeitgleich aber problematisch. Wenn das jetzt einfach so geht wie gezeigt, das fände ich klasse. Ich benutze eh SRV Records im DNS um die Ports zu "publizieren".

Macht keinen Sinn, mit ZMAP scannst du so schnell mit tcp syns dass dieses ganze "andere Port" Blubb völlig nutzlos ist. Das ist in den meisten Fällen nur leidiges Security through Obscurity was gar nichts bringt. Einzig bei einigen wenigen Punkten (wie bei SSH) sag ich "OK" zu sowas, weil es bspw. bei SSH tatsächlich das Grundrauschen an Bots etc. einfach wegdrückt und SSH flexibel ist.

Wenn die offen sein sollen - dann macht man sie auf. Wenn eh nur du drauf willst, dann mach sie nur per VPN auf. Sehe das einfach pragmatisch.

@bob-dig said in Neue pfSense Version erschienen:

Edit: Heilige Makkaroni, man scheint ja tatsächlich IPv6 wie IPv4 NATen zu können.

Es ist kein NAT...

Mein Problem dabei, das NAT-Ziel ist ebenfalls immer von außen erreichbar...

Weil es NICHT dafür gedacht ist irgendwelche Ports in der Gegend herumzuschieben. Und durch die Natur des Regelwerks von "pf" ist das IMMER so. RDR Regeln kommen natürlich vor den Filterregeln. Also wird das Paket auf den "neuen" Port umgeschrieben und kommt so in die Filterregeln. Somit wird dann in der Regel gegen den bisherigen Port gematcht.

Deshalb schreib ich ja, dass das so keinen Sinn macht bei ner Public IP.

Bob.Dig

@jegr Hab noch eine Sache ergänzt drüber (DDNS).

Was die Security betrifft, durch SRV kann man halt andere Ports definieren, die dann tatsächlich deutlich weniger "angegrabbelt" werden, das gilt zumindest für IPv4.

Und was ist, wenn ich auf private IPv6 RDRe? Das müsste doch dann tatsächlich sicher sein.

Ich hatte bis gerade keine Ahnung, dass das überhaupt mit IPv6 geht.

JeGr

@bob-dig said in Neue pfSense Version erschienen:

Und was ist, wenn ich auf private IPv6 RDRe? Das müsste doch dann tatsächlich sicher sein.

Nur weil private Adressen im Spiel sind, ist nichts "plötzlich sicher". NAT war NIE eine Security Schicht. NAT und RFC1918 Adressen sind keine Verbesserung der Sicherheit. Das muss man sich immer im Kopf behalten. Nichts wird dadurch sicherer, dass man private Adressen nutzt. Es wird nur alles um eine "magnitude of order" komplexer und abgefuckter. Sorry - kann man nicht anders ausdrücken ;)

Bob.Dig

Aber es würde gehen ja? Mich stört halt noch, dass der Server immer noch direkt erreichbar ist. Mal sehen was passiert, wenn ich den in den privaten Adressraum verschiebe.

Hab auch mal das Topic geändert. Wenn jemand das alte Topic aufgreifen will, einfach ein eigenes aufmachen.

JeGr

@bob-dig said in IPv6 Port Forwarding:

Aber es würde gehen ja? Mich stört halt noch, dass der Server immer noch direkt erreichbar ist. Mal sehen was passiert, wenn ich den in den privaten Adressraum verschiebe.

Du hast die Frage selbst beantwortet. Wenn du irgendwas in einen privaten - per Definition NICHT gerouteten - Bereich schiebst, dann kann der auch über die Adresse nicht erreicht werden. Wie auch ;)

Hat aber nichts mit Sicherheit sondern bloßer Verschleierung zu tun. Und es wird noch lustiger wenn dann die Kiste FDxy und public IP6 zusammen hat. Und dann darf die IP6 von der aus auf die ULA gemappt wird nicht die gleiche Range sein, wie intern als GUA genutzt wird. Und und und.

Deshalb mein Satz: das wird noch wesentlich "bescheidener" wenn man anfängt solche potentiellen Mausefallen (oder fuckups) zu bauen. Darum: Nope. Würde ich im Leben so nie einsetzen egal "obs geht". Das ist genau der Murks, der uns NAT4 überhaupt erst eingebrockt hat. Und irgendwelche Ports zu verschaukeln nutzt eh kaum jemand. Dann setz doch direkt den Service auf einem anderem Port auf? :)