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

Hatte das so verstanden, dass be1001 mehrere (pfSense) APs darüber managen will. Microtik in pfSense einzubinden ist schon aufgrund der unterschiedlichen Plattformen (Linux und FreeBSD) weniger als unwahrscheinlich.

@musk Prinzipiell ist das keine blöde Idee, entsprechend komplexe Begriffe vllt. nochmal kurz auf deutsch zu erklären. Aber bitte nicht erwarten, dass das hier Übersetzungs-Ausmaße bekommt, denn dann bekommst du ein ganz anderes Problem: die meisten Netzwerker Begriffe sind nunmal englisch und werden somit immer gleich heißen. Was dann aber passiert, wenn jemand anfängt zu übersetzen oder sonst welchen Kram zu machen, sieht man dann in den WebGUIs diverser Hersteller, wenn Begriffe wie DMZ von demilitarisierter Zone über stillgelegter Bereich bis hin zu exponiertes Netz alles heißen können. :/

Hi Sven :) Ich meinte Hetzner fragen, ob Sie ein Subnetz aus dem /64 Netz auf die pfSense routen können, also z.b. /72. Das wäre kontraproduktiv (leider), da die meisten v6 Features ja auf einem /64er aufbauen, weshalb wir von der RIPE ja auch explizit gesagt bekamen (beim Hosting bspw.) dass dem Kunden mind. ein /60 angedacht werden sollte, damit er ggf. intern wieder sauber ein /64 nutzen kann, selbst wenn wir es ihm am Anfang nicht direkt zuweisen. Warum sich Hetzner nicht an diese Vergaberichtlinien oder "best practices" hält, ist mir leider immer noch schleierhaft, auch wenn ich erst vor 3 Wochen noch persönlich bei den Jungs vor Ort in Nürnberg war. Aber leider können die Kollegen aus dem Netzwerk Team dort auch nur das machen, was sie vorgegeben bekommen :/ Klar wäre es einen Versuch wert, allerdings wird das dann vom Setup her ziemlich bastelig, da sämtliche autodiscovery dann wegfällt. Und viel Erfolgswahrscheinlichkeit sehe ich leider auch nicht :/ Viele Grüße Jens

SOLVED: To solve the issue it is necessary to understand the SIP/RTP principles and how to config fritzbox by config files. For everyone having SIP problems: All ports being used are defined by the client - in my case the fitzbox which sits behind pfsense. It is no problem at all to use multiple SIP accounts / providers on the fritzbox, even behind pfsense. The main difference to most NATed apps like http or mail is that the connection details are included in the data layer which are not touched by pfsense. Since the IP numbers send to the SIP servers are internal ones not accessable from outside, the SIP server takes IP and port from the initial request (coming from pfsense). It is important to understand that pfsense is changing the ports on outgoing NAT by default. BUT: this port has no route back / SIP NAT is configured on port 5060! So it is very important to deactivate port translation on outgoing NAT by defining a new outgoing NAT roule: –> Firewall: NAT: Outbound check: "Hybrid Outbound NAT rule generation (Automatic Outbound NAT + rules below)" create roule: Interface: WAN Source: any Source Port: tcp/udp/5060 Destination: * Destination Port: tcp/udp/5060 NAT Address: WAN address NAT Port: * Static Port: YES second issue was: The O2 fritzbox had non default RTP ports defined (50000 instead of 7078) but when switching vom internal DSL modem to PPPoE the fritzbox used firewall rules based on default port 7078. So I switched RTP port back to default by backup / restore of the fritzbox config: rtpport_start = 7078 now everything works as expected