@flix87:

Hat es bei dir denn nun geklappt?

das Löschen der states hilft beim Testen.

Im Prinzip funktioniert's nun auch (zumindest bei den ersten Tests!) für mehrere (interne Server), die auf Port 80 lauschen.

Ich bin noch am Probieren (Redundanz, etc.) und melde mich wieder!

Gruss/Danke
E

Hallo lazyfruit,

gut daß es erstmal geklappt hat. Warum es einen Tag später Probleme gibt, ist dann schwer pauschal zu sagen. Geht zu dem Zeitpunkt ein Softphone? Der Provider könnte ein Problem haben, das ist aber eher unwahrscheinlich. (Andererseits: Bei einem Verwandten war der neue VoIP-Telefonanschluß mehrere Tage gestört.)

Ich selbst habe seit dem Update auf pfSense 2.2 regelmäßig Hänger der gesamten Box. Die ist dann auch über ssh nicht erreichbar und ich muß neu starten. Telefone gehen dann natürlich auch nicht. Sowas würdest Du aber merken.

Noch aus Interesse:  Wie hast Du Traffic Shaping konfiguriert? Ich habe seit heute morgen ebenfalls ein C430-IP installiert und das hat ja höhere Anforderungen als meine bisherige Lösung. Mich würde interessieren, wie Traffic Shaping an einem Telekom-Anschluß mit Entertain sinnvoll eingerichtet werden kann.

-flo-

Hi,

ich habe das hier so problemlos mit squid-dev am Laufen. Ich habe z.B. die statische IP 1.2.3.4 und alle Hosts zeigen auf dieselbe statische IP:

www.domain.com webdav.domain.com bla.domain.com

Ich herwende ein *.domain.com-Zertifikat.

Reverse Proxy -> General -> reverse HTTP proxy port auf 8080 stellen, und HTTPS proxy port auf 8443 Entprechende Port forwards am WAN interface einrichten: 80 auf 127.0.0.1 port 8080 und 443 auf 127.0.0.1 port 8443 Damit ist der Reverse Proxy von extern auf HTTP 80 und HTTPS 443 erreichbar.

Dann

Reverse Proxy -> Web Servers mit "+" einen neuen Server hinzufügen Enable this peer auf on Peer alias "www" Peer IP auf Name oder IP vom internen Web-Server Peer Port auf Port-Nummer des internen Servers Peer Protocol auf HTTP oder HTTPS, je nachdem, was der Server auf dem o.g. Port spricht. Ein Server kann extern per HTTPS angesprochen werden, obwohl er intern nur HTTP macht

Dann

Reverse Proxy -> Mappings, "+" Enable this uri auf on Group name "www" Peers "www" auswählen (ist der Name von oben) Bei URI dann "^http://www.domain.com/.$" eintragen, wenn HTTP und/oder "^https://www.domain.com/.$ wenn HTTPS

Jetzt müsste man von extern (oder über NAT reflection auch von intern) auf http://www.domain.com oder https://www.domain.com zugreifen können.

Dann mit allen anderen Servern wiederholen.

@JeGr

vielen Dank. Das ist genau das was ich gehofft hatte, aber noch testen konnte.

nslookup brauchst du nicht (ist eh deprecated), pfSense hat ganz regulär das "host" command mit an Bord. Warum mit 2.2 dig nicht mehr dabei ist, bin ich gerade überfragt.

@gadh:

Punkt 1.
Es gibt 2 Gateways im Netz. Damit die per VPN angebunden Clients auf Netzwerk-Resourcen zugreifen können muss der pfsense-Router als Gateway gewählt werden. Das ist mir klar. Muss in Firewall trotzdem eine Route eingerichtet werden?

pfSense VPN wird automatisch als Gateway verwendet, wenn du in den Server-Einstellungen bei Local Networks dein LAN einträgst und der Client das push-route Kommando verarbeiten kann.

@gadh:

PUNKT 2.
Der DNS für den OpenVPN-Server sollte doch am besten der Windows-Server sein oder?

Was meinst du mit "für den OpenVPN-Server"? Den DNS, der den Hostnamen des OVPN-Servers auflöst?
Der DNS-Server, den du in der OVPN-Server-Konfig angeben kannst, ist der der die Namen im Remote-Netzwerk auflösen kann. Wird der angegeben, wird er vom Client innerhalb der Verbindung verwendet.

@gadh:

Punkt 3.
Müssen für die Openvpn-Clients Routen in den conf-Datei eingericht sein? (Im Wizard hab ich bei Tunnel\Setting\ Lokal Network den Adressbereich angegeben). Müssen dann trotzdem bei Andvanced noch manuelle Routen eingetragen werden?

Nein.

@gadh:

