@Wallyrt:

ja genau am LAN Port 1. Im Zyxel ist der VLAN Port 7 jedoch noch gesetzt. (und im pfsense auch) Vielleicht liegt hier der Hase im Pfeffer ?

Darauf bin ich diese Woche auch schon reingefallen  ::)

@bt25:

Ich bin davon ausgegangen das alles was nicht Erlaubt ist geblockt wird und das die Rules sich auf das beziehen was in das Interface von außen rein kommt.

Genau so verhält es sich.

@bt25:

also dachte ich ich muss von dem was in das LAN Interface vom WLAN Interface her rein kommt diejenigen blocken die nicht im Alias sind.

Aber nicht so. Du musst du Regeln immer an dem Interface erstellen, an dem der Traffic in die pfSense reinkommt, hier also am WLAN Interface.

Mit deiner letzten Regel sollte das so funktionieren, wie du es möchtest. Mit der Block-Regel am WLAN und Destination = "LAN net" hätte es allerdings auch funktionieren müssen.

Du tust der Telekom aber unrecht. Wenn ich mich recht erinnere, sollte das ganze statisch werden und dann kam der Aufschrei der Datenschützer.

http://www.computerwoche.de/a/anonymitaet-soll-auch-im-internet-der-zukunft-garantiert-sein,2500429

Schlag mich nicht für das Magazin  :o, hab es dort nur als erstes gefunden …

Gruß
pfadmin

Das sind schlicht und einfach nur Bezeichner für weitere IP Adressen auf die die Firewall an der WAN Seite gelauscht hatte.

host1    1.2.3.4
host2    1.2.3.5
host3    1.2.3.6

usw.

Erst dann hat das WAN Interface auf entsprechende IP reagiert und man konnte sie zusätzlich "nutzen".

ipcop und ipfire arbeiten damit.
http://wiki.ipfire.org/en/configuration/network/aliases

Der Pendant bei der pfsense dürfte unter: Firewall -> Virtual IPs  [Add] Type:IP Alias / Interface:WAN
zu finden sein.

Hallo,

erst einmal eine Standardfrage in deinem Konstrukt: Warum versuchst du an dieser Stelle Layer 2 zu tunneln? Es wäre viel einfacher und in der Regel generell robuster, übersichtlicher und sicherer hier einen Tunnel mit Routing aufzubauen. Gibt es hier eine spezielle Anforderung, weshalb du Layer 2 benötigst?

OK, danke für den Hinweis. Ich will gucken wie es dann ans laufen bekomme.
Ich melde mich wenn ich Ergebnise vorweisen kann  ;) ;)

MFG

Blue_Moon

Wenn ich jemanden mitversorgen würde, was rein rechtlich natürlich schon gar nicht geht, würde ich es aber auch nicht für LAU machen.
Bin ja nicht die Wohlfahrt

Ich habe im Internen DNS meines Lan's die gwünschten Domains mit der IP-Adresse von dem PFSENSE Router hinterlegt und wird beim Pingen auch alle sauber auf die Adresse aufgelöst von allen Pc's.

Warum? Im LAN sollte die DMZ doch einfach durch Routing erreichbar sein. Warum dann die IP der pfSense hinterlegen? Das macht doch keinen Sinn? Extern muss natürlich die pfSense übernehmen, dafür sind dann ja auf dem WAN auch sehr wahrscheinlich Port Forwards eingerichtet auf die IP der DMZ. Aber Intern ist der Spaß doch unnötig. Du definierst schlicht die Regeln für die Ports (am besten in ein Aliase) und die IP der DMZ und gut ist. Dann legst du im internen DNS der ja existiert einfach die DMZ IPs der Dienste an die du erreichen willst, NICHT die der pfSense.

Grüße

Moin,

ist denn der Zugriff von anderen Netzen aus im SMB überhaupt erlaubt?

Gruß
pfadfmin

Erledigt.

@Bordi: Korrekt, allerdings gibt die Telekom hier globalgalaktisch alle Ports frei, was schlicht Unsinn ist. Ich habe an meinen vorherigen Post alle Daten angehängt, wie mein Anschluß mit einem Gigaset funktioniert, gleiche Einstellungen müssen mit einem Softphone gehen. STUN kann im Notfall helfen, eine NAT-Umgebung zu umgehen. Kann aber auch das Gegenteil bewirken. Also besser aus als an.

