OK. Ich glaube ich hatte da gestern nen kleinen Denkfehler. Als ich heute morgen aufgewacht bin wusste ich wie es funktionieren könnte. Für jeden den es interessiert:

Unter Firewall -> NAT -> Outbound habe ich nun beide Netze komplett freigeschaltet:

WAN      10.0.0.0/20 *    *    *    *    *    YES  Rule for LAN   
WAN      172.21.0.0/22 *    *    *    *    *    YES  Rule for Captive Portal

Dann hab ich mir unter Firewall -> Aliases einen Alias (cp_allowed) erstellt in dem dann immer alle Ports eingetragen werden können.
Dann habe unter Firewall -> Rules als unterste Regel erst mal sämtlichen Traffic aus dem CaptivePortal-Netz in andere Netze geblockt:
X  * CaptivePortal net * * * *

Darüber habe ich dann einen Zugriff erstellt, dass der Router noch erreicht werden kann (sonst geht nix):

TCP/UDP CaptivePortal net * 172.21.0.1 * *

Darüber habe ich dann noch einmal einen Block erstellt auf die Ports für SSH und HTTPS auf den Router selbst (cp_blocked ist ebenfalls ein alias):
X  TCP/UDP  CaptivePortal net  *  172.21.0.1  cp_blocked  *

Darüber habe ich dann die Regel erstellt, wo der Alias cp_allowed zum Einsatz kommt.

TCP/UDP CaptivePortal net * * cp_allowed * 
  GRE CaptivePortal net * * * *

GRE wird nur benötigt wenn man VPN-Verbindungen zulassen will.

Im Großen und Ganzen sieht das vollständig so aus:

    Proto Source Port  Destination  Port  Gateway >  TCP/UDP CaptivePortal net * * cp_allowed *  >  GRE CaptivePortal net * * * *  X  TCP/UDP CaptivePortal net * 172.21.0.1 cp_blocked * >  TCP/UDP CaptivePortal net * 172.21.0.1 * * X  * CaptivePortal net * * * *

Gruß
Ch3p4cK

Wenn du weiterhin 1:1 NAT benutzen willst, kannst du auch einfach über das 1:1 NAT noch ein normales forwarding machen.
1:1 > normal
Damit erreichst du, dass eine redirect Regel für den entsprechenden Port eingerichtet wird, aber trotzdem noch das alte 1:1 verhalten vorhanden ist.

Hi Databeestje, Hallo Heiko
sorry for the delay. I was in Holiday without my notebook and internet ;-)

You asked my if I using "mobile ipsec". No I don't.
I 'm not sure that I understand your following sentences.

Configuration: Both sides have fixed IP-adresses. But the identifier of the other side
is NOT the extern IP. This is not changeable because this is a bigger company
with thousands of tunnels….

So I have to enter the IP adress for peers_identifier or haven't I understand
this correctly?

greetings, Tim

Da hat mal jemand loadtests mit dem ALIX gemacht.
Mit der forum-suche solltest du das finden.
Kann mich gerade nicht mehr genau erinnern aber ich glaube das maximum lag so um 80Mbit/s.

PPPoe und statische IP am WAN ist nicht so möglich nach meinen letzten Kenntnisstand, ist auch nicht nötig, entweder Zwangstrennung auf DSL mit wechselnden IP am WAN oder aber der Provider macht feste IP´s mit PPPOE, dann wird immer dieselbe IP zugewiesen, insofern ist die dann am WAN statisch, so kann man dann auch VPN mit statischen IP´s machen.
Funktioniert super.

Welche sonstigen Anforderungen am PPOe sollten das denn sonst sein?

Gruß
Heiko

Sorry, hatte Deinen letzten Satz nicht Zuende gelesen. Macht Sinn so. Aber das Wichtigste: es funktioniert wie es soll. :-)

Funktioniert leider immer noch nicht.

Da werde ich wohl den pfSense neu installieren müssen.

Gruß

Marcel

Schade, dass mir keiner helfen kann.

Gruß

Marcel

Um angehängte files anschauen zu können muss man im forum angemeldet sein :)
Hat mich auch schon verwirrte, dass ich plötzlich meine eigenen attachments nicht mehr gesehen habe….

Sonst der direkte link zu dem angehängten bild:
http://forum.pfsense.org/index.php?action=dlattach;topic=13347.0;attach=4140

Oh. Ich hab übersehen dass du ein WRAP hast und kein ALIX.
In diesem Fall kannst du squid gleich im vorherein vergessen.
128MB RAM sind gerade mal genügend um die pfSense in der Grundversion laufen zu lassen.
Squid speziell braucht extrem viel RAM.
Für ganz kleine Netzwerke (kleiner Heimgebrauch) würde "vielleicht" ein ALIX reichen, aber sobald das ganze in einem richtigen Netzwerk eingesetzt wird brauchst du mindestens 512~1024 MB RAM.

Hallo,

das Problme hat sich behoben. Habe die Firewall neugestartet und voila es geht. Mann, dass manchmal ein reboot gut tut erspart viel arbeit. Trotzdem danke an alle für eure Hilfe!!!!!

Habe das Problem jetzt gelöst:

Ich habe Manuell unter /etc/dnscache/root/ip/

"Leere" Dateien für die einzelnen Netze erstellt,
sprich zusätzlich zu 192.168.8 auchnoch 192.168.11
und 192.168.3 erstellt.

Nach einem Neustart funktionierte dann alles einwandfrei.

Mfg,
Stefan

huhu mal wieder,

Ich glaube ich habe die Ursache gefunden: http://forum.pfsense.org/index.php/topic,16943.0.html letztes und vorletztes post… leider gibt es auch dort keine lösung...

So, bei mir funktioniert es nun. Bis jetzt jedesmal, und das seit etwa 12 Stunden :-) ist ja noch nicht lange, aber ich bin optimistisch.

Konfiguration:

WLAN Port gebrückt mit LAN Port
LAN Port gebrückt mit WLAN Port (also beide!)

Firewall Roules:

Von WLAN nach "aussen": alles offen (bei mir spielt das keine Rolle, da ich alleine mit meinen geräten drauf bin.

jetzt funktionierts. Auch der Zugriff auf das VPN das mit der LAN Schnittstelle verbunden ist. Ich verwende den letzten Snapshot der auf dem Server noch verfügbar ist.

Sigma

Jep scheint falsch zu sein.
Werde das fixen wenn ich zuhause bin.

so, nach etlichen stunden herrumprobieren und telefonaten mit dem HP Service hat sich herrausgestellt das die PFSense
im Bridge Modus Spanning Tree informationen versendet, diese wurden vom Switch hinter dem Uplink aufgenommen und
führten dazu das dieser die PFSense als neue kürzeste route ausgewählt hat. Will sagen die PFSense kriegt alles was sie
raussendet wieder zurück…
Weis jemand wie ich das unterdrücken kann das die PFSense Spanning tree versendet ?