Gar nicht ^^"
Soweit ich weiss ist der Server auf dem die translation files lagen an denen gearbeitet wird auch gar nicht mehr existent.

Vieken dank werde ich machen sobald ich einbischen Zeit finde :)

@GruensFroeschli:

Das funktioniert (bis auf das beschriebene problem) so?
Wenn ja, bin ich äusserst erstaunt.
Hast du vielleicht auf den beiden WANs unterschiedliche Gateways?

Ja, das läuft (bis auf die geschilderten Probleme) tadellos.

Ich sehe da eigentlich keine Probleme, denn das default-gateway ist ja immer "nur" WAN und jedes weitere Interface gehört zu einem beliebigen Netzwerk.
Wenn "WAN2" zum selben Netzwerk gehört wie WAN ABER einen andere IP hat, dann sollte das ohne Probleme laufen.

In den Regeln wird der Weg (gateway) über WAN2 ja gezielt ausgewählt und nur bestimmte Pakete gehen über WAN2 raus.

Meine Vermutung, dass es hier ggf. ein grundsätzliches Problem mit der pfSense gibt, wurde kürzlich durch ein weiteres Problem relativiert. Wenn ich WAN2
(jetzt als VLAN Interface) über LAN an einen lokalen Switch per VLAN-Tag schicke und an ein untagged Interface das WAN2 Modem anschliesse (also ohne Tagging),
dann bekommt die pfSense keine IP per DHCP zugewiesen. Das Motorola Modem verweigert die Vergabe.

Kann es sein, dass die Motorola-Modems von Untity Media die Mac des Interfces der pfSense clonen und dann transparent die Daten durchschicken? Dann würde ein Switch natürlich diesen Vorgang verhindern … andernfalls müsste eine DHCP Server auf dem Motorola-Modem laufen und das ist für die öffentlichen IP Adressen ja nicht der Fall,
denn es gibt kein Transfernetz o.ä. ...

@GruensFroeschli:

Rein von der Art her wie die Routing-table funktioniert, kann es gar nicht gehen zwei mal das selbe subnet mit dem selben Gateway zu haben ;)

Warum und wie genau sieht denn dieser Routing Table aus bei einem WAN und einem zusätzlichen WAN2, das auf ein beliebiges Interface vergeben wurde.

Es bleibt jedoch die Frage offen, warum ab und zu das WAN Interface nicht mehr "default-gateway" ist ?!?

Grüße FBI01

Ahhh…habs schon rausgefunden!!

Man muss zuerst das Filesystem auf read-write stellen per

/etc/rc.conf_mount_rw

dann unter /cf/conf/ im File config.xml diese Zeile wieder hinzufügen (ich habs unter <maximumstates>eingefügt)

<disablenatreflection>yes</disablenatreflection>

das Filesystem wieder auf read-only stellen mit

/etc/rc.conf_mount_ro

zum Schluss das File wieder einlesen mit

/etc/rc.reload_all

und es lief wieder! So jetz muss ich mich nur noch der NAT-Rule widmen, wo ja wohl der Fehler liegen dürfte!</maximumstates>

ok also das mit der rule funzt nicht.

ich bin wie folgt vorgegangen (pfsense is by the way version latest)
firewall ~> rules
lan
add new rule

dort die einstellungen wie folgt:
action : block
interface : lan
protocol : any (funzte nicht…daher mit tcp getestet...ergebnis ~~> ich schreibe gerade mit dem offiziell gesperrten rechner :) )
source type : single host
source ip : 192.168.1.101 (der rechner der gesperrt werden soll und der bekommt auch nur diese ip)
destination port range : entweder any oder http...je nachdem was ich bei protocoll gewählt habe...funzt beides nicht.
log : haken aktiviert da ich sehen will ob der gesperrte rechner versucht rauszugehen.

nun wie bereits geschrieben...der rechner der eigentlich gesperrt sein sollte (also der mit ip 101) ist problemlos rausgekommen denn ich surfe gerade mit dem und poste das hier.

was habe ich denn falsch gemacht?

edith sagt:
ok habe den fehler gerade gefunden. scheinbar ist bei pfsense die reihenfolge der regeln wichtig.
nachdem die sperre ganz unten stand griff sie nicht da vorher eine andere regel alles rauslässt.
gut wiss mer das auch :)

