Ah es funzt u sieht schon viel besser aus :)

@Bob-Dig said in Wie mittels OVPN IPv6 ausleiten:

Anstandslos vielleicht, aber netcup möchte 1€ pro Monat dafür.

Sollte man sie mal daran erinnern, dass laut RIPE einem Kunden für sein(e) Netze ein /60 bzw. /56 zur Verfügung zu stellen ist. Finde das schon ein wenig frech.

@JeGr gerne. Dafür habe ich das Posting ja gemacht das man aktuelle Informationen findet.

Was @chpalmer schreibt. Es wurde schon mehrfach auch öffentlich hier oder auf der Netgate Seite publiziert, dass wenn die neue API implementiert wird (damals mit 2.5 geplant), AES-NI ein MUSS wird. Da die API aber bereits seit Mitte letzten Jahres für die 2.5 nicht angekündigt wurde weil sie sich verschiebt, wurde klar kommuniziert, dass 2.5 nun erst einmal kein AES-NI voraussetzen wird.

Es macht allerdings nach wie vor keinerlei Sinn heute noch Hardware (auch gebraucht, sei sie noch so billig) zu kaufen, die kein AES-NI kann, aus genau dem Grunde, dass in Zukunft sehr viel nur noch damit laufen wird. Selbst die letzten kleinen Kisten wie APU2 (3 & 4 sind auch nur 2er Boards mit Änderungen) haben das schon vor Jahren verstanden und laufen bereits so lange mit AES-NI Support. :)
Auch wenn ihr noch so günstig an irgendwelche alten verramschten Watchguard oder sonstwelche Boxen rankommt, die kein AES-NI haben, lasst sie doch einfach sein und organisiert euch was anderes, was wenigstens halbwegs modern ist ;) 2008 kam AES-NI in die CPUs. 12 Jahre später sollte man schon davon ausgehen können, dass man das als Requirement nutzen darf :)

Grüße
\jens

@PFsense-User2019 said in Portfreigabe klappt nicht:

das er mit dem Port 6666 ins Internet geht und auch noch nach dem NAT den Port 6666 hat?
Aber wieso ändert sich der Port nach dem NAT?

Einfach: Ein Gerät will eine externe Verbindung öffnen. Bspw. HTTPS. Dann spezifiziert das Protokoll: Server muss auf tcp/443 lauschen. Clients sollen von >1023 anfragen. Einfacher Fall, toll zu nutzen, denn keine Clients gehen sich gegenseitig auf den Keks. Füge NAT hinzu: immer noch kein großes Problem, denn selbst mehrere Kinder hinter der NAT können zum gleichen Ziel was aufbauen, weil die sich ausgehend eher selten überschneiden. Könnten sie aber! Und das bringt uns zum Problem: wenn jetzt 2 Clients sich entscheiden mit tcp/12345 abgehend zu senden und die gleiche IP aufrufen - was dann? NAT macht die IP Übersetzung und merkt sich 12345 interne IP -> 443 externe IP. Dann kommt der nächste - mit dem gleichen. Jetzt kommt die Antwort von extern -> wohin soll NAT nun die Pakete schicken? Oder anhand was soll es feststellen von wem die kamen? Geht nicht. Ergo randomisiert outbound NAT den Quellport zu irgendwas freiem in seiner Tabelle und schickt es so. Für HTTP/S bspw. ist der Quellport ja egal.
Zudem gibt es Möglichkeiten für IP Spoofing & Fingerprinting um herauszufinden, wieviele/welche Hosts hinter einem NAT stehen und ggf. deren Session zu klauen. Dagegen hilft Source Port Randomisierung. Und viele OS haben das historisch sehr lange sehr schlampig gemacht - wenn überhaupt (nicht genug Zufäligkeit).

Problem sind nun aber eben Dienste, die unbedingt wollen, dass die Verbindung von oder zu einem bestimmten Port kommt/geht. Die sind von einem zufälligen Port dann verwirrt oder funktionieren nicht. SIP bspw. oder auch IPsec. Daher gibt es für diese die Möglichkeit mit static port mappings. Da gehören dann auch "schlampige" Spiele rein, die P2P oder andere Mechanismen machen um keine eigenen Server nutzen zu müssen oder weil das angeblich so viel schneller wäre. Würde der Verbindungsaufbau schlicht über eine Art Connection Server gehen, an dem sich die Spieler anmelden (dafür sind oft genug die Lobbies) und anschließend werden die Verbindungen zusammengeschaltet geht das problemlos, da kein eingehender Verkehr benötigt wird. Bei P2P Sachen hat man meist einen oder mehrere bestimmte Ports die dann auf den jeweiligen PC/Konsole weitergereicht werden müssen (eingehend) ode die ausgehend gesprochen werden. Nur dann klappts.