Danke für die Rückmeldung.

Moin,
ich habe den Lanner NCA-1010B, ein super teil, läuft bei mir stabil seit dem ich ihn habe.
Anschließen, pfSense installieren, konfigurieren, macht was es soll.
Habe ca. 5 VPN´s Laufen (4 x ipsec zu Fritzboxen, 1 x OpenVPN) und da sind noch Reserven.

Oder aber deine PF protokolliert ständig Anfragen deiner Klienten an Microsoft und dem Port 443/80 der naturgemäß durch den Proxy bedient werden sollten.

Dann mal wie in einem anderen thread empfohlen cmd öffnen und:

netsh winhttp import proxy source=ie

eingeben. Leitet die Anfragen der ignoranten Klienten korrekt über den Proxy und sorgt bei richtiger Einstellung für eine grossteilige Bedienung aus dem Cache.

Grüße

Hmm, klappt trotzdem irgendwie nicht… naja, ich werde mich nochmal nach dem Urlaub dransetzen und intensiv mit dem Blocker beschäftigen. Danke für die Hilfe soweit!

@JeGr:

Dass es trotzdem empfohlen ist, liegt eher in der sinnvolleren Debugging und Netzlayer Verfügbarkeit weil man von außen sonst die Knoten direkt einfach nicht erreichen kann.

Das ist natürlich ein gutes "Pro"-Argument. Dann lass ich die Konfig so wie sie ist.

@lendrod:

Hallo,

zur Zeit ist da ja eine Login Page wo dann der Voucher Code eingegeben wird.

Zukünftig soll ja erstmal nur eine Seite sein wo halt die checkbox ist für AGBs gelesen und akzeptiert und die AGBs verlinkt.

Wenn ich das gemacht habe, soll der Gast für XX Minuten/Stunden/Tage Zugang zum WLAN bekommen

Wie setze ich das in Captive Portal um?
Hat das schon jemand gemacht?

Zum Thema "Störerhaftung" und rechlichem Schnickschnack weiss ich nichts, kann dazu keine Auskunft geben.

Wie ist denn Dein Internet-Zugang nun genau aufgebaut?

Ich gehe davon aus, dass das WLAN unverschlüsselt offen ist, und ihr den Local User Manager/Voucher-Manager der Pfsense nutzt.
-> Jeder kann sich ins WLAN einbuchen - erhält sofort eine IP-Adresse, lediglich das Captive-Portal verhindert einen Zugriff aufs Netzwerk/Internet solange kein Voucher eingegeben wurde?
-> Das der Zugang künftig über den Haken "AGB anerkannt" freigegeben werden soll, hat nichts mit dem Capitve-Portal der Pfsense zu tun. Das mußt Du auf der
    Capitve-Portal-Page separat lösen. Die Portal-Page so aufbauen, dass MAC-Adresse, IP-Adresse und das "AGB anerkannt" dann irgendwo mitgeloggt werden und nur der Zugang zum   
    Internet freigegeben wird, wenn der Haken "AGB anerkannt" auch gesetzt ist - meines Wissens stellt Pfsense für sowas keine Standard-Lösung bereit.
-> Da es hierbei keine Authentifizierung durch den Local User Manager/Voucher-Manager mehr gibt, hat die Portal-Seite keine Authentifizerungs-funktion mehr, die mit Pfsense zusammenhängt.
    die Authentication-method des CP ist dann auf "No Authentication" zu setzen. Das bedeutet, dass jeder der auf Deiner Portalseite irgendeinen Push-Button drückt, oder einen Haken setzt,
    dann automatisch Netzwerk/Internetzugang bekommt
–> Die Zeitbegrenzung kann über das "Hard-Timeout" und /oder "Idle Timeout" des CP gesteuert werden. Allerdings kann die Person sich nach dem Timeout sofort wieder einlogen indem die 
    AGB auf der Portal-Seite  wieder aktzeptiert werden. Das kannst Du dann mit den "Pass-through-Credits" limitieren.