^das und
wenn in der pfSense nur das eigene WAN als Gateway konfiguriert ist (default), dann weiß sie ja nicht, wohin sie Pakete, die über einen anderen Router zu ihr kommen, beantworten soll.
Also erst den anderen Router als eine weitere Gateway IP eintragen (nicht default machen, Monitoring kannst Du vermutlich ausschalten) und dann eine Static Route zum entfernten subnet über dieses Gateway setzen.

Wenn Du zwei Seiten miteinander verbinden willst, dann musst Du routen. Das geht nicht im gleichen Netz, dafür braucht es zwingend unterschiedliche Netzbereiche.
Gleiche Netzbereiche miteinander zu verbinden bedeutet bridgen (stretched LAN). Bei einer Site-to-site Bridge musst Du wiederum aufpassen, dass keine IP doppelt vorkommt. Das macht man gelegentlich, um ein Netzwerk in ein DataCenter zu "verlängern". Zwei bestehende Produktiv-Netzwerke zu bridgen wäre … mutig.

Hallo Blitz,

und 2) deshalb, da dir ansonsten jede Möglichkeit fehlt, Dienste konkret einem WAN zuzuordnen. Da jedem WAN Interface ein Default GW zugeteilt ist, kannst du bei deiner Variante mit einem WAN und 2 Gateways darin keinen Service auf bspw. der Sense konfigurieren, der Default über WAN2 rausgeht, da dein WAN-gebundener Service stets das WAN Default GW nehmen würde. Das zu überschreiben wäre mit Floats etc. zwar theoretisch denkbar aber mühselig und unpraktisch, deshalb wird in jeder Doku bei MultiWAN auch zumindest von 2 Schnittstellen (egal ob phyisch oder VLANs) gesprochen. Ich würde 2 WAN GWs im gleichen WAN Subnetz vor der Sense als fehleranfällig betrachten bei der Umsetzung.

Darum würde ich das eher auf eigene Interfaces packen :)

Servus,

du hast ja prizipiell 2 Stellen wo man in deinem Fall den Primären Anschluss auswählen kann.

Einmal Direkt unter Routing->Gateways und einmal unter Routing-Gatewaygruppen.

In deinem Fall ist es völlig irrelevant, welches Gateway unter "Routing>Gateways" als Default eingestellt ist, es ist einzig entscheidend welches Gateway in der Routinggruppe die höhere Priorität besitzt.

Wenn also dein Ovpn-Client primär über Wan2 rausgehen soll, muss in der angebenen Gatewaygruppe Wan2 die Stufe1 (Tier1) und WAN1 die Stufe 2 (Tier2) besitzen.

Wenn du es genauso eingestellt hast, sollte es dann auch funktionieren. (So die Theorie)

Achso nochwas, wenn die Verbindung über WAN1 schon aufgebaut ist und erst dann WAN2 wieder aktiv wird, musst du aller Vorraussicht die VPN Verbindung kurz unterbrechen. Da eine bestehende Verbindung nicht geswitcht wird.

Gruß
Rubinho

Ja wenn du die Sense in den Switch der Fritte einsteckst und deinen eigentlichen Switch mit Clients an das LAN der Sense brauchst du keine VLANs.

Ansonsten hat die DHCP Geschichte etc. Rubinho schon völlig beantwortet :)

Servus,

das entspricht ja quasi dem, oder?

diese dann in Regeln auf deinem LAN Interface einbinden und damit dann den Traffic routen -> PBR (Policy based routing). Einfach eine Regel VON "LAN net" nach "LAN_der_anderen_Seite" via (Adv. Settings öffnen, GW auswählen). Damit wird dann jeder Traffic der darauf matched durch die Tunnel gezwungen.

Ist auch so gemacht, funktioniert nur leider nicht. Ich kann per tcpdump. auf dem vm-Host sehen, wie die Ping-Pakete durch das normale WAN-Gateway rausgehen und irgendwann vom Rechenzentrums-Router verworfen werden, da private subnetze.

Diese PBR-Regel greift so leider nicht. Ich verstehe auch nicht warum, da diese ja ziemlich eindeutig ist. Kann es sein, dass sich "LAN" da nicht zuständig fühlt, da weder ein Interface eine IP in diesen Subnetz hat, noch eine "normale" routing-Regel vorhanden ist, die das ziel-subnetz beschreibt?

Wie kann ich feststellen, wie weit die Pakete kommen?

LG, Freisei

Hängt stark von der Leitungsbreite und der Performance der Kisten ab. Wenn das kein Problem darstellt würde ich persönlich OpenVPN den Vorzug geben. Einfacher und schneller einzurichten und ggf. kannst du damit auch durch PBR bestimmte Sachen anders routen als definiert. Einfach flexibler.

https://forum.pfsense.org/index.php?topic=137103.0 alles lesen, nicht nur die erste Seite.

Aufgrund der Frage hatte ich angenommen das Du von den Netzwerkkenntnissen vielleicht noch keine VLANs eingerichtet hast.

Das ist zwar nicht schwer setzt aber einen Managed Switch voraus und hat eine gewisse Lernkurve.

Ich kann aus den Informationen auch noch nicht erkennen das Du das überhaupt brauchst.

Hast Du schon mal VLANs eingerichtet und brauchst Du überhaupt getrennte WLANs?

