@viragomann

Das steht doch schon in meinem von dir zitierten Text mit drin, dass man das Logging global einstellen kann.

Ich habs z.b. generell abgeschaltet und logge mit einer "Deny any any log" Regel zu Diagnostik Gründen auf einem bestimmten IF.

hallo zusammen, es lag an den berechtigungen der start scripten.

Von AGFEO ist mir derlei nicht bekannt. Habe gerade heute wegen einer anderen Sache mit der Händlerhotline gesprochen und die sagte mir, sie arbeiten sehr eng mit Sipgate, Telekom und Co zusammen, damit die Protokolle auch passen.

Hoffen wir das Beste, demnächst steht die Aufrüstung einer AS43 von (drecks)-VOIP-ISDN-MSN(x2) auf SIP-Trunk an. Lässt sich ja nachrüsten, kostet den Kunden nur leider 605 Euro inkl. fürs Modul  ::)

Oder einfacher gesagt: Nein geht nicht (mit der Grundfunktion von pfSense), da die pfSense per default KEINEN Inhalt filtert, sondern nur Verbindungen. Um das zu realisieren, was du dir vorstellst, müsste ganz tief nach Inhalt gefiltert werden, da braucht es aber einen etwas größeren Aufwand mit einem filternden WebProxy und mehr. Und selbst dann greift immer noch flix' Aussage, dass man keine spezifischen Browser gezielt ausmachen kann, da diese mit wenig Aufwand emuliert werden können.

Grüße

Server no

"Server" ist ein Flag, welches im x509 Zertifikat selbst vermerkt ist. Damit wird eigentlich nur signalisiert, ob das Zertifikat für Client/Server oder CA Betrieb ausgestellt wurde. Für HTTPS ist das meines Wissens recht irrelevant, es bekommt allerdings Bedeutung bei bspw. VPN Diensten. Hier kann der VPN Server prüfen, ob sein Zertifikat ein Server Cert ist und ob sich User mit Client Certs anmelden. Mehr sollte das aber nicht ausmachen.

Trotz der funktionierenden Namensauflösung bekomme ich die Zertifakatsfehlermeldung bei Clients (Egal, welcher Browser).

Welcher Art? Nur weil ein Fehler kommt, muss es ja nicht der Selbe sein wie vorher. Es kann auch sein, dass das Intermediate Cert fehlt und damit die CA Kette unterbrochen ist. Einfach mal nachsehen, was der Fehler besagt.

Grüße

hi viragomann
habe eben ausprobiert. leider scheint es so wie ich gedachte habe. da der service beim booten gestartet wird macht der service watchdog gar nichts. auch finde ich keinen weg den ovpn tunnel nicht automatisch zu starten. weil dann denke ich könnte ihn der watchdog nachträglich starten und vielleicht würde es funktionieren.
gruß

das was JeGr sagt denke ich auch.

Mach es einfach per NAT und das den Squid mit seinem Reverse Proxy (falls du den einsetzt) einfach raus.
In der Regel reicht es wenn man das einfach per NAT macht einen Reverse Proxy braucht man relativ selten

@Bluebull:

wie sieht das ganze dann mit sagen wir 4 PFsense boxen aus?

aber wie gesagt wenn z.B. alle IPSEC Tunnel an einer Zentralen Stelle terminieren nütz es nix wenn man da einfach Routen hin setzt das kann IPSEC so nicht. Muss wirklich alles mit Phase 2 bzw. dann eben mehreren Phase 2 gemacht werden und selbst dann kann es zu Problemen führen.
Für so ein vermaschtes VPN sind FritzBoxen eben nicht gedacht. Dann doch eher ein paar PfSense hin und alles mit OpenVPN. Ist zwar auch nicht einfach aber machbarer.

moin,

versuch mal beim Router der UPC admin admin oder admin password oder administrator password ect… normal ist das auf default, wenn nicht dann ruf bei der Hotline an, und sag du hast ein Problem bei der Portweiterleitung, und du musst ein paar Ports zumachen was auch immer, und brauchst das PWD - wenn du nett bist bekommst du es :)

