Das sollte helfen: https://doc.pfsense.org/index.php/Wildcard_Records_in_DNS_Forwarder/Resolver

Leider bin ich mit der pfSense nicht zum Erfolg gekommen. Ich habe keinen Weg gefunden den "Ausgang" des Remoten WLAN-Controllers zu einem LAN-Port der Internet-pfSense zu tunneln. Meine Lösung ist daher an den remoten Standorten ebenfalls pfSenses einzusetzen und diese dann vom WAN-Interface aus per OpenVPN-Tunnel zum LAN-Interface der Internet-pfSense zu führen. Anders weiss ich mir nicht zu helfen… finde die Lösung aber richtig doof, da ich die Captive-Portal User dann über viele pfSenses verstreut habe...

…danke. Hab's gestern schon gesehen, gleich probiert und es rennt wieder wie es soll. -Wanninger

Teuer ist relativ. Wie schon so oft zitiert: you get what you pay for. Zudem steht bei der Delock Karte nun mal gar nichts dabei, was für ein NIC und Chipsatz verwendet wird. Da die meiste Welt lediglich Windows im Hirn hat, bringt dir das erstmal für pfSense/FreeBSD gar nichts. Durch ein wenig suchen findet man dann eine unspezifizierte Angabe von "Realtek" als NIC. Heißt, das kann laufen, muss aber nicht, je nachdem welcher Realtek Chip hier verbaut wurde und ob der im Treibervorrat von FreeBSD 10 enthalten ist. Solche Puzzlespiele sind mir ein wenig zu dumm, wenns um das Wichtigste in einem Router geht - Netzwerkdurchsatz und -verfügbarkeit. Und da haben Intel Chipsätze bei Netzwerkkarten eben am wenigsten Probleme, weshalb die auch immer vorgezogen werden.

Klassischerweise konfigurieren die Unis ein Profil für den Cisco VPN Client in welchem normalerweise auch Dinge wie Verbindungsdauer etc. festgehalten werden. Diese Konfiguration ist nicht für einen VPN Tunnel gedacht. Zudem möchte eine Uni selten, dass du mit deinen persönlichen VPN Zugangsdaten einen Tunnel für multiple Clients dahinter aufmachst. Davon abgesehen, kann es sein, dass hier nicht nur reines IPSEC zum Einsatz kommt, sondern etwaige Einstellungen aus dem Client benötigt werden, was ich dir aber nicht sagen kann, da ich weder Uni noch Konfiguration kenne. Wenn du dazu keinen Streß mit deinem Uni RZ haben möchtest, würde ich davon abraten, dich mit deinen VPN Client Zugangsdaten (für deinen Einzelclient) als Tunnel/Routed VPN verbinden zu wollen. Die meisten IT'ler der RZs reagieren auf sowas nicht wirklich gut. Zudem kann es sein dass so oder so ein Disconnect erzwungen wird nach Zeit x.

Moin, nur mal so, das spukt das Zyxel VMG1312-B30A so über die DSL Leitung aus: ============================================================================     VDSL Training Status:  Showtime                     Mode:  VDSL2 Annex B             VDSL Profile:  Profile 17a             Traffic Type:  PTM Mode             Link Uptime:  19 days: 10 hours: 13 minutes ============================================================================       VDSL Port Details      Upstream        Downstream               Line Rate:      4.068 Mbps      29.031 Mbps     Actual Net Data Rate:      4.044 Mbps      28.982 Mbps           Trellis Coding:        ON                ON               SNR Margin:        8.5 dB            8.3 dB             Actual Delay:          8 ms              8 ms           Transmit Power:        2.4 dBm          13.2 dBm           Receive Power:      -6.8 dBm          -8.9 dBm               Actual INP:        1.0 symbols      1.0 symbols       Total Attenuation:        8.6 dB          22.1 dB Attainable Net Data Rate:      4.212 Mbps      30.130 Mbps ============================================================================       VDSL Band Status    U0      U1      U2      U3      D1      D2      D3   Line Attenuation(dB):  6.5    37.2    53.2    N/A    20.8    50.4    76.4  Signal Attenuation(dB):  6.5    37.0    N/A    N/A    20.8    50.0    N/A          SNR Margin(dB):  9.0    8.4    9.0    N/A    8.3    8.3    N/A    Transmit Power(dBm):- 0.4  - 2.4  - 3.4    N/A    11.8    7.4    N/A  ============================================================================             VDSL Counters           Downstream        Upstream Since Link time = 13 min 35 sec FEC: 9586358 6688150 CRC: 169 0 ES: 84 106 SES: 0 0 UAS: 0 4104 LOS: 0 124 LOF: 0 124 LOM: 0 0 Latest 15 minutes time = 12 min 2 sec FEC: 81 0 CRC: 0 0 ES: 0 0 SES: 0 0 UAS: 0 0 LOS: 0 0 LOF: 0 0 LOM: 0 0 Previous 15 minutes time = 15 min 0 sec FEC: 72 0 CRC: 0 0 ES: 0 0 SES: 0 0 UAS: 0 0 LOS: 0 0 LOF: 0 0 LOM: 0 0 Latest 1 day time = 4 hours 27 min 2 sec FEC: 6269 0 CRC: 0 0 ES: 0 0 SES: 0 0 UAS: 0 0 LOS: 0 0 LOF: 0 0 LOM: 0 0 Previous 1 day time = 24 hours 0 sec FEC: 16951 261218 CRC: 5 0 ES: 2 0 SES: 0 0 UAS: 0 0 LOS: 0 0 LOF: 0 0 LOM: 0 0 Total time = 1 days 4 hours 27 min 2 sec FEC: 23737504 11109799 CRC: 101581 1 ES: 1846 1160 SES: 627 0 UAS: 249 43409 LOS: 10 1104 LOF: 74 1104 LOM: 0 0 ============================================================================

