Naja, leider habe ich keine Anleitung parat.
Schon deswegen nicht, weil ich auch mit den "Floating Rules" ein Problem habe; siehe hier.
Also habe ich das hier gepostet, in der Hoffnung jemand liest hier mit, und hat eine Idee, wie man das lösen könnte.

Danke

War das also ein Bug beim Hersteller? Auf jeden Fall war es nicht pfSense. Das ist beruhigend, denn die Aufregung war nicht gering!

Das kann ich mangels Glaskugel nicht sagen ;) Ich habe nach deiner Beschreibung nicht mal verstanden, wo die Mailserver laufen, wohin die schicken wollen etc. Und was für Bug beim Hersteller? Welcher Hersteller? Ich bin fürstlich verwirrt, was du eigentlich sagen möchtest :)

Ach so ist das, na das wusste ich doch nicht. Klar da muss dann wohl etwas anderes her halten.

@rubinho:

Wenn Bedarf ist, kann ich den Auszug aus der Mail besorgen.

Klar, gern!
Ist schon wieder Jahre her, dass ich mit Pascal telefoniert und gemailt habe.
Ich erinnere mich dabei an folgende Aussage zu den APUs, als sie noch gar nicht am Markt waren (Mitte 2013):

Siehe www.pcengines.ch/apu.htm . Firmware ist inzwischen weitgehend ok, Kühlung ist noch etwas knapp.

Generell werden die Geräte bei 20°C Zimmertemperatur "gerade ausreichend" gekühlt und haben keinen besonders großen Spielraum.
Steigt die Umgebungstemperatur auf 30°C, dann sind sie vom roten Bereich nicht weit entfernt.

D'oh! Jetzt läuft der DHCP Server wieder. Danke!! Ich hatte wohl mit dem Subnet ein bisschen rumgespielt und vergessen, den ursprünglichen Wert zurück zu setzen.

Ich hatte jetzt mit der v2.2.3 dreimal das Problem, dass sämtliche eingehnede VPN-Verbindungen (ausser die Verbindungen, wo meine Pfesense der Client ist), sowohl IPSec als auch Openvpn, unterbrochen wurden und nicht wieder verbunden werden konnten, bis ich das WAN-Interface einmal Down und wieder Up gefahren habe. Möglicherweise sind andere eingehende Dienste (Voip) auch nicht mehr glaufen, habe sie aber nicht überprüft

In dem Moment hatte ich auch unrealistische Antwortzeiten an den Gateways (0 ms), die aber Online angezeigt wurden.

Zweimal hatte ich das Problem, nachdem ich die WAN-Verbindung (32Mbit KabelDeutschland) über einen gewissen Zeitraum komplett ausgelastet hatte, beim dritten Mal war der Internet-Anschluss kurzzeitig gestört.

Irgendwie hab ich bei den Problemen den Apinger in Verdacht. Der verfolgt mich schon seit v2.1 und verursacht an meinem KDG Anschluss mehr Probleme als alles andere. Dazu kommt das Problem, das die States ja nicht richtig beendet werden, wenn es Probleme mit einen WAN-Anschluss gibt. Das mag aber ein Problem mit Multi-Wan zu sein (Vermutung)

PS. Ich habe 3 IPSec Tunnel zu Fritzboxen (Unterschiedliche Versionen 7270, 7390, 7490) aufgebaut und laufen bis auf das oben genannte Problem ohen Probleme. (Kurios)

Mit dd-wrt bin ich leider nicht vertraut.
Aber du schickst mit dieser Route den gesamten Traffic über die VPN. Ist das so gewollt?

Wie auch immer, lass die Route weg und versuch meinen Vorschlag mit dem Outbound NAT auf der pfSense. Funktioniert aber nur, wenn der dd-wrt das Default Gateway für den Server ist, was vermutlich der Fall ist. Denn dann schickt er die Pakete zum Router und wenn der die VPN aufgebaut hat, schickt er sie dahin weiter. Wenn nicht, schickt er sie ins WAN, wo sie beim ISP verworfen werden (sollten).

Das ist ohnehin die bessere Lösung, wenn du wirklich, wie du anfangs geschrieben hast, mehrere Router hast, die eine VPN-Verbindung zur pfSense aufbauen.

Hallo,

also wenn ich das recht verstehe, die VPN-Sitzung steht?

Hier widerspricht sich aber was:
@blixz:

Nun ist das Problem das ich während der VPN Sitzung nicht auf unseren internen Webserver zugreifen kann, ping und dns Auflösung funktionieren auch.

Oder fehlt da ein "nicht" am Schluss?

