@groddjur42:

Super, klappt alles.

DANKESCHÖN !!

Klasse!  :)

Es wäre sehr schön wenn Du aus diesen Informationen einen offiziellen Bugreport machen könntest.

Vielleicht beeinträchtigen snort und squid den updateprozess. EIn Neustart könnte helfen. Wenn Paket fehlen, einfach nachinstallieren bzw. neuinstallieren.

Hallo FabiNeo,

wenn du Firewall Regeln definierst, bietet dir die pfsense die Möglichkeit einen Gateway auszuwählen. nachdem du also deine Firewall Regeln so erstellt hast, die Port-Ranges definiert hast, musst du nur noch den entsprechenden gateway angeben.

Ich finde deine Überlegung allerdings nicht so ganz sinnvoll. Was möchtest du damit bezwecken, dass du die Port 1.69 über WAN1 versendest und die Port 70-100 über WAN2 und so weiter ? Ich stelle mir normalen Internetverkehr vor - der meiste Traffic entsteht da vermutlich über http, https, evtl. ftp und bischen E-mail. Wenn jetzt Port 80 über WAN2 geht, weil die meiste zeit gesurft wird, dann liegen die anderen Internetanschlüsse brach. Das ist doch nicht wirklich sinnvoll, oder ?

Wenn es dir um Lastverteilung geht, dann bietet pfsense hierfür sogenannte "Gateway Groups". Du definierst eine beliebige gruppe und fügst dieser Gruppe gateways hinzu. Zum Beispiel Gruppe 1 mit deinen WAN1, WAN2, WAN3 und eine Gruppe 2 mit WAN4.
In den Firwall Regeln - wie oben bereits beschrieben - wählst du dann nicht mehr nur einen Gateway aus, sondern deine Gateway Gruppen. Der Verkehr wird dann entsprechend über alle gateways in einer Gruppe verteilt. Fällt ein gateways aus, weil dein ISP ein technisches problem hat, wird der Verkehr automatisch auf die übrigen Gateways verteilt.

Hast du einen Gateway/WAN-Anschluss, welcher keine Flatrate hat oder nur als Backup genutzt weden soll, kannst du das ebenfalls automatisieren. Die gateways, die du in eine Gruppe gepackt hast, kannst du priorisieren. Haben WAN1 und WAN2 die Priorität 1 und WANr die priorität 2, dann werden erst die Gateways genutzt, die Priorität 1 haben. Sollten alle diese Priorität 1 gateways ausgefallen sein, wird zur nächst höheren Prioritätsstufe gewechselt und dein WAN3 kommt in Spiel. Umgekehrt geht es natürlich ebenfalls automatisch.

Vielleicht solltest du das, was du realisieren willst, nochmal etwas genauer erklären, dann kann man gemeinsam vielleicht eine bessere Lösung finden.

Hinweise:

Wenn du squidguard installierst auf pfsense 2.0.x installierst, installiert er immer automatisch squid2 mit - nicht das pfsense paket aber die binaries.
Installierst du also erst squid3, dann squidguard, dann funktioniert squid nicht korrekt. die richtige reihenfolge für squid3 + squidguard ist:

squidguard installieren, dann squid3 installieren, dann konfigurieren.

SquidGuard und Änderungen:
Wenn du Änderungen vornimmst, müssen deine letzten beiden Schritte folgende sein:
1.) General Settings: Save klicken
2.) General Settings: Apply klicken
Erst dann sind die Settings aktiv.

Hmm, was würde denn passieren, wenn man den reset auf 2h stellt.
den hard timeout auf 10min
und 6 credits vergibt.

der user würde sich automatisch einloggen, nach 10min zwangsweise getrennt werden, aber erneut automatisch einloggen (wegen der restlichen credits). Nach 6 mal 10min sind alle credits leer und der user muss noch eine weitere stunde warten, bis er wieder 6 credits bekommt.

Noch nie getestet, aber einer Überlegung. ich weiss halt nicht, wann so ein credit verbraucht wird.