Fun Fact: Du schreibst Satisfactory in deinem Screenshot: Dafür ist der ganze Spaß komplett unnötig 😁 Spielen hier 3 Menschis problemlos hinter NAT etc. miteinander. Einziges Problem ist da der Client und der EGS/Epic Binding zum Server, der oft beim ersten oder zweiten Mal Starten "strict NAT" ausgibt, beim Neustart des Spiels aber plötzlich auf Type 2 runtergeht (hinter NAT aber erreichbar) und Tada es geht. Muss man nur ab und an den Client mal neustarten bis der Server verstanden hat, was Phase ist 😃

Hallo Tim.

Hier ein echt verständliches Video in Deutsch.
Ist zwar nur auf LAN beschränkt, kannst aber ein Limiter mit 90 MBit/s erstellen und in die Allow Any to any Rule von VLAN 1 packen. Wo, wird Dir im Video erklärt. Dann bleiben Dir für VLAN 2 10 MBit/s über.
Ein Limiter für VLAN 2 ist ja nicht nötig. Bedenke aber, du kopierst Daten von VLAN 2 zu VLAN 1, greift dein 90 MBit Limiter, da ist dann nichts mit voller Bandbreite, Das sind dann nur gute 11 MB/s Traffic über deine Interfaces. Blöd, wenn Du ein Gigabitnetzwerk zu Hause hast. :)

Mike

Es sei denn, die willst dienste priorisieren, dann wäre der

Heute sieht es nach reboot so aus:
pfsense1.JPG

pfsense2.JPG

Ich habe ja nichts geändert an der ganzen Config.
VPN-PC ist ein "Dell Optiplex 7010 SFF Core i5-3470 4x3,2GHz 4GB 120GB SSD AMD 7570 DVD-RW W7P64"

Und als Beispiel die Config des Gateway unter:

VPN1.JPG

VPN2.JPG

VPN3.JPG

VPN4.JPG

VPN5.JPG

Anbieter ist NordVPN und die Zugangsdaten (Username und Passwort) sind von hier:

NordVPN.JPG

Und was mache ich jetzt ?

Wenns so einfach war, dann super! 👍

Also ich habe alles versucht.
Sobald ich das LAN-Interface von "Track Interface" auf "Static IPv6" umstelle, verliert der WAN2-Anschluss seine
DHCPv6 Konnektivität. Egal welche Optionen ich einstelle, auch ein Reboot hat nicht geholfen.
Vielleicht hat da jemand noch den "Stein der Weisen" und kann das erklären.

@mike69 Danke Mike

leider weiß ich ja nicht genau wo die Schweinerei passiert ist. Da ich wirklich nicht viel Erfahrung mit Netzwerken, Routern etc. habe habe ich natürlich immer wenn ich etwas verändert habe eine Sicherung angelegt. Da kommen schon so ca. 50 Sicherungen zusammen. Dann müsste ich wahrscheinlich jede separat einspielen und schauen ob sich danach der Limiter noch aktivieren lässt. Ich weiß allerdings nicht so recht ob es da nicht besser wäre die Kiste insgesamt neu aufzusetzen.
Danke für deine Hilfe. Ich weiß jetzt immerhin schon mal das die Konfig, so wie ich sie für den Limiter eingestellt habe, generell funktioniert. Es muss also an etwas anderem in der Konfiguration liegen.

LG, Thomas

@c-f said in DNAT auf Zieladresse hinter IPsec Tunnel:

Die pfSense baut einen VPN Tunnel zu Standort B per IPsec auf.

Ich nehme an einen IPsec Tunnel weil es in der Überschrift steht, aber zur Klarheit nochmal nachgefragt?

Ich hoffe, dass mir jemand mitteilen kann, wo hier die Herausforderung liegt.

Das wird nicht funktionieren wegen IPsec. Mit OpenVPN geht das. Problem daran ist einfach: die Phase 2 deines IPsec Tunnels definiert NUR eine LAN zu LAN Kopplung und definiert daher keinen Rückweg für Pakete, die irgendwo aus dem Internet kommen. Das bei einem Port Forwarding aber die Quelladresse (ein Client aus dem Internet) bestehen bleibt, kommt das Paket mit dieser Quelle an, wird umgeschrieben, durch den Tunnel geschickt, zum Client geliefert und dieser möchte antworten - aber der Rückweg für diese Antwort ist dann das Internet von Seite B. Es gibt schlicht keine Möglichkeit - außer allen Traffic von B über IPsec zu A zu schicken - um das Paket zurückzusenden.

