Nachdem du die Zeitzone umgestellt hast, musst du pfsense neustarten, da sonst nicht alle Funktionen die korrekte Zeitzone nutzen.

Danke für die schnelle Antwort. Ja, den erforderlichen Neustart beim Ändern der Zeitzone hatte ich schon lange vor dem letzten Upgrade herausgefunden. Seitdem hat sich an der Zeitzone aber nichts geändert. Daher ging ich davon aus, daß nach dem Upgrade kein zusätzlicher Neustart erforderlich sei - ist aber nicht so.

Jetzt, nach dem Neustart, ist alles in Ordnung.

Hier läuft '2.0.2-RELEASE (i386) built on Fri Dec 7 16:30:51 EST 2012 FreeBSD 8.1-RELEASE-p13' auf einem Alix-Board.

Bei bestimmten Logeinträgen (System):

    check_reload_status: Starting packages
    check_reload_status: Reloading filter

wird offensichtlich statt der eingestellten Zeitzone (Europe/Berlin) die Zeit nach UTC (t  - 1 Std.) benutzt.

Bug oder Feature?

Version 2.0-RELEASE (i386) built on Tue Sep 13 18:02:53 EDT 2011

Jeden Tag nach dem Reset der WAN-Schnittstelle um 02:00 Uhr finde ich folgende Einträge im Log:


Oct 29 02:00:24    php: : The command '/usr/bin/killall 'ntpd'' returned exit code '1', the output was 'killall: warning: kill -TERM 62883: No such process'
Oct 29 02:00:24    php: : Creating rrd update script
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : Resyncing OpenVPN instances for interface WAN.

Die Einträge RRD betreffend sind verschwunden, nachdem ich den Traffic Shaper komplett entfernt und manuell neu konfiguriert habe.

Der 'ntpd'-Eintrag ist nach wie vor vorhsnden. Vermutlich wird der Dämon schon beim Reset der WAN-Schnittstelle beendet, das taucht aber nicht im Log auf.

[Status: RRD Graphs]

Version 2.0-RELEASE (i386) built on Tue Sep 13 18:02:53 EDT 2011

Jeden Tag nach dem Reset der WAN-Schnittstelle um 02:00 Uhr finde ich folgende Einträge im Log:


Oct 29 02:00:24    php: : The command '/usr/bin/killall 'ntpd'' returned exit code '1', the output was 'killall: warning: kill -TERM 62883: No such process'
Oct 29 02:00:24    php: : Creating rrd update script
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : RRD create failed exited with 1, the error is: ERROR: you must define at least one Data Source
Oct 29 02:00:24    php: : Resyncing OpenVPN instances for interface WAN.


Zum einen läuft angeblich der 'ntpd' nicht, obwohl er angezeigt wird und auch die angeschlossenen Clients werden einwandfrei bedient:

ps faux|grep ntp
root    20623  0.0  0.6  3316  1352  ??  SNs   2:00AM   0:00.03 ntpd: [priv] (ntpd)
_ntp   53183  0.0  0.5  3316  1336  ??  SN     2:00AM   0:00.63 ntpd: ntp engine (ntpd)



PR    D SRC                   DEST                 STATE   AGE   EXP  PKTS BYTES
udp   O 87.122.128.204:41985  85.214.116.15:123     2:2    207    50    14  1064
udp   O 87.122.128.204:38827  141.40.103.103:123    2:2    150    40    10   760
udp   O 87.122.128.204:56373  178.63.64.14:123      2:1     11    19     2   152


Zum anderen weiß ich nicht, was mir die RRD-Einträge sagen sollen.
Unter Status: RRD Graphs sieht jedenfalls alles normal aus.

Danke für aufklärende Hinweise.

Aber das Szenario macht keinen Sinn, weil er will ja mit dem Proxy wahrscheinlich "anonym" sein. Das ist aber sinnfrei, weil die IP von zu Hause ja dennoch aller Welt bekannt ist. Da ist es sogar anonymer über UMTS zu surfen, da man dort nur die IP adresse des zugangspunktes herausbekommen kann, aber diese keinem handy/UMTS stick zuzuordnen geht.

Ich denke aber eher, das wenn man unter UMTS surft, die Provider doch einiges mitplotten. Alleine aus dem Grund das Ermittlungsbehörden diese Daten abgreifen wollen, um eventuelle Gesetzwittrigkeiten aufzuklären. Ist allerdings ein anderes Thema.

Die Ermittlungsbehörden können nichts "mitplotten". Das ist ja gerade das Problem oder der Segen an den ganzen UMZS Einwahlen. Die Behörden sehen nur die IP Adresse des Einwahlknotens, da die Geräte (UMTS) keine bekommen. Egal.

Der ISP kennt die IMEI des UMTS-Gerätes und die Daten der SIM-Karte. Die Ermittlungsbehörden haben (bei Bedarf) Zugriff auf diese Daten - also nix mit Anonymität durch die (alleinige) Verwendung von UMTS.