Wenn die Sitzung steht und du kannst das VPN-Gateway pingen, fehlt meist die Route ins Netz, das du über die VPN erreichten möchtest. Dieses muss in der OpenVPN Server-Konfiguration bei "IPv4 Local Network/s" oder eben "IPv6 Local Network/s" eingetragen sein, damit der Client die Route gepusht bekommt. Das Netz darf natürlich nicht das gleiche sein wie das, in dem sich der Client befindet, sonst wird's nix mit der Verbindung.
In deinem Fall, wo die Hosts vermutlich den ISP-Router als Default Gateway verwenden, brauchst du noch entweder eine Route zum VPN-Gateway, oder einfacher, du richtest auf der pfSense eine Outbound NAT-Regel für den VPN-Traffic ein:
Interface: LAN (oder wo immer die Hosts dranhängen, die erreicht werden sollen)
Source: OpenVPN Tunnel-Netzwerk
Translation: LAN address
Eine beliebige Beschreibung noch dazu, alles andere kann auf Default bleiben.

Wenn das nicht hilft, beschreibe einmal detaillierte, was genau nicht funktioniert. "Kann nicht auf unsere internen Webserver zugreifen" lässt viel Spielraum. Über HTTP(S), RDP, SMB,…?

Hi,

Wie unterbinde ich die WebRTC requests vom OpenVPN Client?

..in dem Du die Ursache der Requests beseitigst, Windows.. ;)
Lies mal das dazu, ist auch noch eine weitere Seite verlinkt…
https://www.perfect-privacy.com/german/webrtc-leaktest/
Gruß orcape

Hallo gsm,

hast du hierzu explizit die Anti-Blockout Regel unter Advanced abgeschaltet? Ansonsten ist es eigentlich auf LAN Seite nicht möglich sich auszusperren?
Für den Fall, dass dem so ist: du kannst auf der Konsole mit "8" auf die Shell und dort

pfctl -d

absetzen. Das schaltet vorübergehend SÄMTLICHES FILTERN ab. Also auch NAT. Sobald du in der Oberfläche eine Regel änderst wird das aber sofort wieder eingeschaltet, da ein neues Ruleset geladen wird.

Grüße

Servus miteinander,
das Thema ist noch aktuell. Ich bin nur leider völlig überlastet und komme nicht dazu.

Danke der Nachfrage  :)

Ich habe alle IPs noch einmal neu vergeben. Nun nimmt der C7 die APU als Gateway an. Bis auf den Freifunk-Router (der komischerweise nun gar keine SSID mehr sendet, aber das wird morgen angegangen) funktioniert nun alles :)

Sobald alle Geräte, die insgesamt ins Netzwerk gehören einmal connected waren, kann ich die Mac-Adressen-Einschränkungen vornehmen und alles weitere konfigurieren.

Vielen Dank für die schnelle Hilfe :)

Danke für Deine Ausführungen, es wird langsam alles klarer bei mir hier.

Allerdings bleibt immer noch das CaptivePortal /WIFI Thema über.
Hast Du da auch noch Infos bezüglich meines zweiten Freads oben?

Grüsse Dich
funroli

Aha seltsames Ding. Hat der Sender irgendein komisches Streamformat oder so, dass das ein Problem war?

@JeGr:

Wie bekommt man das?

In den General Settings auf das neue pfsense_ng_fs Theme wechseln, das ein wenig angepasst wurde um die volle Breite zu nutzen (bevor das neue Bootstrap Theme kommt).

Ah, das geht nur in diesem Theme.
Danke!

@dkrizic:

Also unabhängig von pfSense verwende ich noch zwei weitere Tools, um das Netzwerk zu überwachen. Einmal Icinga und einmal Observium.

Sieht vernünftig aus.
Momentan benutze ich unter pfSense ntopng. Scheint auch einiges zu beherrschen; bin noch nicht ganz durch, was es alles kann.

Das kann was mit dem Proxy zu tun haben klar.
Kann aber auch sein das eine Firewall Regel nicht stimmt.

Wenn die NAT Regel auf einen Server in der DMZ geht und die Anfrage aber aus dem LAN kommt muss ja im LAN auch eine Regel sein die Richtung DMZ das erlaubt.

Was passiert denn wenn du statt der öffentlichen IP die IP nimmst auf die Intern genattet wird? Geht das denn?

Danke sehr!

Ich werde das mal ausprobieren und melde mich.

LG
esquire1968

Ich glaube, das Problem lag am C7. Dieser hatte wohl einen weg und lässt sich jetzt nicht einmal mehr per Direktverbindung an den Rechner erreichen. Mit dem Ersatzgerät sollte es dann funktionieren…