@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: [image: 1594388752630-pfsense1.jpg] [image: 1594388769871-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: VPN/OpenVPN/Clients/Edit [image: 1594388934127-vpn1.jpg] [image: 1594388940242-vpn2.jpg] [image: 1594388944493-vpn3.jpg] [image: 1594388948758-vpn4.jpg] [image: 1594388956019-vpn5.jpg] Anbieter ist NordVPN und die Zugangsdaten (Username und Passwort) sind von hier: [image: 1594389033916-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. [image: 71a9c7820bab30ab8df6abf9876461d90808e6d0-04-07-2020.png]

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.

Ah weil der externe DNS eine interne/private IP zurückliefert, stimmt. Der Rebind Schutz bzw. private leakage protection, dass private Antworten für öffentliche DNS Anfragen abgelehnt werden weil es sich um Angriffe oder Cache Poisoning handeln könnte. Stimmt, bin ich auch schonmal drüber gestolpert, hatte ich bei der Problemstellung jetzt aber auch überhaupt nicht auf dem Radar! Danke für die Rückmeldung, das ruft dann die Sache wieder ins Gedächtnis, wenn es wieder mal irgendwo vorkommen sollte :)

@shiversc said in Hardware-Empfehlung - 19" Server: Ich denke kaum, dass das Setup am IRQ, PCIe-Lanes oder was auch immer gekränkelt hat oder das die Hardware zu wenig auf Netzwerk ausgerichtet ist/war. Die XEON-D sind z. B. was die 10 GB NICs angeht ein SOC-Design, somit kommt die PCIe-Lanes Betrachtung hier gar nicht zum tragen. Ich glaube kaum das eine Fullduplex-Auslastung dem kleinsten XEON-D was anhaben kann. Natürlich ist das Routing ein Faktor, aber ich route nicht, dazu habe ich was professionelles. Ahoi, warum die Xeon-Ds bei uns rausflogen war nicht die Netzwerk Performance. Das hatte ich schon geschrieben - uns sind die Dinger bei der Einrichtung und Konfiguration via UI eingeschlafen, eben weil sie auf Netzwerk optimiert sind. Sieht man auch im Hinblick auf TNSR ganz gut, dass HW wie die 3000er Denvertons oder eben die Xeon-Ds mit dem höher optimierten Linux und der CLI wesentlich höhereren Durchsatz wuppern als mit pfSense, da anderer Stack, anderes Processing und kein "klassischer" Webstack Overhead. Genau darum würde ich die eben nicht für pfSense mehr rannehmen, weil es einfach nervig ist, bei größeren/häufigeren Änderungen oder mit mehr Personen auf der UI zu arbeiten, weil die Dinger eben bei Webserver/PHP Working komplett absaufen gegen eine Standard Desktop CPU wie einen halbwegs aktuellen i5 oder i7. Lässt man die Kisten hingegen ohne große Änderungen einfach laufen ist das egal, da reichen die dicke - das war die Aussage - bevors jemand falsch versteht :) @shiversc said in Hardware-Empfehlung - 19" Server: Außerdem darf ich bei deaktivierten Hyperthreading auch wieder Proxys, Firewalls usw im ESXI betreiben. Ob das nur für Intel-CPUs galt und gilt, konnte mir niemand von den Auditoren beantworten ;) Hrhr :) Ja Audits sind da immer wieder ein Quell der Erheiterung... Aber: In dem Fall haben die ggf. sogar was Positives bewirkt ;) pfSense und FreeBSD profitieren nämlich tatsächlich kaum wenn überhaupt positiv auf Hyperthreading, weshalb das bei uns in der HW für Sensen auch immer aus ist. Klar kann man jetzt im Sinne von Meltdown und Co. auf HT rumreiten - das Fass fang ich gar nicht an. Muss man selbst abschätzen und klären. Aber HT ist für Firewall/Netzwerk Performance tatsächlich eher minimal bis gar nicht hilfreich, gabs auch gerade im Test mit FreeBSD mehrere Benchmarks, die das gezeigt haben. Daher lieber echte Kerne (weshalb die Atom 2k und 3k Serie so ausgelegt waren/sind) statt HT :)

@kibu_onlinedaten Danke für die Rückmeldung. Grüße