Noch eine Ergänzung: Das Zerlegen in mehrere Regeln ist auch für das Logging vorteilhaft, weil feiner steuerbar.

-flo-

Ok, ich sehe schon… ich habe mich wohl etwas unkorrekt ausgedrückt und deswegen kam es zu einem Missverständnis, sodass wir nun etwas aneinander vorbei reden. Ich versuche es noch einmal zu erklären, Schritt für Schritt:

1. unter Tunables steht das "filter member" auf 1 und "filter bridge" auf 0
2. ich erstelle eine Gruppe und dort müsste ich ja Interfaces definieren, welche zu dieser Gruppe zusammengefasst werden
3. laut Punkt 1 müsste ich für die Gruppe ja LAN, WLAN und oVPN_Server Interfaces definieren => aber es geht nicht, ich werde ausgesperrt (da auf den LAN und WLAN Interfaces keine Regeln vorhanden sind und die LAN Anti-Lockout-Rule - warum auch immer - nicht greift; wobei ich es auch mit pass-any versucht hatte)
4. erst, als ich die Bridge (ich habe bisher immer dort alle meine Regeln erstellt und verwaltet) in die Gruppe aufnahm, lief alles nach Plan - ich konnte wieder auf die Sense zugreifen und es wurden alle unter dem Bridge Interface angelegte Regeln angewandt
5. danach habe ich alle Regeln aus dem Bridge Interface in die Gruppe übertragen und soweit funktionierte nach wie vor alles wunderbar
6. nahm ich nun die Bridge aus der Gruppe raus (LAN und WLAN blieben drin), wurde ich wieder ausgesperrt; trotz Punkt 1

Genau das war bisher mein Problem, welches ich absolut nicht nachvollziehen kann. Denn nach meinem Verständnis sorgt das "filter member" 1 eben dafür, dass die Regeln der einzelnen Interfaces (und nicht der Bridge) bzw. die Interfaces selbst bevorzugt behandelt werden sollen?! Dass ich es mit "filter member" 0 + "filter bridge" 1 und Löschen der LAN und WLAN Interfaces aus der Gruppe in die richtige Wege leiten kann, habe ich mittlerweile verstanden und werde es bei Gelegenheit umsetzen.

Servus,

ich möchte prüfen, ob die Freifunk-Router tatsächlich nur über das DSL-Gateway kommunizieren. So wie es unter Diagnostic/States aussieht, wenn ich die IPs der Freifunk-Router filtere, ist alles in Ordnung.

Danke für die Info!

Grüsse

Ralf

@Crunk_Bass:

Danke für deine Rückmeldung.

Was willst du genau am Freifunk überprüfen?
Falls es um aktuell bestehende Verbindungen geht kannst du dir diese unter Diagnostics -> States aufzeigen lassen.
Dort einfach nach der IP des Freifunk Routers filtern.

Wenn du in der Firewall Regel als Gateway direkt das DSL Gateway ausgewählt hast und keine Gatewaygruppe dann wird auch kein Failover betrieben.

Hi,
danke für die Antwort. Ich besorg einfach mal 4 GB RAM. Das sollte reichen.

Was meinst du?

Grüße

Heinz Krischeu

Was Chris sagt. Zudem:

1. OPT1 nicht mit LAN kommunizieren darf

auf OPT1 Interface: a) block rule opt1 net nach lan net, b) allow any any

2. WAN nicht mit LAN kommunizieren darf

WAN darf per default GAR NICHTS. Das ist eine Firewall, keine Fritzbox :P

3. WAN nur eingeschränkt mit OPT1 kommunizieren dar
      (näher: WAN -> OPT1 nur Port 0 - 1023; OPT1 -> WAN nur Ports >=1024)

