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.

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

Hallo Zusammen,

vielen Dank für die vielen Antworten.
Ich werde das ganze am Wochenende mal trennen.
Das macht Sinn ja. :)
Aktuell komme ich nur nicht dazu, weshalb das ganze hier etwas eingeschlafen ist.
Bei einem anderen Peer klappts scheinbar.
Sehe merkwürdig.
Aber ja, trennen macht sinn.

Danke erstmal.

Hallo @NOCling

danke, das war es; ich habe immer versucht das Monitoring auf das LAN zu verweisen.

Mit Allow SNMP (161) auf den WAN-Host und Allow ICMP auf den WAN-Host kann Check_MK jetzt die pfSense abfragen.

Danke!