Hi,

also es ist möglich ne pfSense auf dem Thinclient zu installieren!

habs hinbekommen. Nachdem ich durch irgendwelche umstände auf einmal eine Verbindung per COM-Port hergestellt bekommen hab, konnte ich die embedded Version installieren.

Die Firewall läuft einwandfrei.

weniger als 128MB RAM sollte man jedoch definitiv nicht verwenden.
…

Mit 2,8 Mbits downstream Durchlauf hat der Prozessor eine Auslastung von ca. 70%.

Danke!

// kann geschlossen werden

Hat sich erledigt, habe pfsense neu installiert. Laeuft jetzt.
Gruss Alex

Du installierst dir nun einfach pfSense auf vernünftige Hardware und kannst das ganze dann nutzen. Firewalls gehören auch nicht in die VM…

So, habe nun geloest, vielleicht interessiert es wen:

Man braucht keinen Tunnel unter "Tunnels" anlegen.
Nur "Allow mobile clients" anhakerln, Phase 1 und Phase 2 konfigurieren und fuer jeden Tunnel einen Identifier und PSK anlegen.

lg rainer

Vielen Dank!! Hat geklappt!! :)

In der Version 1.2.3-RELEASE tritt dieses Problem nicht mehr auf.

Grüße FBI01

Vielen Dank für den Hinweis !

Ja, wenn man diesen Punkt aktiviert sind die Meldungen aus dem Syslog verschwunden.

Grüße FBI01

@hbc:

Ich weiß zwar nicht mehr genau, wie die Default-Regel lautet (schätzungsweise any bei Protokoll) aber hast Du schon mal versucht vorsichtshalber IGMP explizit als Protokoll zu erlauben? z.B. vor der Default-Regel?

Proto  Source  Port  Destination  Port  Gateway IGMP  WAN      *     224.0.0.0/4  *  *

Ist zwar OT, aber müllt bei Dir der IGMPproxyd auch so das Systemlog voll? Es wird unbenutzbar, weil alles nur noch IGMP ist.

Jabs, aber dazu funktioniert es ja nicht einmal. Programm geht immer 1:30 und dann ne Ecke nicht usw.

Gut  :D,

habe nun in VirtualBox noch 3 zusätzliche Interfaces hinzugefügt und in Pfsense allen VLANs ein eigenes emuliertes zugwiesen.
Damit müsste LAN unabhängig von den VLANs sein.

Das ganze sieht nun folgendermaßen aus:

Host              |    VirtualBox    |      PFsense      |
NIC 1 –------------em0-------------WAN     
NIC 2 --------------em1-------------LAN
                    '-----em2-------------OPT1 / VLAN10
                    '-----em3-------------OPT2 / VLAN20

NIC 1 und 2 sind definitiv VLAN-fähig und werden in VB per Bridging genutzt, haben unter Windows keine IP-Adressvergabe, also nur physikalisch anwesend und aktiv. (Netzwerkkabel verbunden..)

PFsense em0 erhält per DHCP auf NIC1 eine IP vom DSL-Router. Funktioniert soweit alles.
Pfsense em1 hat eine statische IP Adresse. Damit kann ich PFsense dann auch administrieren.

VLAN30 habe ich der Einfachheit halber entfernt.
Am Switchport 1 erhalte ich eine IPadresse aus dem DHCP Bereich vom LAN (em1).
Alle anderen Ports erhalte keine IP (VLANs)
Anbei die aktuellen Screenshots. Am Problem; der DHCP per VLAN; hat sich nix geändert. Funktioniert noch immer nicht.

Die Firewallrules habe ich auf Allow All gestellt (Screenshots)

Help! :-)
LG,
Peter

firewallrules.jpg
firewallrules.jpg_thumb
interfaces.jpg
interfaces.jpg_thumb
vlan_interfaces.jpg
vlan_interfaces.jpg_thumb
assign.jpg
assign.jpg_thumb

Vielen Dank
ich google jetzt mal danach  ;)

Keine eine Idee ?

Ich habe es auch bei anderer Hardware, gleiches Bios bei dem 2. Rechner.
Als dritte Möglichkeit habe ich nun einen anderen Server genutzt mit einem Dualcore. Nun funktioniers… Bin ratlos!

Gruß
Base