Erholt aus dem Urlaub habe ich mich nochmal an das Problem rangesetzt und konnte feststellen das es eindeutig nicht an der Hardware liegt. Also eigentlich schon. Das Problem macht unser Gateway des Providers, eine Frotzbox im Unitymedia Netz.

Die Techniker von Unitymedia schauen sich das Problem nun an.

Habe exakt die gleiche Config und Hardware an einem Cisco3208 Modem zum selben Ziel getesetet und ich habe sofort die 10MBit bekommen.

Bin auf die Lösung gespannt

Da wir in unserem Setup meist nicht nur einen Server des Kunden, sondern mehrere betreuen, schaut hier auch niemand seltsam, wenn der Server eine private IP hat, da wir meistens entweder SSL-VPN anbieten oder VPN-Tunnel zum Kunden aufbauen, damit dieser auf sein Projektsetup zugreifen kann. Da dieses in einem separaten VLAN mit eigenem Netz untergebracht wird, haben alle Kisten dort private IPs. Wir gehen hier noch einen Schritt weiter und Knoten auf den Server des Kunden extra IPs für den notwendigen Service (so er Sichtbarkeit ins Netz hat) so dass bspw. der Server selbst auf .10 hört und arbeitet (SSH), der Webserver aber bspw. auf die .11 und aufsteigend. Damit lässt sich via 1:1 NAT dann gezielt nur der Webserver bspw. nach außen öffnen und selbst wenn jemand die Regeln auf der Firewall versauen würde (alle Ports statt 80,443) würde auf Serverseite nur der Webserver antworten, weil nichts anderes auf der Maschine bspw. auf die .11 hört (natürlich muss dann auch SSH und bspw. NTP beigebracht werden, da nicht drauf zu hören und sich mal kurz auf alles zu binden).

Ein weiterer Vorteil für den Kunden ist, dass er bspw. bei einem Serverupdate hergehen kann (wenn ers beauftragt und zahlt ;)) und die neue Kiste soweit vorbereitet wird (auf der internen IP) und dann kann man für den Livegang einfach die NAT Target IP ändern -> done. Kein unnötiges IP runterfahren auf Server1 und draufbinden auf Server2. Oder man zieht die externe IP via 1:1 NAT auf einen Loadbalancer - oder nutzt bspw. das HAProxy Package - um das Setup zu erweitern. Auch dafür muss am Endsystem dann überhaupt nichts geändert werden.

Natürlich kann man das auch geroutet und mit 2 oder 3 Interfaces lösen wobei ich hier schon oft Server gesehen habe, die dann trotzdem Dienste hatten, die eigentlich intern bleiben sollten, aber dank "BIND ALL" dann trotzdem auf der externen IP erreichbar waren. Sicher steht dann noch die Firewall dazwischen, aber wenn gar nicht erst was drauf hört, ist das immer sinnvoller.

Und zum Thema "sicherer", wenn Server wie DB bspw. dann komplett getrennt stehen: Meist ist es nicht der DB Server der "gehackt" oder übernommen wird, sondern das Frontend. Und da die Server auf die DB kommen sollen, können Sie dann auch weiterspringen (es sei denn man baut es wirklich extrem mit einer zweiten Firewallschicht auch intern).

Für große Provider à la 1&1 und Co. ist es eben einfacher die Server einfach mit externer IP auszurollen (da mietet man meist eh keine Firewall dazu) und die Absicherung der Server von-/gegeneinander dann über VLANs und Port-Security auf den Switchen zu erledigen. Aber gerade speziellere Hosting-Partner die nicht einfach "nur" dedizierte Server anbieten, sondern managed Services/Hosting/Firewall setzen das oft anders auf, um es im Sinne des Kunden besser wart- und konfigurierbar zu haben und ggf. eben auch gut erweitern zu können.

Just my 0.02c (die eher zu 2€ geworden sind ;))

Grüße

Hej guten Morgen,