Hallo! Die empfohlene Methode ist die, Konfiguration in eine XML Datei zu sichern (Diagnostics: Backup/restore). Dann die Platten tauschen und pfSense darauf neu zu installieren und die Konfig wiederherzustellen. Die XML kann man auch gleich bei der Installation einbinden (z.B. v. USB-Stick), hab ich aber noch nicht gemacht. Zuvor installierte Pakete werden nach der Konfig-Wiederherstellung automatisch wieder installiert, wenn du die Sicherung mit den Defaultwerten vornimmst. Ich habe auch mal mit Clonezille ein Image der Platte gezogen und dieses, allerdings auf gleichartiger Platte, wiederhergestellt. Gruß

Guten abend jetzt habe ich nochmal alles durchgespielt und auf der Konsole mitverfolgt: Zuerst deinstall: GUI Removing package… Starting package deletion for zip-3.0_1-i386...done. Starting package deletion for p7zip-9.20.1_2-i386...done. Removing OpenVPN Client Export Utility components... Tabs items... done. Loading package instructions... Include file openvpn-client-export.inc could not be found for inclusion. Deinstall commands... Not executing custom deinstall hook because an include is missing. Removing package instructions...done. Auxiliary files... done. Package XML... done. Configuration... done. done. Package deleted. Die 2 pbi's in /root/tmp gibts aber noch! pbi_info zeigt das zip-Package nicht mehr an Install GUI: Beginning package installation for OpenVPN Client Export Utility . Downloading package configuration file... done. Saving updated package information... done. Downloading OpenVPN Client Export Utility and its dependencies... Checking for package installation... Downloading https://files.pfsense.org/packages/10/All/zip-3.0_1-i386.pbi ...  (extracting) Mehr wird nicht angezeigt .... pbi_info meldet das zip als installiert der Exporter wird als installiert ausgegeben Unter VPN -> OpenVPN nix zu sehen Griitz Renato

"don't pull routes" war das Rätsels Lösung :) Daaanke!

ich sehe nur das zip … Die pbis werden in /root/tmp hinterlegt: [2.2.6-RELEASE][root@vpn.cpcm.ch]/root/tmp: ls -l total 1508 -rw-r–r--  1 root  wheel        0 Jan 10 18:14 apkg_p7zip-9.20.1_2-i386.pbi -rw-r--r--  1 root  wheel  1539837 Jan 10 18:55 apkg_zip-3.0_1-i386.pbi Offenbar ist aber das "apkg_p7zip-9.20.1_2-i386.pbi" futsch. Wo krieg ich das per wget oder so? Danke & Cheers Renato

Während des Betriebs kann ich es dir nicht sagen, aber z.B. beim Reboot springts. Gruss FloSense

Sorry, ich habe die Bilder mal nur verlinkt, ich konnte kaum mehr das Forum erkennen vor lauter Bild ;) Bilder bitte entweder kleiner anhängen an den Beitrag (dann werden die automatisch klein) oder einfach nur verlinken wenns nicht kleiner geht. Danke! Zudem steht das 2.3 Beta(!) Forum jedem offen, wo auch über die neue UI berichtet wird. Screenshots wurde zudem schon im August im Blog gepostet ;) https://blog.pfsense.org/?p=1837 Es freut mich allerdings, dass dir die UI ebenso wie mir gefällt :) Erwähnenswert ist vielleicht, dass wir nun seit ein paar Tagen die Alpha bereits verlassen haben und in die Beta eingetreten sind. Dabei ist u.a. nun auch lighty (lighttpd) durch nginx ersetzt worden, was den Prozess etwas verzögert hatte. Grüße