Teste mal, ob es mit Regeln nur für TCP funktioniert, für einen SSH-Zugang benötigt man kein UDP. Ansonsten sehen die Einträge korrekt aus. Was sagen die Logs?

In der Übersicht: Status --> Wireless erhalte ich folgende Ausgabe:

Associated or ad-hoc peers
ADDR              AID  CHAN  RATE  RSSI  IDLE  TXSEQ  RXSEQ  CAPS  ERP
00:0e:2e:49:4d:55  1    13    54M   15.5  0     903    14144  EPS   AE
Flags: A = authorized, E = Extended Rate (802.11g), P = Power save mode
Capabilities: E = ESS (infrastructure mode), I = IBSS (ad-hoc mode), P = privacy (WEP/TKIP/AES), S = Short preamble, s = Short slot time

1. Was bedeutet: AID (1)

2. Welche Einheit hat der Wert unter RSSI (15,5)? Unter [1] finde ich: "Der RSSI-Wert ist ein Ein-Byte-Wert, geht also von 0 bis 255, je höher, umso besser die Signalstärke (nach IEEE 802.11-Standard). Ein RSSI von 1 ist der geringste empfangbare Wert." Das kann es aber nicht sein, denn 15,5 ist kein Integer-Wert. Sind es dB, µV, % oder ...?

3. Unter Flags (ERP) habe ich auch schon den Buchstaben 'Q' gesehen - was verbirgt sich dahinter?

4. Mit: 'ifconfig ath0_wlan0' erhalte ich folgende Ausgabe:

ath0_wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   ether 90:a4:de:7a:a5:3b
   inet6 fe80::92a4:deff:fe7a:a53b%ath0_wlan0 prefixlen 64 scopeid 0xa
   inet 10.0.2.1 netmask 0xffffff00 broadcast 10.0.2.255
   nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
   media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
   status: running
   ssid BitBox channel 13 (2472 MHz 11g) bssid 90:a4:de:7a:a5:3b
   regdomain ETSI country DE indoor ecm authmode WPA2/802.11i
   privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit
   txpower 30 scanvalid 60 pureg protmode OFF burst -apbridge
   dtimperiod 1 -dfs

'txpower 30' scheint der umgerechnete 1-Byte Wert (1-255) zu sein, denn als 'Transmit Power' ist 12(%?) eingestellt.

Was bedeutet: scanvalid 60 pureg?

Danke im voraus für aufklärende Hinweise.

[1] https://secure.wikimedia.org/wikipedia/de/wiki/RSSI

Hi

Ich hab das gleiche Problem nach einem Update auf 2.0-RC1-IPv6 (i386) built on Tue Jun 28 21:28:47 EDT 2011

Mit 2.0-RC3 (i386) built on Wed Jun 29 14:20:32 EDT 2011 werden die Logs wieder angezeigt.

Hier läuft aktuell Version: 2.0-RC3 (i386) built on Tue Jun 28 22:08:57 EDT 2011 auf einem Alix-Board 2D13.

Nach dem Update gestern und heute werden überhaupt keine System-Logs mehr angezeigt - auch nach einem Factory Default nicht.

Ansonsten funktioniert das System wie gewohnt völlig normal. Bei meinem Bekannten mit der gleichen Hard- und Software trat der Fehler zeitgleich auf.

Kann sonst noch jemand dieses Problem bestätigen? Die Logdateien sehen sehr merkwürdig aus, besonders die Dateigrößen:

$ ls -la /var/log
total 3848
drwxr-xr-x   2 root  wheel     512 Jun 29 17:09 .
drwxr-xr-x  13 root  wheel     512 Jun 29 17:09 ..
-rw-------   1 root  wheel   65535 Jun 29 17:08 apinger.log
-rw-------   1 root  wheel   65535 Jun 29 17:08 dhcpd.log
-rw-r--r--   1 root  wheel    5062 Jun 29 17:08 dmesg.boot
-rw-------   1 root  wheel  512144 Jun 29 17:08 filter.log
-rw-------   1 root  wheel   65535 Jun 29 17:08 ipsec.log
-rw-------   1 root  wheel   50688 Jun 29 17:08 l2tps.log
-rw-r--r--   1 root  wheel       0 Jun 29 17:09 lastlog
-rw-r--r--   1 root  wheel     581 Jun 29 17:58 lighttpd.error.log
-rw-------   1 root  wheel   65535 Jun 29 17:08 lighttpd.log
-rw-------   1 root  wheel   65535 Jun 29 17:08 ntpd.log
-rw-------   1 root  wheel   65535 Jun 29 17:08 openvpn.log
-rw-------   1 root  wheel   50688 Jun 29 17:08 poes.log
-rw-------   1 root  wheel   65535 Jun 29 17:08 portalauth.log
-rw-------   1 root  wheel   65535 Jun 29 17:08 ppp.log
-rw-------   1 root  wheel   50688 Jun 29 17:08 pptps.log
-rw-------   1 root  wheel   65535 Jun 29 17:08 relayd.log
-rw-------   1 root  wheel   65535 Jun 29 17:08 slbd.log
-rw-------   1 root  wheel  512144 Jun 29 17:08 system.log
-rw-------   1 root  wheel     328 Jun 29 17:09 userlog
-rw-------   1 root  wheel   65535 Jun 29 17:08 vpn.log