OpenVPN funktioniert an dieser Stelle anders, da es hier durch Policy Based Rules und durch den PF eigenen Mechanismus "reply-to" einen Weg gibt, der sicherstellt, dass Antworten von gewissen States wieder zurück über den VPN Tunnel laufen. Bei einem OVPN Tunnel kann einfach in der Tunneldefinition selbst ein zweites NATting definiert werden, dass alle Pakete von "nicht LAN A" an LAN B auf die Tunnel-IP NATtet. Dadurch finden die Pakete bei einem OVPN Tunnel den Rückweg wieder und gehen durch den Tunnel zurück zu Site A und von dort aus wieder ins Internet (sofern alles korrekt konfiguriert ist).

Ohne einen Proxy zu nutzen, wird das also mit IPsec leider nicht funktionieren. Mit Proxy (bspw. HAproxy) kann es klappen wenn man Offloading nutzt, da dann die Verbindung im Proxy terminiert und neu geöffnet wird. Somit kommt für den Client auf Site B die Verbindung von Site A und die Verbindung kann hergestellt werden.

Ne, Ingress habe ich eigentlich kaum. Wenn, dann ist die Leitung meist wirklich down nachts, wegen Wartungsarbeiten. Danach geht nur leider der Graph nicht mehr, dabei ist es auch egal ob IPv4 oder v6. Die States sind offen, werden aber nicht mehr genutzt. Für mich ist das ein Bug seit 1-2 Versionen.

Bild Text

Kann ich nichts zu sagen, bin ich nicht wirklich aktiv, 2 Foren und ein Reddit hin und wieder reichen schon mehr als genug 😲

@DerTom24 said in Jeweils einen DHCP-Server pro VLAN einrichten - geht das?:

die Zuweisung der Vlans zu einem bestimmten WAN (1 x Fritzbox, 1 x über VPN-Box) über eine Firewallregel zu bewerkstelligen.

Ich glaube das rührte eher daher, dass sich noch niemand wirklich vorstellen konnte, wie das Konstrukt aussehen soll.
Zuweisung per Regeln ist der einzige Weg VLANs das entsprechend mitzugeben. Man muss nur darauf achten, dass anderer Traffic der ggf. intern laufen soll eine eigene Regel mit Default GW benötigt, da eine Regel mit aktiviertem Gateway allen Traffic über dieses GW über die Firewall zu schieben versucht. Auch etwas, was ggf. intern laufen soll - daher muss das darüber mit einer extra Regel abgehandelt werden.

Bspw.: VLAN 46 soll via WAN 2 ins Netz. VLAN 46 soll aber VLAN 23 trotzdem erreichen können. Dann braucht es eine allow VLAN 46->23 Regel mit Default GW (*) und darunter eine VLAN 46 to any Regel mit GW WAN2.

Grüße

@pipen1976 said in 2x DSL Anschluss Gateway:

Es funktioniert. Unter NAT/Outbound hatte ich vergessen das Interface umzustellen. Vielen Dank für Eure Hilfe.

Ah super :D Das wäre die nächste Sache gewesen ;)

Danke schön für deinen Einsatz. Ich bin noch einige Tage dabei an den Servern was zu machen. Danach werde ich mir die Rules auf der Fortigate anzeigen lassen und auf die PFsense übertragen. Das sollte soweit kein Problem sein.
Einzig mit dem VPN habe ich Probleme. Da werde ich aber noch mal einen Post starten.
Danke, Sebastian

Danke euch beiden!
Dann werde ich mal langsam das Projekt angehen. Meine APU Büchse arbeitet schon länger an der Kotzgrenze. 😀

Zwischen zwei PPPoE Verbindungen, mit einer Path-MTU von 1492 Bytes, bekommt man mit ESP und AES-GCM Verschlüsselung im Tunnel-Mode max. eine MTU von 1438 Bytes (1398 MSS) für die IPSEC-Verbindung hin. Sollte ESP in UDP verpackt werden müssen, z.B. aufgrund von finsteren Dual-NAT Konfigurationen, sind es entsprechend 8 Byte weniger.