Hi,

Thema erledigt.
Bei den Servereinstellungen bzw. den dazugehörigen Clientzuweisungen hatte sich ein Fehler eingeschlichen.
Dadurch wurde von der pfSense ein Tunnel mit 4 ip´s kreiert.
10.10.8.1, 10.10.8.2 point-to-point (Server)
10.10.8.6, 10.10.8.5 point-to-point (Client)
Ab pfSense 2.0.1 gehört der push und iroute Befehl für das remote Netz in
"Client Specific Override"
Damit erstellt pfSense einen Tunnel mit 2 IP´s und das LAN-to-LAN funktioniert ohne Probleme.
Gruß orcape

wenn in der pfsense der PPTP Server aktiv ist kannst du ohne ein zweites WAN Interface (also einem zweiten Internetanschluss) kein PPTP nach außen machen:
http://doc.pfsense.org/index.php/What_are_the_limitations_of_PPTP_in_pfSense%3F

Such mal nach "transparent squid"
Da solltest du viele Guides finden.

Ich bin fündig geworden.
Wahrscheinlich ist es aber doch besser, wenn ich die pfSense direkt an den Router anbinde und darauf squid laufen lasse, das wird doch einfacher sein. Auf dem Server läuft noch die alte Squid 2.5 Stable 12.

DANKE für die Hilfe !

@Nachfalke: ich habe die Pfsense als KVM auf Proxmox laufen. Deshalb musste ich die Modems auf einem Swich schalten und diesen VLANs zuweisen. Der komplizierte Teil lief ohne Probleme  ;D nur der einfache Teil, dass Modem auch in den richtigen Switchport zu stecken, viel mir wohl ein wenig schwer :o

~~Ich weiss jetzt nicht was du mit Konfigurationsdatei meinst, weil ich nur 2 Datein bekommen habe, denke ich mal dass es due ovpn Datei ist:

client
dev tun
auth-user-pass
proto udp
remote u674011.nvpn.so 1194
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
ca nVPN.crt
verb 3

Hier der Inhalt…
Ich weiss nicht wie das funktioniert. Ich habe den Support angeschrieben und die meinten, dass die keine *.key files benutzten und auch nicht benutzten müssen.
Es funktioniert tatsächlich auf dem Windows Server 2003 mit dem openvpn client 2.2.2
In pfsense habe ich es bis zum authentifizieren hinbekommen:

Nov 25 12:05:09 openvpn[3399]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 11 2011
Nov 25 12:05:09 openvpn[3399]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
Nov 25 12:05:09 openvpn[3399]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Nov 25 12:05:09 openvpn[3399]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Nov 25 12:05:09 openvpn[3399]: Initializing OpenSSL support for engine 'cryptodev'
Nov 25 12:05:09 openvpn[3399]: LZO compression initialized
Nov 25 12:05:09 openvpn[3399]: Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Nov 25 12:05:09 openvpn[3399]: Socket Buffers: R=[42080->65536] S=[57344->65536]
Nov 25 12:05:09 openvpn[3399]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Nov 25 12:05:09 openvpn[3399]: Local Options hash (VER=V4): '41690919'
Nov 25 12:05:09 openvpn[3399]: Expected Remote Options hash (VER=V4): '530fdded'
Nov 25 12:05:09 openvpn[4400]: UDPv4 link local (bound): [AF_INET]46.4.42.23
Nov 25 12:05:09 openvpn[4400]: UDPv4 link remote: [AF_INET]212.7.208.142:1194
Nov 25 12:05:09 openvpn[4400]: TLS: Initial packet from [AF_INET]212.7.208.142:1194, sid=b86d488e d6ef1030
Nov 25 12:05:09 openvpn[4400]: VERIFY OK: depth=1, /C=NV/ST=NV/L=nVPN/O=nVpn/CN=nVpn_CA/emailAddress=support@nvpn.net
Nov 25 12:05:09 openvpn[4400]: VERIFY OK: depth=0, /C=NV/ST=NV/L=nVPN/O=nVpn/CN=server/emailAddress=support@nvpn.net
Nov 25 12:06:09 openvpn[4400]: [server] Inactivity timeout (–ping-restart), restarting
Nov 25 12:06:09 openvpn[4400]: TCP/UDP: Closing socket
Nov 25 12:06:09 openvpn[4400]: SIGUSR1[soft,ping-restart] received, process restarting
Nov 25 12:06:09 openvpn[4400]: Restart pause, 2 second(s)