Und mit wie RAM komm ich klar? Also: -OpenVPN Client -Snort -HAVP -Squid + Squidguard (+ caching) -LCDProc -pfBlockerng und noch 1-2 weitere

@flo Trotzdem Danke für den Versuch….. Mir ist da noch ein anderer Ansatz untergekommen: Was wäre denn, die pfsense zu einem wirklichen mcast ROUTER aufzubohren? Hat jemand Erfahrungen mit mrouted? Schliesslich basiert der code vom igmpproxy in Teilen darauf gehört das zum Standard Umfang von freebsd (ist aber bei pfsense nicht dabei) Hat jemand Erfahrung damit? Br br

@steve_darcy: Was meinst du mit ich solle alles über ovpn laufen lassen? Das wäre nur für den Test gemeint. Wenn alles über die VPN läuft, weiß der Zielserver nichts von deiner tatsächlichen IP. @steve_darcy: Weil das Problem hatte ich auch schon bei anderen Seiten also nicht nur bei Ip-check info. Ist es denn ein Problem? @steve_darcy: Wenn du sagst das bestimmte Teile der Seite über den Tunnel laufen wäre die einzige Möglichkeit immer den Tunnel zu schließen wenn ich meine Originale IP brauche? Nein, du brauchst nur alles, was die Zielseite aufruft und in deinen Browser lädt, über den gleichen Weg zu schicken, also über die VPN oder eben nicht. Verwende Analysewerkzeuge um herauszufinden, was aufgerufen wird. Im Firefox kannst du dir bspw. über rechte Maustaste > Seiteninformationen > Medien die URLs von Grafiken und sonstigen Medien anzeigen lassen. Oder du suchst den Seiten- oder Framequelltext nach weiteren http(s)-Aufrufen durch. Auf ip-check.info sehe ich da bspw. noch shop.anonymous-proxy-servers.net. Diese URLs über den gleichen Kanal aufzurufen reicht vermutlich um das "Problem" zu beheben. Mit DNS hat das übrigen gar nichts zu tun. Der Zielhost hat keine Ahnung, welches DNS du verwendest und steht mit diesem nicht in Verbindung. Und der Browser schickt da auch nichts mit. Er führt lediglich die Befehle der Zielseite aus, die Aufrufe der diversen Objekte eben auch von verschiedenen Hosts.

Wenn die Verbindung aufgebaut wird ist das ja schon mal soweit i.O. Aber du musst eben noch einstellen dass sie auch genutzt wird. Dazu erstellt du zunächst ein VPN Interface (Interfaces - assign - ovpnc(x)), bennenst es entsprechend und aktivierst es. Jetzt solltest du auch ein neues Gateway für die Verbindung haben (unter System - Routing). Als nächstes stellst du in den gewünschten Firewallregeln dieses Gateway ein. Also z.B. deine LAN allow any Regel bearbeiten und dort unter Gateway das VPN-Gateway angeben. (Achtung: wenn du auch intern über mehrere Interfaces routest brauchst du jetzt davor eine Regel für die entsprechenden Netze) Als letztes noch NAT kontrollieren: unter Outbound für dein VPN interface NAT für Source: "dein LAN" aktivieren. Nun sollte dein Traffic über den VPN laufen.

@Bluekobold: Mag schon stimmen, ich bin allerdings im Heimumfeld pragmatisch. Man kann da viel spielen wollen, schlußendlich wirds meist doch weniger ;) Aber jedem wie er möchte, da habe ich keine Anteile dran. Aber diese immer wieder empfholenen Jetway Celeron Kisten haben eben trotz allem (mehr GHz, mehr Kerne) kein AES oder Quickassist. Und mit einem Atom C2358 oder 2558 ist man in einem recht ähnlichen Preissegment und hat dabei nicht nur annähernd gleiche Taktung und Kernzahl (wenns da unbedingt drauf ankommt), sondern auch noch ordentliche CPU Entlastung sobalds um Verschlüsselung geht. Und wenn ein full scale IDS wirklich von Interesse ist, dann sollte derjenige auch VPN/IPSEC nicht außer Acht lassen und dafür sind IMHO diese Celerons nur bedingt geeignet. Just my 2c