Ist die Festplatte wirklich auf IDE eingestellt, vll irgendwo noch AHCI an oder so hatte das gleiche Problem.

Ich schiesse auch mal aus der Hüfte  ;)

Stell den Proxy ins LAN, gib ihm eine feste IP aus dem LAN und stelle sicher, dass er ins Internet kommt (GW, DNS, etc). In der pfSense machst Du dann eine Rule Block alles in Richtung Internet, ausser der Proxy IP. Jetzt darf nur noch der Proxy ins Internet.
Konkret im "LAN"-Tab bei den Rules einfach die "Default allow LAN to any rule" ändern und bei Source einfach nur die Proxy IP anstatt des LAN-Net reintun.

Wenn der Proxy im Internet steht, dann auch die "Default LAN to any rule" ändern, allerdings jetzt die Destination. Dort jetzt anstatt "any" die Proxy IP eintragen, jetzt kommen die internen Clients nur noch auf den Proxy.

Der Proxy muss in beiden Fällen an jedem Client konfiguriert werden.

Mein Netz ist an der Stelle recht flach, da die PS hier auch per LAN angebunden sind und somit direkt hinter der pfSense hängen. Bei mir läuft auch überhaupt kein upnp Daemon. Im Gegenteil, das ganze läuft auch noch hinter doppelter NAT (Kabel-Router macht eine, pfSense macht die zweite). Insofern verstehe ich da nicht, was PSN für ein Problem hat.

@Franz: WLAN ist glaube ich an der Stelle das geringste Übel, denn jeder Einsteiger WLAN AP kennt inzwischen das Häkchen, ob WLAN Geräte miteinander reden dürfen oder nicht. Etwas teurere APs können da sogar VLAN und Multi-SSID. Aber ich bin nach wie vor kein Freund - da stimme ich dir zu - von dieser GIGA VLAN Lösung, nur um jeden einzelnen Anschluß in ein VLAN zu quetschen. Zum Einen ist Wachstum somit ein Gräuel, Problemsuche und -lösung übel und der Overhead an Routing massiv. Je nachdem was vornedran für eine pfSense steht, muss diese JEDES VLAN routen. Damit holt man sich lustige andere Probleme mit ans Bein. (Intra-VLAN Traffic bspw. könne die Backplane oder CPU so stark auslasten, dass kaum mehr anderer Traffic ins Internet funktioniert)

Das halte ich persönlich für "ein bisschen Internet" einfach für etwas übertrieben. Zumal der Zugriff aufs Web dann ja noch - so ich es richtig verstanden habe - über das CP abgeprüft wird. Wenn ihr das als "Business Internet" anbietet, kann ich den Aufriß an Security etc. ja noch nachvollziehen (dann würde ichs aber anders aufbauen via Port Security u.ä.). Aber für etwas off time internet access wäre mir der Management Aufwand zu hoch.

Grüßend

@shiversc: Cache in welcher Hinsicht? Varnish o.ä. agieren meist aus einer Ramdisk, die würden also eher von mehr RAM profitieren als von einer SSD?

Grüße

Ja, die Switch-Infra kann das (Cisco Switche mit IOS) … die sind auch mit Sicherheit richtig eingestellt (ist ein grosses Netz).

Unter transparent verstehe ich, dass ich vor und hinter der Firewall die selben IP-Adressen habe.

Gruss craCH

Hallo,
habe geschafft IPsec Verbindung mit dem Shrew Soft VPN Client aufzubauen und die Pakete werden damit auch durch die Firewall geroutet. Mit dem Cisco Client funktioniert das Routing leider nicht. Sollte jemand einen Trick für den Cisco Client kennen, bitte her damit!
@Snemelc:
Wenn die Verbindung steht, dann könnte evtl. die Firewall Regel fehlen. Ist die Firewall-Regel unter "Firewall: Rules: IPsec" hinzugefügt? So ungefähr:
Proto Source Port Destination Port Gateway Queue Schedule Description
IPv4 * * * * * * none   Permit IPSEC traffic.
Wenn ja, dann würde ich testweise die Pakete loggen (Log packets that are handled by this rule), dann sieht man ob die Pakete durchkommen.
Evtl auch NAT Regel unter "Firewall: NAT: Outbound" kontrolieren. Sollte auf Manual Outbound NAT rule generation umgestellt werden und für den IP-Bereich der unter VPN: IPsec: Mobile zugewiesen wurde eine NAT Regel hinzufügen wie z.B.:
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description
WAN  10.110.10.0/24 * * * WAN address * NO NAT fuer IPsec
Natürlich sollte auch dann für LAN Bereich eine ähnliche  NAT Regel geben.

Wegen deines Probleme würde ich mal einen Bugreport machen.

Bezüglich des Thin Clients, weißt du aber, dass es für den optionalen Slot auch NICs, ich glaube sogar Dual-NICs gibt?

OK, das mit dem Server muß ich mir nochmal näher ansehen. Beim Test mit dem DHCP bin ich aber auch einen anderes Problem gestoßen.

Mein Netzwerk ist jetzt folgendermaßen aufgebaut:

WAN->pdSense -> Switch -> Clients / Drucker 10.1.0.x /255.255.0.0
                                          -> WLAN-Router -> Clients  10.1.5.x/255.255.0.0

Die Clients aus dem WLAN können nicht auf den Drucker und die Laufwerke der direckt am Switch hängenden Clints zugreifen. Der Router ist ein Buffalo WZR-HP.
Hat da jemand eine Idee wie ich das bewerkstelligen kann?

