Ja stimmt schon. Hab wohl ein wenig … blöd reagiert. Tut mir leid. Hab halt gehofft jemand schreibt: Du die Fehlermeldung kommt bei mir nicht, oder bei mir klappt's auf alle Fälle, dann hätte ich nicht so im trüben gefischt! Aber das Ergebnis zählt und es funktioniert  :D

Moin,

@jahonix:

Wozu braucht man denn "starke Quadro-GPU für sieben 4K-Displays" in einem Router?

Kannst sie ja weg lassen, ansonsten: Augmented reality, Deep Packet Inspection per Operator, der kann dann hinterher sagen ich habs kommen gesehen …  :P

-teddy

@Grimson:

@Freaky21:

Folgende Problematik: Es geht um ein WLAN Netz welches 2,4 und 5GHz anbietet. Je nachdem was empfangstechnisch guenstiger ist, verbindet sich der Client entweder mit 2.4Ghz oder 5Ghz. 2 Netze heißt aber auch 2 Mac-Adressen beim Client.

Hat der Klient 2 WLAN Karten/Adapter, oder warum hat der unterschiedliche MACs bei den zwei Bändern? Alle mir bekannten Endgeräte benutzen die gleiche MAC unabhängig vom verwendeten Frequenzband.

Danke für den Hinweis. Scheint auch tatsächlich nur bei einem Gerät so zu sein. OK, dann ist das damit erledigt!

Klaus

"Problem" gelöst…

Seitdem jemand unseren WAN Router resettet hat, hatte dieser 192.168.0.0/24 als LAN Netz - genau das gleiche, wie ich es in pfsense nutze.
Das kann natürlich nicht gehen. Nun hat der WAN Router wieder 2.1 - und es geht ;)

Danke!!

Hallo,

die pfSense scheint nicht das Standard-Gateway in ihrem Netzwerk zu sein.

Der VPN-Endpunkt sollte das Standard-Gateway sein, ansonsten wird es etwas komplizierter.

Grüße

Tja, wie es aussieht, passen die möglichen Authentisierungsvarianten einfach nicht zusammen.
Auf dem Linux-Client habe ich im nm-applet nur entweder EAP oder Zertifikate als Möglichkeiten - nicht die Kombination. EAP-TLS gibt es da einfach nicht.
Auf Android kann ich auf EAP-TLS umstellen, aber dann werden nur Zertifikate genommen, auch kein Passwort.

Ich habe nirgendwo die Möglichkeit gefunden, die ich auf dem Linux-Server hatte:

rightauth = pubkey
  rightauth2 = eap-md5

Und auch die Möglichkeit der Client-Identifkation per ASN.1 DNB gitb es bei den pfSensen scheinbar nicht, d.h.

rightid = "C=DE, O=<o>, OU=<ou>, CN=<fqdn client="">"
  leftid = "C=DE, O=<o>, OU=<ou>, CN=<fqdn server="">"

klappt nur für den Server, nicht für den Client.</fqdn></ou></o></fqdn></ou></o>

Sehr praktisch :) Dann hoffe ich jetzt klappt dann alles :D

Alles klar.
Danke für deine Antowrten!

Hallo an alle,

vielen Dank für eure Infos und euren Input.
Ich werde nun mal die 1020 anfragen und im Laufe des Jahres auch mal die "alte" Firewall in der Zentrale angehen.

Gruß Sebastian

Ich habe es am WE mal umgestellt und die Vigor übernehmen jetzt den Verbindungsaufbau nebst DynDNS, mit den Ports zur pfSense in der DMZ. Läuft soweit alles ok und auch das Load Balancing funktioniert mit WAN1&2 als Gateway-Group  ;)

Es scheint, dass ich bei der statischen Konfig irgendwo nen Fehler drinn hatte.
Das Gateway war immer wieder mal offline.
Das muss ich mir nochmal in Ruhe ansehen.
Kann natürlich sein, dass das auch mit Snort zusammen hing.
Mal sehen.

Natürlich braucht der LAN einen Gateway. Der LAN GW ist die IP Adresse des Routers in dem lokalem Netzwerksegment (in meinem Falle des pfSense).  Dann braucht der WAN noch einen Gateway vom ISP, damit das Traffic von dem lokalen Netzwerk nach außen geroutet werden kann.

Dazu sage ich nur, dass du mal dringend dein Netzwerk/Routing Wissen überprüfen oder ausbauen solltest. Welchen Sinn macht es denn bitte AUF dem Gateway sich selbst nochmals als Gateway zu setzen!? Es hat schon einen Grund, wenn unter der Gateway Einstellung auf dem Interface steht:

"If this interface is an Internet connection, select an existing Gateway from the list or add a new one using the "Add" button. On local area network interfaces the upstream gateway should be "none". Gateways can be managed by clicking here."

Frei übersetzt: Beim LAN sollte hier "NONE" stehen. Nur bei einem Upstream/WAN Interface muss hier natürlich das Upstream Gateway eingetragen werden.

Aha? Und wie soll das Traffic aus dem lokalen Netz an die WAN Schnittstelle geroutet werden, wenn kein standardmäßiges Ausgangspunkt festgelegt wurde?

Ganz einfach: jedes LOKAL angegebene Netz des Geräts steht natürlich in seiner Routing Tabelle. Da muss ich selbst nichts mehr für tun, um das zu ergänzen. Und mehr als ein Upstream/Default Gateway braucht es in diesem Szenario nicht! :)

Edit: Ah, Grimson überlesen. Sorry.

@JeGr:

Source: any (denn das Paket kommt egal was vornedran läuft AUS dem Internet, nicht vom WAN oder sonstwo her)

Stimmt, ich sollte nach einer Kombi aus Spät- und Nachtdienst nicht mehr posten. :D

@Parsec wenns nur um das WebUI Cert der Sense geht, das kann das ACME Package ohne zusätzlichen Proxy. Der Service hört selbst auf den Port. Wobei ich auch hier es angenehmer finde, den Port auf 81 umzulenken damit er nicht "daueroffen" ist.

Hallo,

das Tut für Voip via T… habe ich gelesen...

Habe die FB jetzt als Client und fürs Gast-WLAN zusätzlich an die pfsense gehangen.

Leider kann die FB 6490 das nur separat.
Jetzt kann ich auch die eingehende Telefonie empfangen.

Dankeschön für die Hilfe.

Moin,

Hier ist ein Beschreibung, zwar keine offizielle Quelle aber mach einen vernünftigen Eindruck  https://www.cpug.org/forums/showthread.php/18672-Check-Point-1100-Appliance-FAQ Demnach ist die CPU eine ARM926EJ-S rev 1

A: The sizing recommendation is based on number of users.
A: 1120 Appliance -> Up to 10 Users, 28 SPU (SecurePower Units)
A: 1140 Appliance -> Up to 25 Users, 34 SPU (SecurePower Units)
A: 1180 Appliance -> Up to 50 Users, 37 SPU (SecurePower Units)

;D SPU, was ein Schmarrn

-teddy

Kann mir mal einer sagen wie sich diese Konfigurationsart nennt damit ich mir entsprechende Guides anschauen kann? Gibt es da schon was ich mir anschauen kann?

Wie Virago sagt, OpenVPN Site2Site machen und die Seite B hinter der FB spielt Client. Für den Zweck dass du Site2Site dann auch noch routen willst, wäre es auch sinnvoller OVPN via Preshared Key zu machen, ansonsten hat auch da Virago recht, dass man sonst gern SSL-based spricht. In dem Fall aber würde ich PSK vorziehen. Auf der Client Seite müsste es sogar ein Setting geben, um das Default GW auf den Tunnel zu legen, dann muss das remote Netz nicht mit 0.0.0.0 angegeben werden, da bin ich aber gerade da unterwegs gerade unschlüssig.

Gruß

Das würde sich aber dann beim WLAN beißen. (Unterscheidung "Intern" und Gast-WLAN)

Warum? Beides sind für mich unterschiedliche VLANs demzufolge dann auch unterschiedliche IP Ranges. Damit ist es auch möglich, WiFi-LAN im Wunschfall ggf. zu Bridgen oder ordentlich zu routen und auf den WiFi-Guest Interface dann bspw. ein Portal o.ä. aufzuziehen wenn gewünscht.

Die VLAN IDs und IP Ranges waren jetzt nur Demo, aber ich würde das eben über das dritte IP Segment codieren und dann einheitlich machen, dann hat man es im Debugging Fall auch leichter.

Ich hatte nicht vor, die Konfig zu übernehmen, sondern parallel neue Hardware beschaffen und neue Konfig aufbauen, ohne Import der alten.

Guter Plan! Hört sich solide an. Jetzt nur noch runterbrechen in kleinere Häppchen wie Hardware beschaffen, Testaufbau, etc. und loslegen :)

@jenszahner:

Nur jetzt stellt sich die "doofe" Frage, wo muss ich das Ding "eintragen", so das es beim Neustart auch hochkommt und idealerweise auch Updates von PfSense überlebt.

Schau dir einfach mal die Packages genauer an, da ist was passendes dabei.