Warum? Port 0-1023 ist mal unsicher wie nur was, da da unter anderem Ports und Protokolle dabei sind die im Internet kein Mensch haben will oder die nicht verschlüsselt laufen, was man heute ebenfalls nicht haben will. Wenn man schon Ports REIN lassen will, dann nur die Dienste die man auch braucht. Dafür gibt es Aliase und damit kann man das problemlos zusammenfassen (SMTPS/Submission/POP3S/IMAPS bspw.). Aber mal kurz 1024 Ports aufzumachen … kurz nachdenken ... nein! Die andere Anforderung - OPT1 nach WAN >1024 hört sich nach Standard-Antwort Traffic bzw. Client Traffic an. Die Anforderung ist auch quatsch, entweder OPT1 spricht mit WAN, dann geht die Verbindung auf nen Server Port (meist <1024) - der Rest geschieht Stateful (das ist der Job der Firewall, dass man für den Antwort Traffic nicht auch noch Regeln machen muss) oder es geht andersherum, aber auch dann brauche ich keine Regel für Antwort Traffic.
Da du nichts über die Anbindung schreibst (public/private IPs) sollte da noch ggf. NAT ausgeschaltet werden (wenns überall public Adressen sind) bzw. manuell konfiguriert, damit nur das genattet wird was sein muss.

Trotzdem klingt gerade 3. für ein Wohnheim sehr dubios. Da stimme ich Chris zu.

Gruß

Ich frage mich da eher, warum der Rechner überhaupt vor der pfSense steht. Das Setup macht mir keinen Sinn. Und die Aussage dass du für DMZ nicht "erfahren genug" bist, ist zum einen quatsch (wie anders als durch Einsatz will man das denn lernen) und zum anderen ist eine DMZ im Grundprinzip auch erstmal nichts anderes als ein weiteres "Bein" bzw. Netz an deiner Firewall das eben andere Behandlung bekommt. Die wenigstens werden hier ein Multi-Tier-Firewall Konstrukt aufmachen, weil das allein schon wieder zusätzlichen Aufwand bedeutet was Routing und Regelwerk etc. angeht.
Und dein WLAN bspw. ist ja bereits ebenfalls eine separate Zone - also fast schon DMZ Behandlung. Darum erschließt sich das ganze Setup nicht wirklich.

Den auf der Zeichnung umkreisten Server habe ich als exposed host in der Fritzbox eingetragen und kann nur aus dem Internet darauf zugreifen. Leider besteht keine Möglichkeit von genau diesem Rechner ins LAN oder ins WLAN zu kommen. Umgekehrt geht es eigenartigerweise. Ich kann von jedem Interface der pfsense den Server pingen.

Nicht wirklich ungewöhnlich, da die pfSense logischerweise abgehend beide Netze nach draußen NATtet und damit den Weg ebnet. Umgekehrt hat dieses Zwischennetz auf dem WAN natürlich keinerlei Rechte bis du auch was aufmachst.
Zusätzlich müsstest du wahrscheinlich die Outbound NAT Settings ändern, dass nur Verbindungen ins Internet genattet werden, aber in das Zwischennetz der Fritzbox wo der Rechner steht nicht. Ansonsten werden die Pakete da nie korrekt ankommen.

Das ist aber alles wie du siehst ziemliche Fummelei die komplett unnötig wird, wenn man einfach alles als einzelnes LAN bzw. VLAN hinter der pfSense konfiguriert.
Dann muss lediglich in der Fritzbox die pfSense als exposed Host wie du richtig erkannt hast eingetragen werden und fertig. Keine zusätzlichen seltsamen Regeln in der FB mehr. Alles andere kannst du dann auf WAN Seite der pfSense konfigurieren.

Grüße

Problem ist nun natürlich das oben genannte, Fritzbox wählt sich neu ein, andere Präfix und zack ist mein IPv6 tot…

sollte so nicht sein. Aus anderen Gründen fahre ich schon lange die 2.4 Beta und das funktioniert nach Anfangsschwierigkeiten sehr gut.