Wenn nein kannst Du den AP einfach an Deinen Switch hängen und fertig. Administration ist sowieso getrennt.

Brauchst Du getrennte WLANs dann wirst Du um VLAns nicht herum kommen. Das ist dann aber nicht einfach so eben mal so mit zwei screenshots gemacht.

Gruß

Hagen

Autsch, da habe ich beim zweiten Teil der Frage nicht richtig aufgepasst. :-(

Kann passieren, kein Beinbruch :)

Am Switch hab ich meine VLANs (Alle untagged, Trunks) wie oben also mit der IDs: 150, 160, 190 definiert und das selbe am Firewall als Interface konfiguriert.

WO als Interface? Alle 3 als einzelne physikalische Ports? Oder alle 3 als VLANs eines physischen Ports mit dem du zum Switch gehst? Das ist nicht klar.

Ich habe auch den Firewall mit meinem Modem verbunden und mit switch allerdings nur durch LAN Anschluss vom Firewall: 10.1.10.1.

Was hat jetzt 10.1.10.x wieder für eine Bewandnis? Du hast doch angeblich nur 50, 60 und 190? Und was ist jetzt "LAN" Anschluß. Der LAN Port der 4860? Die hat ja nun 6 Interfaces, also WELCHER Port? Oder doch mehrere? Das ist alles recht konfus.

Mein Ziel ist aber dass meine Geräte im LAN 10.1.50.1-x bekommen und meine WLAN 10.1.60.1-x . (Bridge vielleicht ?)

Warum Bridge? Was hat die damit nun noch zu tun? :o Wenn das alles getrennte Netze sind, muss doch nichts gebridget werden?

Ich will das ich die OPTs als Ausgang zum Switch nutze

Nochmals: OPT ist irgendeine interne Bezeichnung, die alles mögliche (VLAN, echtes Interface, etc.) definieren kann. Mag sein, dass das bei der SG außen drauf steht, dann aber doch bitte einfach dazuschreiben, dass echte Ports gemeint sind oder nicht. So ist das gerade alles extrem undurchsichtig und wäre einfacher wenn du einfach mal eine Skizze machen würdest, was du womit meinst.

an jeweiligen Ports (VLANs) anschließen und sie die IP Adresse vom jeweiligen VLAN bekommen, aber ich verstehe nicht we man das macht.

OK Bitte Skizze. -.-
Ansonsten können VLANs intern genauso behandelt werden wie jedes andere physikalische Interface und dementsprechend auch problemlos einen eigenen DHCP Server o.ä. aufgesetzt bekommen.

Also der Switch hat ja sozusagen die VLANs was von einander nichts wissen und Trotzdem soll WLAN ins LAN zugreifen können und das macht man in der Konfiguration vom Firewall richtig ?

Richtig, im Routing zwischen den Netzen werden dann entsprechend auf den eingehenden Interfaces die Regeln aufgelegt wer wohin warum mit wem reden darf.

Gruß

Servus,

ich habs gefunden. Es hatte nicht mit OpenVPN zu tun, sondern mit der Virtualisierung.

"Disable hardware checksum offload" und jetzt läufts.

Grüße, Freisei

Sprich nach Update auf 2.4.2 ist der Sync-Portal-Bug weg (den du wohl auch hattest)? :)

danke für deine antwort, sonst klappt alles aus meinem lan.
danke noch für den tipp, ist warscheinlich passiert bei testen

Also ich glaube die Lösung für die langen Verbindungszeiten gefunden zu haben. Kann es sein, dass Vodafone und Unitymedia sich nicht mögen und untereinander schlechtes Routing haben?

Jedenfalls glaube ich, dass es daran gelegen hat. Habe einige Traceroutes aus dem Mobilfunknetz zu meinem heimischen Anschluss gemacht und es dauerte halt etwas länger bzw. gab an 2 Stellen diese langen Timeouts.
Danach habe ich Traceroute zur öffentlichen IP eines in der pfSense eingerichteten OpenVPN Clients gemacht und siehe da - alles lief schnell und in 1-2 Hops weniger durch.

So habe ich auf der Serverseite des VPN Tunnels eine Portweiterleitung und als WAN meines pfSense VPN Servers eben die o.g. öffentliche IP eingerichtet. Gleichzeitig den server-poll-timeout auf 3(!) Sekunden runtergesetzt. Was soll ich sagen? Läuft top und nur absolut selten brauchen die Clients länger als 3 Sekunden, noch deutlich seltener als beim 5-sekündigen Verbindungsaufbau zu meiner WAN IP.

@kebeil:

Edit:
Ich habe jetzt vom Log die Easyrule gesetzt. Damit gehts. Aber was macht diese Regel anders als meine any any???

Um das beurteilen zu können, müsste man dein Regel-Set von WAN und Floating kennen.
Vielleicht der Port, vielleicht das Protokoll, vielleicht die Reihenfolge?  ???

Servus,

nein das hab ich noch nicht Probiert aber wie gesagt ich hab auch ein Problem mit legacy mit 2.4.1 …
Ich blein jetzt ertmal auf 2.3.5 bis nächstes Jahr in nehme mich dann nochmal der Sache an. Verückt ist auch das ich 2 gleiche Server im betrieb habe also absolut identisch und beim zweiten gab es keine probleme beim update auf 2.4.1.