Punkt 4.
Ich nutze ein tun-Device muss man trotzdem eine Bridge zwischen WAN&LAN erstellen?

Versuch das lieber nicht. tun und Bridge widersprechen sich quasi.
Aber warum überhaupt zwischen WAN u. LAN? Eine Firewall hat normalerweise die Aufgabe, genau diese Bereiche strikt zu trennen.

Wenn du einen OpenVPN-Server eingerichtet hast, zeigt die pfSense in Firewall > Rules ein virtuelles Interface für OpenVPN. Hier musst du dann die Regeln einrichten, was die Clients dürfen. Also bspw. deine Rechner im LAN erreichen. Wenn ohnehin alles, ist es einfach, ansonsten musst du dir die Regeln wohl überlegen.

Grüße

–Update--

Das Problem scheint wohl mit meinem anderen Problem https://forum.pfsense.org/index.php?topic=92446.0 zusammen zu hängen.

Die States verharken sich nur dann, wenn der Zustand meiner Gateways flapt und ich von Status Emails überschüttet werde.

@JeGr
Gibts eine Möglichkeit, dass diese Failover Gruppen etwas träger reagieren, sprich erst dann umschalten wenn das Gateway mindestens 30 Sekunden nicht erreichbar ist ?

Hallo Jens,

danke Dir für Deine Rückantwort!

Vorweg erst noch einmal zur Präzisierung, hatte ich gestern vergessen: Alle Adressen sind statisch definiert. Nirgendwo läuft DHCP.
Ich möchte auf der pfsense1 so wenig wie möglich Traffic haben, daher die Trennung und ein separater WLAN-Router. Dann können die WLAN-Geräte untereinander "ungestört" über "ihren" AP kommunizieren.

Jetzt zu Deinen Fragen:

Dazu ist in der pfsense1 eine weitere Neztwerkkarte installiert (192.168.15.10). An dieser Karte hängt eine zweite pfsense (räumlich weit getrennt, pfsense2).
Was für eine Netzwerkkarte? WLAN? LAN? Wie ist die zweite pfSense angebunden?

Die pfsense2 ist über ein normales LAN-Kabel mit pfsense1 verbunden. Die "weitere Netzwerkkarte" in pfsense1 ist eine ganz normale LAN-Karte (OPT1). Gegenstück auf pfsense2 ist das WAN-Interface.

Die WLAN-Schnittstelle ath0 hat die 192.168.13.10.
Wo ist diese denn verbaut? Pfsense 2?

Genau! In der pfsense2 ist OPT1 als ath0-Schnittstelle (das WLAN) eingerichtet. Funktionierte auf Anhieb, die Einrichte-Maske ist sehr gut gemacht!
Zur pfsense1 führt die oben beschriebene LAN-Verbindung über das WAN-Interface.
Das LAN-Interface in der pfsense2 ist auch vorhanden, wird aber derzeit nicht genutzt (hatte es zur ersten Einrichtung genutzt, wer weiß, wozu ich es später mal noch brauchen kann….)

Nunja letzteres ist aber nicht unbedingt ein Grund das komplette Feature abzuschalten. Man kann die WLAN Geräte ja durchaus untereinander kommunizieren lassen (doch häufig eher: warum?) und frei von WLAN -> WAN zugreifen lassen (WLAN to any Regel), ohne das gleich abzuschalten.

Stimmt. Ehrlich gesagt habe ich mir gedacht, ich schalte das mal ab zur Komplexitätsreduktion bei der Fehlersuche. Klar kann man auch da eine Firewall aktiv lassen. Ggf. kann man sich dadurch auch einen Hauch Performanceverlust einsparen? Das ist aber eher nebensächlich.
Da hier einige Notebooks werkeln, kann es durchaus mal sinnvoll sein, dass die Geräte über sftp/ssh untereinander kommunizieren können, und sei es nur für "primitiven" Datenaustausch.

Auf pfsense2: ist dort auf dem "WAN" also dem Uplink im 15er Netz zur pfSense 1 denn eine Regel für einkommenden Verkehr angelegt, dass Verkehr vom Netz/Interface der pfSense 1 überhaupt rein darf?

Hm, erziele ich das nicht durch Abschalten der Firewall? Falls nein, habe ich jetzt die Regel entsprechend eingerichtet und alles erlaubt.

ist auf pfSense 1 denn eine Regel angelegt, dass Verkehr vom Link Interface zu pfSense 2 denn überhaupt rein/raus darf?

Asche auf mein Haupt, nein. Ich dachte, für OPT gelten die gleichen Regeln wie für LAN, bei dem das ja standardmäßig erlaubt ist. Dazu gelernt: Dem ist nicht so. Habe ich also nachgepflegt. Aber auch hier: Wenn die Firewall deaktiviert ist....??