Was aber mir irgendwann aufgefallen ist - wenn die Fritze z.B gebootet wird oder aus einem anderem Grund eine Einwahl erfolgt, muss ich danach die Sense booten, sonst klappt das nicht wirklich zuverlässig mit ipV6

Die PF hat aber immerhin schon eine V6 am WAN.
    fe80::20d:b9ff:fe36:6958%re0

Ich wurde sagen, nein oder anders - die hat nicht das was Du Dir erhofft hast. Schaue zum Vergleich die IPV6 an der Fritze an
Ich habe mich auch an die 2 Anleitungen gehalten - lief damit aber nicht. Bin jetzt nicht 100% sicher - meine da stand was davon, dass IPV6 over IPV4 gefahren werden soll, und zumindest bei mir dürfte hier

"Request a IPv6 prefix/information through the IPv4 connectivity link" kein Hacken gesetzt werden.

Hallo,

Dann wird Dir nichts anderes übrig bleiben, als Remote Gateway auf 0.0.0.0 zu stellen. Dann werden alle eingehenden IPs akzeptiert, die einen Tunnel aufbauen wollen.

Viele Grüße
Tino

Ich habe heute nochmal ein wenig mit einer Lidl Mobile SIM (stammt aus einem Lidl Surfstick) in meinem Netgear LB1111 herumgespielt. Interessanterweise musste/konnte ich heute keinen Tarif auswählen. Nachdem die SIM in dem Modem war und das Modem Strom hatte, ging es online und es kam auf dem Gerät (zeigt das Netgear an) eine SMS von Fonic, dass automatisch eine 24h Flat (1 GB) vom Guthaben abgebucht wurde.

Ich muss das mal im Auge behalten. Wenn es so weitergeht, wäre das ja auch eine Lösung. Eine externe IPv4 bekommt man da zwar auch nicht, aber wenn das bei den (bezahlbaren) Alternativen auch ein Problem ist, dann arbeite ich erstmal mit einem von innen aufgebauten VPN-Tunnel zu einem System mit externer, fester IPv4.

Wenn das mit der Lidl SIM nicht verlässlich funktioniert, teste ich sonst mal das Vodafone-Angebot.

Danke!

So könnte man sagen, ja. Und der Einsatz von doppeltem NAT ist - auch wenn ich hier gebetsmühlenartig werde

Ja ja ich habe es umgestellt :D, weil es auch ein "Vorteil" für mich bringt.

Ich habe ein /sbin/mount, mit dem ich NFS shares mounten kann.

funktioniert bei mir.

@JeGr:

Da sollte auch 22 stehen, da das Paket ja VOR Eintritt in den Regel-Tab bereits in 192.168.0.248/22 umgeschrieben wird.

So läuft, hatte einfach die Umsetzungsreihenfolge der Regeln Firewall / NAT verpeilt gehabt, danke

-teddy

@JeGr:

Hi,

mehrere gleiche Tiers sollten den Effekt haben, dass Verbindungen über die Gateways des Tiers entsprechend round robin rausgehen und damit beide Leitungen nutzen. Das ist zumindest auch das Bild, was wir hier in verschiedenen Setups sehen. Beispiel 4 verschiedene GWs an 4 Leitungen -> die Clients dahinter teilen sich die Bandbreite der 4 Gateways. Fällt eines aus, steht eben insg. nur noch die Bandbreite von 3 zur Verfügung. Natürlich ist das kein "schön gewichtetes" loadbalancing und kein additives Setup (3x50 MBit/s != 150MBit/s) aber in den Setups wo es genutzt wird, sind die Clients deutlich zufriedener (gerade wenn man jetzt häufiger mal Linespeed hat ;)).

