IPv6 Ports mittels Firewall blocken
-
@mdollenbacher said in IPv6 Ports mittels Firewall blocken:
Meine Frage ist jetzt die ob ich über die pfSense sagen kann das Anfragen an eine bestimmte Adresse und an alle Ports bis auf z.B. 80 & 443 geblockt werden oder ob ich das direkt auf der VM machen müsste.
Hallo Mathias,
Wenn du darüber sprichst eingehend auf dem WAN alles bis auf Port x und y zu blocken - natürlich geht das. Vielleicht wäre es einfacher zu fragen, WAS genau du machen willst aber ggf. nicht geht, denn so verstehe ich gerade nicht, wofür du den ganzen Tag gesucht hast ;)
Grüße
-
Hey und erstmal danke für die Antwort :)
es geht darum bei meinem jetzigen "Setup" bzw. Konfiguration
nutze ich NAT um die benötigten Ports freizugeben. Alles andere wird geblockt. Ich weiß das es unter IPv6 kein NAT sonder nur sowas wie NAT64 oder auch NTp gibt aber ich brauche das eigentlich nicht.Ich suche nur nach einer Möglichkeit alles zu blocken und die benötigten Ports dann in der Firewall freizugeben.
Jetzt war ich mir nur nicht ganz sicher ob das über die pfSense geht oder ob ich z. B. über iptables auf jeder einzelnen VM die Ports per Hand blocken müsste.
Ich hoffe du/Ihr versteht jetzt besser was ich meine.
LG
Mathias -
@mdollenbacher said in IPv6 Ports mittels Firewall blocken:
Ich weiß das es unter IPv6 kein NAT sonder nur sowas wie NAT64 oder auch NTp gibt aber ich brauche das eigentlich nicht.
Das willst du nicht(!) - und brauchst es nicht, korrekt :)
Ich suche nur nach einer Möglichkeit alles zu blocken und die benötigten Ports dann in der Firewall freizugeben.
Nochmal: warum "alles zu blocken"? pfSense blockt per se ALLES auf dem WAN schon standardmäßig. Daher frage ich auch so doof, warum du was wo wie unbedingt "blocken" willst. Es geht um freigeben und da gibst du eben Port 80,443 auf WAN nach IP6 xy:zz:123: frei. So wie es deine Regel nach dem NAT auch tut. Erst wird geNATtet, dann kommt die Firewall Regel, die das Paket erlaubt. Warum sollte da was mit IP6 anders sein? Es entfällt lediglich der NAT Schritt, die Regel für die Freigabe auf dem WAN für Ziel:Port bleibt genauso. Und was nicht definiert ist wird geblockt. Warum sollte bei IP6 jetzt plötzlich alles offen sein wie ein Scheunentor?
Jetzt war ich mir nur nicht ganz sicher ob das über die pfSense geht oder ob ich z. B. über iptables auf jeder einzelnen VM die Ports per Hand blocken müsste.
Auch das verstehe ich nicht. Kein Mensch würde da jeden Port einzeln blocken. Du gehst doch selbst mit IPtables oder netfilter in ner VM oder Box hin und sagst "default allow, block port 1, block port 2, etc. etc.", sondern setzt einfach nen dummes "block any, allow port 80/443". Wo kommt diese seltsame Denkweise mit "alles ist erlaubt" her?
Gruß Jens
Edit: Wenns hilft: stell dir einfach vor, du hättest innen wie außen public IP4 Bereiche, die ganz normal routingfähig wären. Also öffentliche Adressen innen wie außen. Bei denen würdest du doch genauso einfach die Regeln machen wie jetzt auch: block any ist default, allow dst_ip port xy, fertig. Wie bei den automatisch generierten NAT Regeln, nur dass das Ziel eben vorher nicht in eine private IP umgeschrieben und die Regel dann nicht auf das interne Ziel lautet. IP6 (zumindest mit statischen IP6 - und wenn du Services anbietest, machst du besser statische IP6!) läuft da genauso.
-
Hey,
ich hab nie gemeint "Alles ist erlaubt". Ich weiß das die pfSense alles Standartmäßig blockiert.
Du sagst es fällt einfach der NAT Schritt weg. Wo kann ich denn dann die Ports freigeben? Also unter welchem Reiter. Bei NAT ging das ja direkt unter Firewall / NAT / Port Forward.
Unter welchem Reiter muss ich jetzt schauen für IPv6?
LG
MathiasP.S.: Sorry wenn ich mich so doof anstelle. Bin wirklich kein Netzwerktechniker haha
-
@mdollenbacher said in IPv6 Ports mittels Firewall blocken:
Du sagst es fällt einfach der NAT Schritt weg. Wo kann ich denn dann die Ports freigeben? Also unter welchem Reiter. Bei NAT ging das ja direkt unter Firewall / NAT / Port Forward.
Nein ging es nicht. :) Du wirfst da lustig Dinge durcheinander ;)
Du kannst NAT / Port Forwards natürlich auf einen/wenige Ports beschränken. Oder du kannst via 1:1 NAT alles weiterleiten. WAS du im Masquerading/ingess NATting machst, bleibt dir überlassen. Das hat aber nichts damit zu tun, was effektiv freigegeben ist. Das definiert NUR die Regel, WANN ein Paket umgeschrieben wird (aka Ziel IP wird von externer WAN IP auf Interne IP geändert). Dabei wird aber noch keine Erlaubnis gegeben, dass das Paket durch den Filter darf!Port Forwarding hat (ganz unten) aber die Option, standardmäßig automatisch eine passende Filterregel(!) anzulegen und diese - und NUR diese - regelt, was erlaubt ist und was nicht. Alles was nicht in den Firewall Regeln erlaubt ist, wird geblockt. Easy as that :) Und dabei ist es völlig gleich, was du vorher bei den Forwards oder 1:1 NATs definiert hast. Wenn ich dir danach eine Firewall Regel reinbastele die alles blockt ist dein Forward trotzdem geblockt.
Daher nicht NAT mit Regeln verwechseln, das Resultat mag im ersten Moment durch die Automatismen für dich genauso aussehen, es regelt aber völlig andere Prozesse. Scheinbar hast du bislang aber eben nur die Auto-Regeln der NAT-Rewrites genutzt und daher gar nicht gesehen, dass dafür immer Regeln auf dem WAN Interface angelegt wurden. Einfach mal nachschauen, da findest du die ganz leicht. :)
Unter welchem Reiter muss ich jetzt schauen für IPv6?
Noch nie einen Blick unter "Firewall > Rules" geworfen? :)
Beispiel:
Einfaches Ding: Auf dem WAN wird ankommend TCP von einer gewissen Quelle (Alias) auf Port 5022 angenommen und das Paket umgeschrieben, so dass nicht mehr die externe IP, sondern die interne von meinem NAS und der Port von 5022 auf 22 umgeschrieben wird. Einfach gerade mal als Beispiel gemacht.
Das schreibt aber NUR das ankommende Paket um und macht sonst erstmal gar nichts. Das Paket bleibt weiter im Processing und wenn keine andere NAT Einstellung mehr greift, geht es weiter in die Regelsätze.
Das hier ist die zugehörige automatisch erstellte Firewall Regel -> man bemerke den Prefix "NAT" in der Beschreibung und den gleichen Text "SSH NAS" dahinter. Symbolisiert somit, dass die automatisch aus dem NAT Eintrag erstellt wurde. Da ist nun plötzlich nichts mehr zu sehen von der WAN IP oder Port 5022, sondern nur noch "interne IP, Port 22". Warum? Weil das Paket bevor es in das Regel-Processing und Matching kommt, zuerst(!) umgeschrieben wird (auf die internen Werte) und dann gegen Filterregeln gematcht wird. Da das damals schon viele Benutzer nicht verstanden haben (NAT VOR Firewall Regeln) hatte man in irgendeiner früheren 2er Version (ich denke es war 2.2) dann die automatisch erstellten Regeln im NAT Dialog eingebaut. Damit man sich das nicht merken muss und die Standardfehler weniger werden :)
Somit: das zweite Bild ist das, was überhaupt (Haken vorne -> allow) den Traffic erlaubt. Das andere (NAT oben) mit dem verdrillten Pfeil ist nur ein Umschreiben, aber noch keine Erlaubnis :)
Ergo: Firewall Regeln einlesen, Regel erstellen auf WAN, aaaaaaand it's gone :)
-
Hey,
sorry für die späte Antwort.
Ich hab es jetzt die 2 letzten Tage versucht und bin nicht wirklich weiter gekommen. Ich weiß leider nicht genau was ich bei Source und Destination Address angeben muss oder ob ich was anderes komplett falsch mache. Es wäre sehr nett und würde mir extremst weiterhelfen wenn man mir das zeigen könnte und vielleicht nen paar Kurze Sätze dazu schreiben könnte woran es denn nun gelegen hat ;D
z. B. an Hand eines Screenshots.Hier das was ich versucht habe aber leider nicht geklappt hat.
Jetzt hab ich noch eine Frage zur Konfiguration des ganzen Systems weil vielleicht liegt da ja ein Fehler vor.
Ich hab dem Proxmox die erste IP des Subnetzes gegeben und diese auf die Bridge (bei mir vmbr0) gelegt und dann dem pfSense auf dem WAN Interface die 2 IP gegeben und als Gateway das normale, vom Anbieter angegebene, eingetragen
auto vmbr0 iface vmbr0 inet static address 95.217.xxx.xxx/26 gateway 95.217.xxx.xxx bridge-ports enp0s31f6 bridge-stp off bridge-fd 0 post-up ip route add 95.217.xxx.xxx/28 dev vmbr0 iface vmbr0 inet6 static address 2a01:4f9:xxxx:xxxx::1/64 gateway fe80::1 up sysctl -p up ip -6 route add 2a01:4f9:xxxx:xxxx::/64 dev vmbr0
Wenn ich jetzt einer VM eine IPv6 Adresse geben möchte weiß ich dieser Maschine die Bridge vmbr0 zu und trage in die Netzwerkonfiguration z. B. folgendes ein
auto ens19 iface ens19 inet6 static address 2a01:4f9:xxxx:xxxx::4 netmask 64 gateway 2a01:4f9:xxxx:xxxx::2 # up sysctl -p
Wäre das jetzt so korrekt oder mache ich hier schon einen Fehler?
LG
Mathias -
@mdollenbacher said in IPv6 Ports mittels Firewall blocken:
Ich hab es jetzt die 2 letzten Tage versucht und bin nicht wirklich weiter gekommen. Ich weiß leider nicht genau was ich bei Source und Destination Address angeben muss oder ob ich was anderes komplett falsch mache. Es wäre sehr nett und würde mir extremst weiterhelfen wenn man mir das zeigen könnte und vielleicht nen paar Kurze Sätze dazu schreiben könnte woran es denn nun gelegen hat ;D
Klar, wenn du mir sagst, was genau die Regel tun soll?
Ich hab dem Proxmox die erste IP des Subnetzes gegeben und diese auf die Bridge (bei mir vmbr0) gelegt und dann dem pfSense auf dem WAN Interface die 2 IP gegeben und als Gateway das normale, vom Anbieter angegebene, eingetragen
Macht gerade für mich irgendwie keinen Sinn. Wie hast dus denn bei IP4 gemacht? Da ist ja scheinbar ein /26 im Spiel, wie hast du das denn zur pfSense gebracht?
-
Also ich hab eine Regel die den Port 80 freigeben soll.
Die Regel sieht so aus.Ich hab mal das Logging für die Regel aktiviert und habe dann in den System Logs festgestellt das dort eine "default deny ipv6 rule"
greift. Ich hab dazu nur den Haken "Allow IPv6" Eintrag unter System / Advanced / Networking und der ist gesetzt.Macht gerade für mich irgendwie keinen Sinn. Wie hast dus denn bei IP4 gemacht? Da ist ja scheinbar ein /26 im Spiel, wie hast du das denn zur pfSense gebracht?
Ich hab von meinem Host eine IP für die Maschine bekomme. Die war standartmäßig dabei. Ich hab dann noch ein /28 Subnetz dazu gekauft. Das hab ich dann bzw. ein Freund auf meine Maschine geroutet. (Sorry wenn das scheiße erklärt ist.)
-
@mdollenbacher said in IPv6 Ports mittels Firewall blocken:
Ich hab von meinem Host eine IP für die Maschine bekomme. Die war standartmäßig dabei. Ich hab dann noch ein /28 Subnetz dazu gekauft. Das hab ich dann bzw. ein Freund auf meine Maschine geroutet. (Sorry wenn das scheiße erklärt ist.)
Genau du hast das /28er wahrscheinlich auf die VM geroutet (indirekt auf die einzelne IP die die pfSense hatte). Vermute ich zumindest macht aber am meisten Sinn.
So muss auch IPv6 zu dir kommen damit du es sinnvoll verwenden kannst. Mit einzelnen IP6s aus dem gleichen Subnetz wie dein Host und das Gateway macht das nicht so wirklich Sinn für mich. Aber da müsste ich auch nochmal irgendwas sehen, wie das VM Setup aussieht. Irgendwie empfinde ich das extrem schräg dass die VM eine IP6 aus dem gleichen Range des Hosts und des GWs bekommt - macht keinen Sinn. Wozu hat der Hypervisor dann auf der Bridge überhaupt eine Adresse wenn die VM selbst die Adresse auch tragen kann etc. - daher wäre eine Skizze wie das Setup aussieht oder wie dein Kumpel das /28er Netz geroutet hat und die pfSense überhaupt v4 hat sinnvoll. Das ist gerade alles etwas konfus :)
-
Also zum Server dazu gehört die IP: 95.2xx.xxx.228 mit dem Gateway 95.2xx.xxx.193
dazu hab ich ein IPv4 /28 Subnetz geholt das als Gateway die IP 95.2xx.xxx.228 hat und zwischen 95.217.xxx.208
und 95.217.xxx.222. Interne IP ist 10.0.0.2Mein pfSense hat nun die IP 95.217.xxx.209 und als Gateway die 95.2xx.xxx.228. Die Interne IP ist 10.0.0.1.
Jetzt hab ich ein Internes Netz (10.0.0.1/24) und von diesem kriegen die Server jetzt eine interne Adresse.
Netzwerkkonfiguration würde jetzt so z.B. aussehen
iface vmbr1 inet static address 10.0.0.3/24 gateway 10.0.0.1 dns-nameservers 10.0.0.1
Jetzt regel ich per NAT halt sowas wie Portweiterleitung und den ganzen Kram.
Gratis zum Server hab ich ein IPv6 Subnetz bekommen. Dieses lautet 2a01:4f9:2b:xxx::/64
und hat als Gateway fe80::1Jetzt hab ich mich an die Anleitung des Hosters gehalten und das so eingerichtet wie es hier steht (Netzwerkkonfiguration Hostsystem Routed)
https://community.hetzner.com/tutorials/install-and-configure-proxmox_ve/de/?title=Proxmox_VEIch hoffe es ist verständlich. Ansonst kann ich dir auch genau Screenshots von der Netzwerkonfiguration der einzelnen Maschinen zukommen lassen.
-
@mdollenbacher said in IPv6 Ports mittels Firewall blocken:
Gratis zum Server hab ich ein IPv6 Subnetz bekommen. Dieses lautet 2a01:4f9:2b:xxx::/64
Das ist dann auch das Problem. Mit einem /64er funktioniert das alles nicht. Du brauchst extern ein /64er Netz, bei dem deine pfSense eine IP6 hat. Und dann brauchst du innen für das LAN ein weiteres /64er Netz (oder besser ein größeres /60 oder /56er, welches auf deine externe IP6 geroutet wird), das du intern in VLANs nutzen kannst. Ohne mehr als ein Netz /64 zu haben, wird das nichts. IP6 nutzt public IPs überall. Und ein /64 ist das Minimum was auf einem Netzabschnitt verwendet werden sollte. Da das extern also ein /64 ist hast du nichts fürs LAN oder irgendwelche VLANs was du benutzen kannst. /64 ist das Minimum da sonst etliche Funktionen von IP6 nicht mehr korrekt laufen (e.g. SLAAC etc.) die auf ein ordentliches /64er Netz minimum angewiesen sind.
Daher solltest du der pfSense extern/WAN eine IP6 geben, testen ob diese funktioniert und ob du diese von extern erreichen kannst etc. und wenn DIE auf dem WAN ordentlich funktioniert, dass du eingehende Pakete etc. darauf sehen kannst (System Logs/Firewall bspw.) DANN würde ich an deinen Hoster rangehen und sagen "hey ich brauche noch ein /64er das bitte auf diese IP6 geroutet werden muss". Machen eigentlich alle außer sie stellen sich wirklich dumm/stur an, da es bekannt ist, dass ein Kunde für den sauberen Betrieb mit mehreren Netzen mind. mehrere Netze und damit ein /60er oder /56er Prefix minimum benötigt. Für einen Single-Server reicht natürlich das /64, deshalb ist das dabei, aber wenn du damit virtualisierst, brauchst du mehr.
Grüße
-
Ich weiß nicht ob das relevant ist aber ich habe noch 2 Bridges auf dem Host (vmbr0 & vmbr1) für das WAN- & LAN Interface.
Wenn ich jetzt der VM die Bridge mit dem WAN Interface (vmbr0) zuweise und mit einer IPv6 aus dem Subnetz ausstatte
kann ich sie von außen anpingen. Ist das normal so? Ich verstehe auch noch nicht so ganz wozu ich jetzt noch ein Subnetz benötige, sind in dem Subnetz nicht genügend IPs oder verwechsle ich da grad was komplett.LG
-
@mdollenbacher said in IPv6 Ports mittels Firewall blocken:
Wenn ich jetzt der VM die Bridge mit dem WAN Interface (vmbr0) zuweise und mit einer IPv6 aus dem Subnetz ausstatte
kann ich sie von außen anpingen. Ist das normal so?Dazu kenne ich dein Virtualisierungssetup nicht gut genug um da zu sagen "yay" or "nay". Aber wenn du der pfSense auf dem WAN bspw 1234:5678:xyz::3 gibst, einen IPv6 Ping von extern machst und du in deiner pfSense dann auf dem WAN einen ICMP6 Blocked Ping auf die ::3 siehst, dann funktioniert scheinbar zumindest alles bis dahin erstmal sauber. Wenn die pfSense dann selbst mit nem Ping-Test bspw. ipv6.google.com pingen kann (was nur via v6 auflöst, deshalb guter Test), dann sollte das soweit OK sein.
Ich verstehe auch noch nicht so ganz wozu ich jetzt noch ein Subnetz benötige, sind in dem Subnetz nicht genügend IPs oder verwechsle ich da grad was komplett.
Moment, nein, ja. :)
Habe ich oben bereits geschrieben. Ja man KANN in IPv6 auch Netze kleiner als /64 vergeben, es wird aber von allen Obergremien von Netzwerkern in den RFCs darauf hingewiesen, dass das nur in Ausnahmefällen und nicht gern getan werden soll. Es gibt genug IP6 Prefix-Range, dass einem nicht die Prefixe ausgehen werden, nur weil man statt eines /127 oder /126 Transfernetzes zwischen 2 Geräten ein komplettes /64er Prefix nutzt.Wie schon oben beschrieben, IPv6 ist nicht IPv4. Es gibt völlig andere Techniken und Möglichkeiten mit IPv6 und diese benötigen zur korrekten Funktion ein Prefix mit /64er Größe. Außerdem gibt's keine NAT mehr. Zumindest nicht in der Form die man kennt und selbst dann sollte das nicht im Normalfall genutzt werden. Da dein /64er Prefix also extern auf dem WAN aufliegt, kannst du es innen auf dem LAN nicht benutzen. Punkt. Gleiches Spiel wie bei jedem normalen IPv4 Netz. Wenn du extern 1.2.3.4/24 benutzt, kannst du intern nicht auch 1.2.3.4/24 nutzen. So kann kein Routing funktionieren, daher klappt das nicht. Somit brauchst du ein zweites Prefix /64 (wenns nur um dein LAN geht) oder ein größeres Prefix wie /60 oder /56 aus dem du mehrere /64er rausschneiden kannst, damit du mehr als ein LAN/VLAN hinter der pfSense mit IP6 versorgen kannst.
Beispiel: ISP gibt für Server 2001:DB8:4321:8765::0/64 als Prefix.
Du vergibst jetzt der pfSense bspw. 2001:DB8:4321:8765::4/64 als IPv6 und ::1 ist dein Gateway (manchmal routen sie das auch direkt via fe80:: via link-local).
Jetzt hast du zwar tausende IP6 in dem Prefix zur Verfügung, aber die werden (im Normalfall) nicht zu dir geroutet, sondern du musst dir eine IP6 aus dem Netz geben um die zu nutzen (wie die ::4 auf dem WAN bspw.). Da es kein NAT gibt, kannst du jetzt aber nicht einfach die ::5 noch zusätzlich aufs WAN binden und die dann irgendwie intern reinschustern. So läuft Routing nicht.
Statt dessen brauchst du eben ein weiteres Prefix wie bspw. 2001:DB8:4321:9876::0/64 das dir vom Provider dann auf die 2001:DB8:4321:8765::4 - deine pfSense IP6 - geroutet wird. Dann wird das ganze /64 deiner pfSense zugeroutet und du kannst es auf dem LAN konfigurieren. Auf dem WAN musst du dazu nichts konfigurieren. Keine Alias IP o.ä. da das Prefix dir zugeroutet wird und eh bei dir ankommt. Lediglich Firewall Regeln für IP6 IPs aus dem neue Prefix musst du eben erstellen und damit den Zugriff zulassen. Auf das LAN kommt dann bspw. 2001:DB8:4321:9876::1 und dann können deine virtuellen Server hinter der pfSense alle IP6 aus diesem neuen Prefix bekommen bzw. du kannst diese statisch konfigurieren.
Bspw. 2001:DB8:4321:9876:1::1, 2001:DB8:4321:9876:2::1 oder auch 2001:DB8:4321:9876::1, ::12, ::13 - wie du dann die IPv6 Adressen nutzt oder vergibst, ist dann relativ egal. Meist bietet sich an, da ggf. was zu nutzen, was auch die IP4 erkennen lässt. Also wenn du 10.0.0.12 bspw. am Server hast, könnte man 2001:DB8:4321:9876:10::12 als IP6 nutzen, dann sieht man gleich welche Kiste das ist :)Was den Sinn o.ä. der Virtualisierung angeht, kann da vllt jemand mit mehr Proxmox Background was zu sagen :)
-
Hey,
ich habs jetzt hinbekommen, also nicht selber :/. Mein Freund hat mir geholfen und es geht jetzt.
Vielen dank für die ganze Hilfe.LG
Mathias