Welchen syslog Server hast du denn genommen? Gibt es einen syslog Server direkt als iso?

Ich konnte das Problem mit einem passiven Lüfter lösen.

Ein aktiver Lüfter kommt beim aktuellen Projekt nicht in Frage.
Danke für den Tipp.

fg Sven
–----------
Seosuche CH
nethosting

Gerne! :)

Funktioniert.. bin selbst drauf gekommen.

Das Problem ist, dass durch den Squid niemals die virtuelle Adresse angenommen werden kann.
Somit sind Tests, wie "wieistmeineip.de" nicht möglich.
Schickt eine E-Mail von einer privaten an eine zweite private E-Mail Adresse.
Schaut euch den Header an, denn hier könnt ihr die richtige IP herauslesen.
Was bei mir die virtuelle war.

Das hab ich durch die Firewall-NAT (Outbound-NAT) Einstellungen hinbekommen, indem ich diese auf Manuell gestellt habe und die Translation IP-Adresse auf die virtuelle gestellt habe.

Mit freundlichen Grüßen,
sYnCzZz

Nabend zusammen…

heute kann & möchte ich das Rätsel mal auflösen..

Schuld an allem scheint das Modem zu haben. Diese mag wogl irgendetwas nicht was die Sense schickt..

Ich habe es nun gegen ein D-Link 321b ausgetauscht und siehe das alles funktioniert wie gewünscht!

Gruß

OK, ich habe die Teillösung momentan selbst herausgefunden.

Per Hand Anpassung der OpenVPN Client Config Datei.

OPENVPN config zu Portuinity dev ovpnc1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 192.168.100.100 client lport 0 management /var/etc/openvpn/client1.sock unix remote openvpn.ffm.portunity.de 1194 auth-retry interact ca /conf/Portunity-ca.crt tls-auth /var/etc/openvpn/client1.tls-auth 1 ns-cert-type server resolv-retry infinite verb 3 tun-ipv6 tun-mtu 1440 fragment 1400 mssfix auth-user-pass /conf/Portunity-ServerLocation.pas

Damit baut er die Verbindung auf und der Tunnel steht, dennoch kann ich keine Daten Routen.
Im Log taucht beim Verbindungsaufbau folgende Fehlermeldung auf:

Jan 25 08:58:30 openvpn[17268]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
Jan 25 08:58:30 openvpn[17268]: /sbin/route add -net 188.246.4.0 188.246.4.243 255.255.252.0
Jan 25 08:58:30 openvpn[17268]: /sbin/ifconfig ovpnc1 188.246.4.243 netmask 255.255.252.0 mtu 1440 up

Innerhalb der Routing Tabelle wird die Destination aber korrekt angezeigt?

Schön, dass es jetzt so läuft wie Du es gerne hättest  ;)

…und danke für das posten deiner Lösung!

Hast Du diese Seite schon gesehen?
http://doc.pfsense.org/index.php/Example_basic_configuration

Abgesehen davon, würde ich es eher so machen, dass die Gäste im WAN-Netzwerk hängen. Es sei denn, du willst protokollieren wo die Gäste surfen ;-)

Aber gerne doch  :D

Auf bge0 liegen 6 VLANs. Ich nenne Sie einfach 10 - 15.

10 und 11 dürfen überall hin. 15 darf gar nicht nach 10-14 bzw nur auf bestimmten Ports wie DNS nach 11. 15 soll aber parallel Internetzzugriff haben. 12 darf ins Inet und nach 11 auf den DNS und Windows-Share einer Maschine, sonst aber nirgends hin. 13 darf ins Inet und OpenVPN Tunnel zur pfS öffnen.

10 = Desktops
11 = Server / Windows DC
12 = Testnetz / unbekannte Kundenrechner
13 = WLAN privat 802.1X
14 = Hab ich grad vergessen
15 = WLAN Gäste. Linksys WRT54-GL hängt mit den LAN-Ports im VLAN. Auth nach 802.1X

Vielen Dank :-)

Nur noch als Anhang: Wenn du nicht anfangen willst, auf Layer 7 (also Application Layer) zu filtern, wirst du nie verhindern können, dass eine Anwendung X einen Port Y nutzt, der gerade frei ist. Deshalb werden ja bspw. auch viele OpenVPN Server so (um)konfiguriert, dass sie bspw. auch via tcp/443 oder tcp/80 erreichbar sind (zusätzlich zu udp/1194), damit man bspw. aus solchen Dummy-Netzen wie oft in Hotels oder Hotspots verbaut eben doch ein VPN ins Büro/nach Hause aufmachen kann. :)

Wie meinen? Wenn du es auch von außen konfigurieren willst, warum willst du dann das WebGUI auf dem Port nach außen - WAN - abschalten? Irgendwas an deiner Aussage macht da keinen Sinn :)
Und das was du beschreibst dein Problem gelöst hat, macht nichts weiter, als wie gesagt deine Sense mit ihrem DynDNS Namen den sie eigentlich nur extern hat auch intern bekannt zu machen. Macht aber wenig Sinn wenn du - wie dein Topic sagt - die Konfiguration via WAN abschalten willst!

Bevor man(n) sich in irgendwelche Updates ohne weiteren Erfolg stürzt: Was spricht denn das Syslog zu der Sache? Also was findet man in Status/System Logs? Ein Start/Quit/Kill des SSHD müsste dort eigentlich auffallen. Könnte es sein, dass die SSH Keys nicht/unsauber erstellt wurden?

Gar nichts. Wenn der initiale Weg hergestellt werden kann - aka man kann sich auf die gewünschten Server verbinden - ist alles weitere damit erledigt. Da du sehr wahrscheinlich auf dem LAN Interface eine "allow LAN -> any all" Regel liegen hast, ist das damit abgedeckt.

Hi,
keine Ahnung ob der SBS 2008 an der Stelle irgendetwas verwurstet, wenn du die Wizards benutzt.
Mach doch vorher einfach eine Vollsicherung wenn du dir nicht sicher bist.

VG.
Livinlight

Hi,
als aller erste Maßnahme mal auf 2.0.1 updaten.
Und für weitergehende Sachen müsstest du schon etwas konkreter werden.

Viel Glück

so, ich erstatte nur mal meldung:
hat super funktioniert. danke nochmal  ;D