Ich weiss nicht was ich falsch mache….~~

EDIT: Problem gelöst :D

Jo .. an jedem Standort ist im lan 10.1.0.0/16…
Danke für die Antwort

Hallo lg,

danke für den Tip, dieses tcpdump ist ja mal ein mächtiges Ding.

Kennst du dich damit aus und kannst mir sagen wie der Befehl am besten ausehen könnte.
Arbeite mit der Linux Version auf Centos.

wenn ich über
tcpdump hostname "interneIP"
mitschneide dann zeigt er die internen Verbindungen schön an, sobald ich aber von außerhalb also über das Wan mich verbinden will kommt kein Paket an.
Was kann ich in der pfsense noch einstellen dass diese durchgehen?

Gruß und Danke Dominique

Bin mich auch am einlesen aber das ist sehr undurchsichtig ;-)

Gruß Dominique

@doctohelp:

Hallo Nachtfalke,

danke erst mal für eine Hilfe.
Ich komme mir jetzt vor wie Bart Simpson in der "Ich hab nichts gemacht - Boy" Folge. ???

Heute in der Firma ging es auf einmal. :o
Zuhause wurde mir der Zugriff mit meinem Surfstick verwehrt.

Na jetzt werde ich nur mehr einige kleine Feineinstellungen vornehmen.

Danke auf jeden Fall, du warst eine große Hilfe!

Hi, weiss ja nicht ob du immer noch überlegst, warum das nicht geht … aber ...
eigentlich haste dir die Antwort schon selbst gegeben ... zumindest ist das eine vermutung :)

Surfsticks sind - providerabhängig - manchmal auf bestimmt dienste restriktiert. ... Stell doch den OpenVPN testweise mala uf TCP und mach einfach nen Telnet auf den Server .. dann kannst zumindest mal die schuld deines Providers ausschließen ...
lg

@lotharm:

Nun meine Frage: kann man mit der Installation von pfSense und dem Teil-FreeBSD eigentlich Apache, PHP und MySQL nachinstallieren um den pfSense-Rechner auch als Web-Server für das Portal zu nutzen?

Also PHP und einen Webserver auf dem gleichen System wie die Firewall ist keine gute Idee. "Sicherheit ist nicht nur ein Stück Software, sondern ein Konzep." Und zu diesem Konzept gehört eine eine eigene Hardware. Über Schwachstellen in PHP, dem Webserver oder anderen Anwendungen könnte die ganze Firewall unterlaufen werden.

So weit die Theorie. für den Heimgebrauch kann man Kompromisse eingehen. So habe ich das Ganze über eine Virtualisierung gelöst. Auf der Hardware läuft die kostenlose Version von ESXi. Pfsense als eine VM (virtual machine) mit Zugriff auf die beiden Netzwerkports. Als weitere VM dann ein belibiges Betriebssystem mit Apache, PHP und MySQL. Ich habe mich für CentOS, also den robusten RHEL-Nachbau, verwaltet mit Virtualmin, entschieden. ISP Config wäre eine Alternative.

Durch die Virtualisierung auf meiner Hardware ohne VT-x und VT-d muss ich in Sachen Performance ein paar Abstriche machen. Aber für den Heimgebrauch ist das nicht messbar.

Bei mir gibt es zwar immer noch das Risiko, dass der VM Host angreifbar ist, aber die Lösung ist deutlich sicherer als, den Webserver auf dem Firwall Betriebssystem laufen zu lassen.