Fazit nach erneutem Versuch mit den eingetragenen Regeln: Trotz entsprechender Regeln keine Veränderung. Von den WLAN-Clients kein Zugriff auf pfsense1 und von pfsense1 kein Zugriff auf die WLAN-Clients.

Also tatsächlich eine Routing-Frage, die ich dann wohl unter "Routing" klären müsste? Nur wie? Es gibt bereits eine Regel auf pfsense1 die das Netzwerk 192.168.13.0 über das Gateway 192.168.15.11 (also WAN-Interface von pfsense2) erreichbar machen sollte. Sie muss demzufolge falsch oder unvollständig sein? Oder es fehlt an anderer Stelle etwas Grundsätzliches?
Wo ist mein Denkfehler?

Danke und Grüße,
Matthias

Ja das Gerät kann Vectoring.

Ich poste nachher mal Bilder von allen Konfiguration , damit wir gemeinsam eine Lösung finden können.

Vielen Dank für deine Hilfe.

vielen Dank für die Antworten.

Ich habe es mit der Anleitung von administrator.de Schritt für Schritt gemacht, zwei Mal und nun funktioniert es. Also die Geräte per Kabelverbindung und die über WLAN rein kommen sind jetzt in einem Netzwerk und kommen auch ins Internet. Die Firewall Regeln wollten aber wohl direkt so greifen, nachdem ich auf "Apply change" geklickt habe.

Das funktioniert jetzt erst mal soll so laufen an den Start gehen, dann werde ich sehen, an welchen Stellen es hapert und wo ich noch eingreifen muss.

Nochmal Danke für die Antworten.

Hi,
da muss ich mich JAP anschließen, ich bezweifle, dass du selbst mit falscher Terminal Emu irgendwas beim Bootup so fies verstellen konntest, dass jetzt gar nix mehr geht. Ein Full-Reset oder ein Toggle der Console sollte da helfen, ansonsten mal im Handbuch blättern, wie man das BIOS resetten kann. Denn ohne dass du irgendwas wirklich per Filetransfer geflasht hast, könntest du nur irgendeine Einstellung verdrehen.

Grüße

Eieieieiei, das ist ja mal eine fiese Bug / "Feature" Kombination :)

Freut mich aber dass du damit dem Ganzen auf die Schliche gekommen bist :D

Viele Grüße

Gern und danke :)

@rubinho:

Vielleicht fehlt einfach nur die Rückroute in der FB.

Geiler Scheiß, das wars! Vielen, vielen Dank für den Tipp  ;D

Auch ich würde, wenn ich die Wahl hätte, Openvpn nutzen.
IPSec ist meiner Meinung nach, ne richtige Diva, vorallem wenn du einen Tunnel mit unterschiedlichen Geräten (Hersteller) aufbauen musst, zickt IPSec nur rum.

Openvpn dagegen verzeiht dir so einiges (z.b temp. Verbindungsabbrüche)

Moin,

habe den Accesspoint soeben in Produktivbetrieb genommen. Ein TP-Link C7 mit openWRT stahlt insgesamt 6 SSIDs auf 5 VLans gebrückt und versorgt alle mit W-Lan. Falls es knapp wird setze ich noch einen 2.Accesspoint aber bisher scheint es zu reichen.

-teddy

We recorded a packet loss of 36%.

Wenn sich das von Innen nach Außen aber reproduzieren lässt, würde ich das dem Provider mal um die Ohren hauen ;)

BTW:

Direct TCP access to remote RPC servers (port 135) is allowed.
liest sich für mich nicht unbedingt in !negativ Schreibweise. Und wenn das grün hinterlegt ist… naja. Warum ich sowas anzeige, muss ich nicht verstehen ;)

Ahoi,

richtig, es geht nur um Full Installs ohne Console. Auf einer APU macht man die normalerweise eher seltener (also full install) und noch seltener ohne console ;) Das soll auch prinzipiell nicht alle Hardware betreffen, deshalb denke ich nicht, dass APUs davon befallen sind.

Grüße

Also

IP/Port weiterleiten von Router auf das WAN der pfSense (auf die vIP des WAN) Rules: für das betreffenden WAN-interface auf der pfSense -> "IPv4(UDP)" von "/" auf "/1194" per Gateway "" Rules: für OpenVPN -> "IPv4() von "/" auf "/" per Gateway "" Routes: Netz des VPN auf das Gateway auf dem aus auch angesprochen werden soll (also das entsprechende WAN, dessen vIP du oben benutzt)

Wenn du einen Router hast, bei dem du nicht bestimmen kannst, welche IP abgehend dann benutzt wird… also keine Ahnung was dann passiert.
Was für ein Router ist denn das?