[immer]

Source port und source IP bleiben in den allermeisten Fällen immer any ( * )

Welcher SSH- bzw. HTTPS-Client benutzt Quellports < 1024, oder anders gefragt: Welchen Sinn macht es, mehr freizugeben als unbedingt notwendig?

Mein Grundsatz ist: Freigaben so restriktiv wie möglich -Blockregeln so global wie möglich!

[Status: System logs: Settings]

So das habe ich nun gemacht, im DLINK eine Portweiterleitung : Name "all" port: 1-65535 , auf Pfsense (nun 192.168.2.101) und Datenverkehrytyp: beliebig.
Also das ALLES was reingeht zur pfsense geht und diese dann entscheidet.

In der PFsense habe ich dann bei Firewall-Nat eine regel erstellt:

WAN    TCP    *    *    192.168.2.101    54321    192.168.1.4    22 (SSH)

Diese Nat: Port Forward ist mit einer Regel in der Firewall verbunden:

TCP    *    54321    192.168.1.4    22 (SSH)    *    none     

Also ist doch nun im Prinzip für den zugriff von ssh eigentlich alles so wie es sein sollte.
Trotzdem klappt der Zugriff noch nicht. ?

Sicherheitstechnisch sollten in dem Router nur die Ports weitergeleitet werden, die auch benötigt werden.

Aktiviere mal unter: Status: System logs: Settings [x] Log packets blocked by the default rule, dann kannst du im Log sehen, wie die Pakete aufgebaut sind, die eigentlich durchgelassen werden sollen. ... und dann schau dir nochmals meine Beispiel-Regeln für die PfSense an.

The picture shows the increased bandwidth when I switched the Floating Rules on while uploading a file with full speed. My upload bandwidth is definitely 512 KBits (netto), so it seems there is a bug in calculating the 'Bandwidth Out' value. 'Bandwidth In' is not affected by this.



Version: 2.0-RC3 (i386) built on Fri Jun 24 17:47:19 EDT 2011

und wie richte ich da NAT ein ?

--> http://static.highspeedbackbone.net/pdf/D-Link-DIR-615-Manual.pdf Seite 28 (Port Forwarding)

Zieladresse ist die WAN-Adresse der PfSense.

also ich habe nun mir so etwas erstellt:
If    Proto    Src. addr    Src. ports    Dest. addr    Dest. ports    NAT IP        NAT Ports    Description    
   
WAN    TCP    *    54321    192.168.1.4              22 (SSH)    192.168.1.4    22 (SSH)    ssh-oss     
WAN    TCP    *    443 (HTTPS)    192.168.1.4    443 (HTTPS)    192.168.1.4    443 (HTTPS)    https-oss

Aber leider klappt das nicht.
der Router hat die 192.168.2.1 , die WAN der pfsense die 192.168.2.2, die LAN der pfsense hat 192.168.1.1 und der Server am nic1 hat die 192.168.1.4 . Ist da noch irgendwo ein gedanklicher fehler drin ?
Und wieso steht da nun NAT IP und PORT, ob wohl ich da "redirection ip und port" angeben mußte ?

Der Source-Port liegt normalerweise im Bereich 1024-65535 und die Dest.-addr ist die IP der WAN-Schnittstelle:

If  Proto   Src. addr   Src. ports   Dest. addr    Dest. ports   NAT IP        NAT Ports     Description    
WAN TCP     *           1024-65535   WAN address   22 (SSH)      192.168.1.4   22 (SSH)      ssh-oss     
WAN TCP     *           1024-65535   WAN address   443 (HTTPS)   192.168.1.4   443 (HTTPS)   https-oss

Falls der Zugriff auf den Server damit immer noch nicht möglich ist, mußt du in dem Router evtl. ebenfalls NAT einrichten.

Und nicht vergessen: Unter 'Interfaces: WAN - Private Networks - [ ] Block private networks' das Häkchen entfernen!

Mal sehen, wie es nach einer völligen Neuinstallation aussieht ...

Nach dem erneuten Beschreiben der CF-Karte mit dem aktuellen Image (pfSense-2.0-RC3-4g-i386-20110621-1821-nanobsd.img) funktionierte das nächste Update wie erwartet.

Problem gelöst!