Zudem stande ich auch vor dem Problem die squid-logs von der pfsense zu bekommen. Was ich nun getan habe ist folgender weg.

Einen symbolischen Link der Logdatei in das www-root der pfsense und dann lasse ich jeden Abend auf meinem http Server ein php script laufen welches die logdatei ausliest und in eine SQL-Datenbank schreibt. In der squid-Konfig habe ich die Log-Rotation auf 1 Tag gesetzt, so wird jeden Tag ein leeres Logfile erzeugt welches ich Abends dann auslese.

Einen anderen Weg (rsyslog wäre genial) habe ich nicht gefunden bisher.

LG
Chris

Danke.

(Wieder mal 'was Naheliegendes nicht gecheckt!)

Gruss
Edgar

http://www.fontpalace.com/font-details/Tahoma/ die Windowsversion runterladen und als root
auf dem betreffenden linux-system nach /usr/share/fonts/truetype kopieren.
Zur Sicherheit noch ein ln -s /usr/share/fonts/truetype/Tahoma.ttf /usr/share/fonts/truetype/tahoma.ttf

@JeGr:

Ahoi,

Ich würde mal mit Glaskugel sagen (den Rest kann ich deiner Kurzzusammenfassung nicht entnehmen), dass dir Routen fehlen. Deine WAN Clients kennen das .100.x Netz nicht - woher auch - ergo schicken Sie die Anfragen an Ihren Default Router (192.168.1.1). Der muss also ne Route zu 192.168.100.x haben, die logischerweise auf das WAN Interface der pfSense zeigt (welches du nicht beschrieben hast).

Der LAN Router dürfte somit das gleiche Problem haben.

Gruß

Danke für den Hinweis! Nun geht es.

SARG ist über Pfsense GUI verfügbar und sollte I.M.H.O deiner Bedürfnisse entsprechen.
Ich habe es bei mir installiert. Ich habe mich aber noch nicht damit beschätgit. Werde berichten wenn es soweit ist und du wenn vorher :)

