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.

Ist ein bekannter Bug in 2.4.1, einfach auf 2.4.2 updaten.

https://www.netgate.com/blog/pfsense-2-4-2-release-now-available.html

Danke für deinen Tipp, blex.
Jedoch muss doch dies dann im SquidProxy definiert werden, oder woher weiss er denn welche IP er verlässt?

Gruss

Scheint heute ein Störung bei 1und1 zu sein

Hier müsstest du mal schauen was nicht geht.
Normalerweise hat das iPad eine ip aus einem VPN Netz.

Jetzt weis dc1 wie er da hin kommt da der Tunnel bei ihm endet. Dc2 weis es nicht. Er wird den Traffic vom iPad an das default fw. geben was wohl nicht dc1 sein dürfte. Somit kommt es nicht an.

Diese These zu testen ist einfach. Schau auf dc2 mit wireshark oder ähnlichen Tools nach ob Pakete ankommen und welche Absender ip diese Pakete haben. Siehst du Pakete vom iPad Bingo.
Die Lösung ist dann auf dem default Gw eine Route zu setzen die zu dc1 zeigt. Dies führt aber zu asynchronem routing

Ist das Setup aber anders z.b. iPad <- VPN -> pfSense < - Network -> dc1 hast du ein anderes zenario.
Dann wäre von Interesse wie du das von auf der pfsense konfiguriert hast. Wenn du hier ein paar Details schreibst können wir dir sicher weiterhelfen.

Gruß blex

@ JeGr

Deine Aussage "kaputtkonfiguriert" macht mich etwas stutzig.

Meine Konfiguration ist folgende.

pfSense Interface Assignment
NIC 1 als WAN
NIC 2 not assigned
VLAN10 auf NIC 2 (IP: 192.168.10.0/24)
VLAN20 auf NIC 2 (IP: 192.168.20.0/24)

pfSense Firewall VLAN10 (von oben nach unten)
1. Allow IPv4 * VLAN10 net Port * –> VLAN10 address Port *, Gateway *
2. Block IPv4 * VLAN10 net Port * --> VLAN20 net Port *, Gateway *
3. Allow IPv4 * VLAN10 net Port * --> * Port *, Gateway * (also auf any)

pfSense Firewall VLAN20
gleiche Konfiguration, wie VLAN10 nur mit VLAN20

24Port Switch
Port 1: Tagged VLAN10 und VLAN20 (hier ist pfSense angeschlossen) / PVID: 10
Port 2-10: Untagged VLAN10 (hier sind Rechner angeschlossen) / PVID: 10
Port 11-15: Untagged VLAN20 (hier sind Rechner angeschlossen) / PVID: 20
Port 16: Untagged VLAN20 (hier ist der Access Point angeschlossen) / PVID: 20
Port 17-23: diese Ports sind deaktiviert, gehören aber dem Default VLAN 1 an (hier sind logischerweise keine Geräte angeschlossen) / PVID: 1
Port 24: Untagged Default VLAN 1 (hier stecke ich einen Rechner an, wenn ich den Switch konfigurieren möchte) / PVID: 1

Die Port Security aller Ports steht auf 1-24, ist somit deaktiviert.

Die Konfigurationen von pfSense und dem Switch sollten doch so richtig sein, oder?

Vielen Dank nochmal,
KHR

nur für meine Weiterbildung. Warum war es nicht möglich in der VMWware über die LAN Schnittstelle zuzugreifen?

Ich würde denoch empfehlen den Zugiff auf die pfS über WAN (wenn überhaupt) über eine einzelne Firewall regel zu erlauben und dann die Firewall wieder zu aktivieren.

Gruß

Hagen

My Friends

So nun hier die Auflösung:

APU3B4 mit PFsense Version 2.4.1 und upgrade BIOS auf (apu3_v4.0.11.rom). Temperatur bei 61.5.  ;D

Cheers Laura

Vielen Dank an @JeGr, ich habe es endlich sauber gelöst bekommen.

Super! Vielen Dank auch für die Rückmeldung, freut mich dass es geklappt hat :D

OK. Man kommt auch im bridge-Modus auf den Vigor, sofern man denn ohne VLAN-Tag darauf zugreift.
Besten Dank nochmals.