Klingt mit der Anzahl der VLANs etwas nach Overkill. GästeWLAN seperiert ist ja durchaus OK, das "normale" WLAN soll ja aber eher wie LAN behandelt werde (vermute ich), insofern würde ich das ggf. ins LAN bridgen oder zumindest gleich behandeln. VLAN 1 würde ich nicht vergeben, das default-VLAN macht manchmal wenn es in Nutzung ist Probleme bzw. ist Fallback. Zudem sollte das Modem nicht in ein VLAN, da das Modem überhaupt nichts von dem IP Layer weiß. Modem einfach direkt an die pfSense anschließen und gut. Nix VLAN.

Warum dann noch irgendwelche Streaming Clients extra nehmen? Hört sich eher an, als wären die wie der SmartTV zu behandeln. Nicht nur VLANs nutzen, weil man es kann, nur nutzen, wenn es Sinn macht.

ja das klingt so, als könnte er VLAN Tagging auf den SSIDs. Dann wäre es denkbar, wenn der AP am Switch mit den PCs etc. hängt, das interne WLAN auf das gleiche VLAN wie die PCs zu taggen, damit bspw. ein Laptop mit den PCs kommunizieren kann, Gäste aber in ein extra VLAN zu legen.

Sicherheitslücken… vielleicht. Deshalb mag ich persönlich keine SmartTVs, sondern mach das lieber über eine extra kleine Box. Wenn du Interesse hast, gern per PN, da das ein ganz anderes Thema ist, aber da gibts auch Lösungen wie der Raspberry, der sich dann bspw. via HDMI-CEC direkt wie ein SmartTV mit der Fernbedienung des Fernsehers steuern lässt.
Eine Isolation ist aber m.E. eher weniger notwendig. Wichtig ist nur, dass niemand von außen auf das Gerät kommt. Dann hält sich auch der Gefahrenaspekt mit Schadsoftware in Grenzen. Denn wenn ein SmartTV "gehackt" wird ist das den anderen Geräten eher egal. Schlimmer ist da eher, wenn das Ding bspw. noch ne Kamera für Skype hat, dass dich jemand bespitzeln kann.

Nein. Es ist alles verboten was nicht explizit erlaubt wird. Lediglich auf dem LAN ist immer eine Default Regel "abgehend ins Internet alles erlauben aus dem LAN", aber ansonsten ist jedes Interface per default erstmal dicht und muss Stück für Stück aufgemacht werden. Default ist auch eine NAT von LAN auf WAN. Wenn man bspw. aus GästeVLAN ins Internet will, muss dafür dann auch ein NAT Eintrag rein dito NAS, TV, etc. Und natürlich entsprechende Regeln.

PfBlocker ja. Snort halte ich eigentlich für zu Hause für ein wenig Overkill, aber jedem das Seine :)

Grüße

@GruensFroeschli:

Sind diese zwei Verbindungen auf den gleichen Server?
Wenn ja: Es ist nicht möglich mehr als eine PPTP Verbindung auf einen Server von der gleichen öffentlichen IP zu haben.

Für Erklärung wieso:
https://doc.pfsense.org/index.php/PPTP_Troubleshooting
http://forum.pfsense.org/index.php?topic=41556.0

Hallo, danke für die Links, die haben alle Fragen beantwortet.

LG. Manfred

Gerne etwas kleiner :P WLAN-Clients werden auch in Zukunft maximal 10-15 Stück sein. Reichweite aktuell vernachlässigbar.
Outdoor ist gut, wird aber nicht benötigt. Wenn alles so läuft wie geplant und auch die Räumlichkeiten vorbereitet sind, wird der Fokus auf dem LAN-Betrieb liegen (dann auch mit ordentlichem Switch ;) ); WLAN bleibt weiterhin für mobile Geräte bestehen.

Hallo Martin,

also irgendwie erschließt sich mir der Use Case noch nicht wirklich, denn bei 1:1 NAT legst du die IP nicht innen auf, sondern außen. Deshalb könntest du vielleicht (mit Skizze?) etwas erläutern, was du erreichen willst. Was ich vermute:

WAN IF mit .35 und Default GW auf .33 DMZ IF mit irgendeiner Adresse Clients auf DMZ, die echte IPs bekommen sollen (.36-.62 vermutlich?) 3. Interface für …?

Ich spreche da jetzt von DMZ, weil das was du beschreibst eigentlich eher DMZ als LAN Job ist.
Wenn ich das richtig interpretiert habe, wäre meine Herangehensweise gewesen:

WAN IP auf .34 statt auf .35 setzen (weil GW+1 einfacher zu merken ist) alle nötigen IPs bzw. das restliche Netz auf dem WAN als Alias-IP anlegen Clients auf DMZ Interface bekommen interne Dummy-IP (10.x, 172.16.x oder 192.168.x was am wenigstens Terror macht), DMZ Interface bekommt .1 Clients bekommen feste Zuordnung (kann durch MAC Zuweisung geschehen) 1:1 NAT konfigurieren auf WAN von externer IP .xy auf interne IP .yz

Fertig. Ggf. noch ausgehende Verbindungen von .yz wieder auf .xy mappen.

DHCP an der Stelle führt nur zu vielen Tränen.

Grüße
Jens

Das GW der VM ist natürlich 192.168.4.1. Habe mich vertippt.

Leider konnte ich bisher nicht weiter testen.

Ich werde es am We erneut versuchen. Diesemal werde ich PfSense direkt ans Modem anschließen. Dann ist zwar mein Telefon, welches über die Fritzbox läuft, tot, aber dann ist das halt kurz so

Habe die pfSense neu installiert. Jetzt läuft alles wie es soll.
Offensichtlich war schon einiges vermurkst …