die letzten 6 zeichen/ziffern der MAC adresse sind auch ein warmer tipp :)

und sag du willst ne statische IP4 adresse, und das möge bitte vermerkt werden, dann erzählt er/sie dir dass ihnen die ip4 adressen langsam ausgehen und man auf ip6 portiert wird, dann sag sie mögen dir bitte ne fixe geben und vermerken dass du nicht auf ip6 portiert wirst, mach das aber bald, sonst gehts dir so wie mir, wachst morgens auf, und musst feststellen dass nichts mehr geht ;)

hab ne private 250Mbit leitung mit ner statischen IP also die UPC ändert die IP adressen nur im Problemfall, also bei mir ist sie bis zum Tag der IP6 portierung 2 Jahre lang gleich gewesen, ich bat dann um rückportierung da meine Hardware keine ip6 kann, zack 10 min später inkl eintrag man möge portierungen unterlassen war alles beim alten, ;)

mit freundlichkeit geht da viel bei der Hotline ;)

Update:  Key Lifetime für Phase 1 auf 86400 gesetzt, Phase 2 auf 3600 - Ping vom externen Netz, über IPSec ins interne Netz …. OK. Ping bekommt Antwort.

Andersrum vom internen Netz ins RemoteNetz übers IPSec ... negativ .... weiterhin werden die Pakete ins Internet und nicht in den Tunnel geschickt.

<seufz>.... snbtch !!</seufz>

Der Grund steht doch auch in Redmine:
"It's not valid to configure a PPPoE server on an interface that's a PPPoE client. We'll need to add input validation to prevent such a configuration."

Beides auf dem gleichen Interface wird nicht funktionieren.
Solltest Du das auf unterschiedlichen Interfaces konfigurieren, dann ist das ein neuer Bug. Diesen ggf. melden.

Soo liebe Leute,

selbst ist der Mann.

Für alle die das gleiche Problem haben:
Unter Possible Login Times passen momentan nur 10 Zeiten.
Die 11. Zeit wird nicht übernommen.

Wir schauen momentan, inwiefern man die Abkürzung "wk" von Mo-Fr. umdefinieren kann.

Falls ich was rausfinde, melde ich mich noch einmal.

Gruß
NoiR

Hey,

da kann ich auch noch etwas beisteuern:

Wir haben hier für unser Management VLAN einen TL-WR710N (bei Amaz0n für knapp 30 €) mit OpenWRT "upgegradet", dann mit einem Nano-USB-Stick erweitert und OpenVPN installiert. Kostenpunkt: ca 40€ + Zeitaufwand: ca 30min zur Installation und einrichtung (wenn man sich mit openWRT auskennt). Es gibt aber auch einige Howtos dazu. Dieses Gerät könnte auch als WLAN-/LAN-Ruter dienen, hat aber kein DSL-Modem… Läuft bei uns perfekt stabil (mit VLANs, OpenVPN, etc...)

Viele Grüße, Flomow

GRML Problem gelöst!

Man sollte doch mal länger drüber nachdenken. Zum Hintergrund:
Der Client auf den ich weiterleiten wollte nutzt direkt den Weg über meine Fritzbox, welche am KD Kabelmodem hängt (Gateway: 172.20.21.22)
pfSense betreibe ich aktuell ja parallel zur KD Leitung und das pfSense ist der Gateway 172.20.21.100.

Die Lösung ist also im Client den Gateway zu ändern auf 172.20.21.100, denn die SYN_RECV Meldungen bedeuteten, dass eine eingehende Verbindung zwar erkannt wurde, jedoch der TCP Handshake fehlschlug, da dieser über einen anderen Gateway versendet wurde.

Naja manchmal muss man erst Stunden suchen und hier posten, bis man selber dahinter kommt. ;)