Ja, das mit den gleichen Tiers habe ich verstanden, dass es wohl ein "einfaches" Failover ist. Aber wie gesagt, mich interessiert es, wie es aussieht, wenn in jedem Tier mehr als 1 Gateway definiert ist? Wird es dann genau so gehandhabt, als wäre nur 1 GW pro Tier eingerichtet (dass das Tier erst dann gewechselt wird, sobald alle enthaltenen GW's down sind) oder gibt es eine gewisse Ausnahmeregelung (Umschwung auf ein anderes Tier bereits beim Ausfall eines GW's)?

@JeGr:

State Killing tut genau das, macht aber IMHO eher bei so etwas wie VPN Verbindungen Sinn, wo natürlich die Verbindung gekillt werden soll, wenn das VPN down ist, damit kein Traffic unverschlüsselt über die Leitung tröpfelt. Für ein LoadBalancing Setup ist das eher unpraktisch, wenn dann eher bei einem Failover Setup, bei dem die 2. Leitung kleiner ist als die primäre und man erzwingen will, dass die Verbindungen wieder über die primäre Leitung aufgebaut werden (und nicht erst wenn der State mal einen Timeout bekommt).

Gruß

Also, wenn man das automatische Wechseln der Gateways per Rules unterbunden hat, dann gibt es keine Vorteile beim State Kill, richtig?

Jetzt habe ich aber 2 Netzwerkkarten

Mit gleicher IP bzw. IP Subnetz? Oder was möchtest du jetzt genau sehen? Und wo hast du 2 Netzwerkkarten? Das klingt alles ein wenig wirr.

Gruß

Danke für die Antworten

"Block private networks and loopback addresses" Häkchen ist an der WAN ist aus.

Also ich habe mittlerweile alles Probiert,
das mit der Statischen IP funktioniert einfach nicht, ich weis nicht mehr weiter.

Das einzige ist wirklich eine Private DHCP Adresse per Kabelrouter zu erhalten und dann mittels dhclient.

Werde erstmal mit dem Workaround leben.

Vielen Dank erstmal für eure Zeit und ideen

Kurz mal der Stand der Dinge:

Die Zugabe von

link-mtu 1400

in die Client-Konfig hat das Problem scheinbar behoben.
RDP funktioniert und die Datenübertragung beim Kopieren von Files startet jetzt. Der Durchsatz scheint sich im normalen Bereich zu bewegen.

Wir testen mal noch die Testinstanz mit fragment/mssfix, so wie der alte VPN-Server von der alten ipfire konfiguriert war.

Danke erstmal für die Antworten. Wenn ich neue Erkenntnisse habe, werde ich diese hier posten.

Ja mit 2.4 läuft das erst wieder brauchbar. Die Verbindung bricht nicht weg, aber der DSN startet neu und kann in dieser Zeit keine Antworten geben.

Gruß
pfadmin

Hallo,

@alex.f:

        Internet             :       .-----+-----.       |  pfSense  |------- DMZ (192.128.2.0/28)       |  OVPN S  |       '-----+-----'             | 172.16.2.1             |             |        Tunnel Net: 172.16.0.0/30             |             | 172.16.2.5       .-----+-----.       |  pfSense  |       |  OVPN C  |       '-----+-----'             | 10.0.2.4             |           LAN

eine VPN ist eigentlich dafür gedacht, über ein unsicheres, also meist öffentliches, Netz zu verlaufen. Auf ein /30er Netz trifft das wohl nicht zu.
Ein Testaufbau?
Wie auch immer, die VPN sollte auch hier funktionieren, wenn auch sinnfrei.

@alex.f:

Serverseite IPv4 Remote network(s): 10.0.0.0/8

:o Ist diese Netzbreite tatsächlich erforderlich?
Besser ist es, diese so schmal als möglich zu wählen.
Wenn alle Angaben stimmen, sollte aber auch das kein Problem darstellen.

Wie sieht deine Client VPN Konfiguration aus?

Laufen am Client noch andere OpenVPN Instanzen?

Wie sieht die Routing-Tabelle am Client aus?