Oh ohh ich befürchte, falsches Update gezogen… wurde inzwischen korrigiert... Jetzt hilft nur noch neue Installation  :(

So, in der Zwischenzeit bin ich einen weiteren Schritt weiter. Nachdem meine IP-Adresse entsperrt worden ist, ist die Adresse wieder erreichbar.
Jetzt kommt aber das eigentliche Problem:

Ich kann über den Asterisk, der hinter der pfSense steht keine Anrufe über diesen Provider führen (andere Provider funktionieren problemlos). Eingehende Gespräche kommen an. Wenn ich anstatt über den Asterisk über ein Softphone telefonieren will, geht das auch.

Auf der Asterisk-Konsole hingegen erhalte ich immer folgende Meldung:```
chan_sip.c:4174 retrans_pkt: Retransmission timeout reached on transmission 2fd07b462e70d25878b99b0d0f569947@provider.com for seqno 103 (Critical Request)

Ich finde leider keine helfenden Hinweise dazu im Internet. Wer kennt sich damit aus? Soweit ich herausfinden konnte, ist das ein NAT-Problem. Aber was ist dagegen zu tun?

Kein Problem, bei der Vollinstallation kannst du die config.xml mit einspielen (siehe WIKI backup restore als Suchbegriff), dann macht er beim ersten boot das re-assign der interfaces mit dir.

Oder du installierst ganz normal, weisst in der Konsole die Interfaces zu und dann kannst du zum ersten mal einloggen, gehst durch den Wizzard und danach spielst du die config.xml ein. Danach erfolgt ein Neustart durch die Box, die dabei am Ende die Pakete automatisch wieder einspielt (oder es versucht, verkackt (üblicherweise*), dann loggst du dich wieder bei der GUI ein und spielst die Pakete wieder von Hand ein).

Zertifikate sind nicht KORREKTUR: doch mit drin in der config.xml.

Kannst dir die config.xml mal mit dem Editor anschauen, da stehen im Klartext die Einstellungen für die pfSense und die Pakete drin (und die RRD Daten, wenn du die mitsicherst).

Hatte jahrelang IPsec Tunnel, auch mit ADSL mit Zwangstrennung, mit pfSense und mit anderen, da hat es nie Probleme mit dem reconnect gegeben. Vielleicht pennt der DynDNS Anbieter und braucht zu lange, bis er die neue IP verteilt?

Quatsch, probier mal:

In Phase 1 DPD raus (kein Haken)

In Phase 2 unter Advanced Options (ganz unten) bei "Automatically ping host" eine IP im Netz auf der anderen Seite eintragen (auf beiden Seiten des Tunnels)

Interfaces -> WAN-Interface -> IPv4 Configuration Type "Static IPV4"

Static IPv4 configuration -> "IP-Adresse"

Du kannst aber auch temporär das LAN-Interface zum Einrichten des VPN-Servers nutzen. Dann musst du aber, wenn der Server produktiv geht, das Interface wieder umswitchen (Was eine aktive Internetverbindung voraussetzt)

Diese Restriktion ist etwas unglücklich gewählt, da es das Anlegen eines VPN-Dienstes bei einer nicht produktiven Pfsense verkompliziert wird. Aber vielleicht gibt es einen Grund warum das gemacht wurde.

Danke für die Rückmeldung und schön das die Ursache gefunden wurde.

Ich habe das neue ntopng ausprobiert und es funktioniert ohne Probleme.

Genau soetwas habe ich gesucht. Besten Dank.

Gruß
Jan

Hi,

Did you find any solution to this issue?

I'm experiencing the same issue.

Sorry to reply in English.

Thanks.

Guten Morgen,

hat denn die virtuelle IP den 192.168.1.1 als Gateway hinterlegt?

Ich habe das Script nun ausgelagert auf eine andere Maschine und hole mir die Log-File über einen symbolischen Link ;-)
ist mir zwar ein bisschen unlieb da die Access.log dann offen liegt, aber das Netz hängt eh nur intern.

Danke.

LG
Chris

Hallo,
um nochmal auf die Routingtabelle zurück zukommen.

Wenn ich das richtig verstanden habe, resultiert das Geheimnis des "merkwürdigen" Eintrages der Netzwerkmaske 128..0.0.0 in meiner
Routingtabelle aus der Festlegung der bestmöglichen Route (in diesem Fall durch den Tunnel).

Das Verfahren nennt sich "Longest Prefix Match".
D.h., mit diesem Verfahren wird ein Paket nur über die Schnittstelle weitergeleitet, die eine maximale Übereinstimmung mit der Zieladresse hat.

Also:
Netzwerkziel    Netzwerkmaske    Gateway              Schnittstelle        Metrik
0.0.0.0            0.0.0.0                192.168.77.254  192.168.77.116    10
0.0.0.0        128.0.0.0                192.168.200.5    192.168.200.6      25

Hier wird die Route nicht aufgrund des Metric Wertes festgelegt, sondern anhand der der Netzwerkmaske (eben der maximale Übereinstimmung mit der Zieladresse).
Somit gehen die Datenpakete über die 2. Route (Tunnel).

Dann wäre nur noch eine Frage offen:

Mir ist aufgefallen, dass in der Routingtabelle auf dem OpenVPN Server neben der eigentlichen
openvpn Schnittstelle 192.168.200.1 noch eine weitere IP-Adresse 192.168.200.2 auftaucht.
Diese 192.168.200.2 ist aber nicht erreichbar.

Auf dem OpenVPN Client (Windows 7) wird neben der Zuweisung der Client IP 192.168.200.6
dann auf einmal ein Gateway mit der IP 192.168.200.5 zugewiesen.
Die IP-Adresse 192.168.200.5 ist nicht erreichbar.

Die Verbindung geht aber über das richtige GW 192.168.200.1 (z. B. mit Tracert getestet).

Was hat das zu bedeuten?

Gruß
Peter