[Gelöst]Keine Verbindung zum WEBGui, sobald VPN Verbindung aufrecht

viragomann

Jedoch komme ich, sobald die VPN Verbindung steht, Partout nicht auf die Weboberfläche von PFSense, dass auf einem XEN Server (HP Gen8, Intel 1000PT Quad Port) läuft.

Von wo aus? Von außen, vom LAN?

Poste mal deine Routing-Tabelle bei aufgebauter VPN. Diagnostic > Routes bzw. "netstat -r" in der Shell.
Und verrate uns deine VPN IP.

Teddy

Nabend,
danke erstmal für deine Antwort. Vom LAN aus.

Hier einmal das Routing1, mit PFSense parallel eingebunden (FritzBox mit unmanaged switch), PFSense mit 2xLAN Kabel an LAN (Port1) und WAN (Port2) an Switch angeschlossen, Oberfläche erreichbar. VPN lt. Traceroute Tool auf Weboberfläche verbunden.

Und Routing2 mit PFSense seriell eingebunden (Kabelmodem -> WAN PFSense -> VPN -> LAN PFSense -> FritzBox Port1 zur DHCP Adressvergabe für internes Netzwerk), Oberfläche nicht erreichbar. VPN allerdings verbunden, Verkehr wird auch über opt1 geleitet. (Genau so soll es auch später laufen, mit dem Zusatz des erreichbaren WebGui :D)

Bei beiden versuchen wurde (versucht) die Weboberfläche über die LAN IP zu erreichen. (…178.55).
VPN IP in diesem Fall: 194.187.249.46

Routing1.png_thumb

Routing2.PNG_thumb

viragomann

Da zeigt die Default Route auf die VPN Verbindung. D.h. es werden auch alle Antworten in diese Richtung geschickt.

Liegt offenbar an der VPN Konfiguration. Vermutlich bekommst du die Route vom VPN Server.
Nimm aus der Client Advanced Konfig "pull" raus und richte für die Interfaces, die über VPN gehen sollen, Policy based Routing ein, falls das noch nicht getan ist.

Teddy

Ich stehe ein wenig auf dem Schlauch. :D

Unter OpenVPN Client -> Cyberghost habe ich nun mal bei "don't pull routes" den Haken gesetzt.
Policy based routing, unter Firewall -> NAT?

Sämtlicher Traffic ist vom LAN Port ausgehend (da dort die FritzBox natürlich dranhängt).
In der Firewall ist daher derzeit folgende Regel aktiv:
Source: LAN Net
Destination: Any
Gateway: opt1 (Cyberghost)

Für opt1 (Cyberghost):
Source: Any
Destination: Any
Gateway: Default

Ich bräuchte doch nur eine Regel, die Anfragen an die IP der Firewall (…178.55:444) direkt auch an diese weiterleitet und nicht über VPN schicken will oder?

viragomann

Das kommt darauf an, von wo aus der Zugriff nicht klappt. Womit wir wieder bei meiner ersten Frage wären.

In der VPN Client Konfig steht in den Advanced Settings kein "pull"?.

Den VPN Client musst du natürlich auch neu starten, nachdem du Konfig-Änderungen durchgeführt hast.

Die Firewall Regel für LAN ist okay. Mit dem OpenVPN Client als Gateway ist keine Default-Route vom VPN Server nötig.
Die Regeln müssen nur so angeordnet sein, dass ein Zugriff auf das pfSense Interface weiterhin möglich ist.
Normalerweise hast du als erste Regel am LAN die "Anti-Lockout Rule" (In System: Advanced: Admin Access > Anti-lockout Haken nicht gesetzt), die den Zugriff auf die GUI ermöglicht, also mit Ziel LAN-Adresse und Zielport 444 in deinem Fall.
Wenn diese Regel gesetzt ist, sollte auch der Zugriff funktionieren, vom LAN aus.

Teddy

Zugriff soll ausschließlich vom LAN möglich sein (sämtliche Geräte, außer Kabelmodem selbst) liegen im Adressbereich 192.168.178.xxx), ich hoffe das ist die benötigte Antwort auf die erste Frage!?

Habe mittlerweile nach jeder Änderung an Firewall / OpenVPN die gesamte PFSense neu gestartet. :)

Hier mal die Openvpn Client Config, wie von Cyberghost aus vorgegeben:

auth-user-pass /conf/CYBERGHOST.pas
resolv-retry infinite 
redirect-gateway def1
persist-key
persist-tun
cipher AES-256-CBC
auth MD5
keepalive 5 60
ping-timer-rem
explicit-exit-notify 2
script-security 2
remote-cert-tls server
route-delay 5
tun-mtu 1500
fragment 1300
mssfix
verb 4
comp-lzo

![LAN Rules.png](/public/imported_attachments/1/LAN Rules.png)
![LAN Rules.png_thumb](/public/imported_attachments/1/LAN Rules.png_thumb)
![Cyberghost (opt1) Rules.png](/public/imported_attachments/1/Cyberghost (opt1) Rules.png)
![Cyberghost (opt1) Rules.png_thumb](/public/imported_attachments/1/Cyberghost (opt1) Rules.png_thumb)

viragomann

Habe mir noch mal die Routingtabellen angesehen. Da ist einiges ziemlich strange.

Wenn du die VPN herstellst, wandert das LAN Netz 192.168.178/24 von xn1 nach xn0, was vermutlich WAN ist???
Und gleichzeitig die Default Route von 192.168.0.1 nach 192.168.178.1.
Auf dieses Problem kann ich mir im Augenblick keinen Reim machen.
Vielleicht was mit den Interface-Einstellungen nicht in Ordnung? Hast du auch die pfSense schon mal restartet?

Poste doch mal die Seite Status > Interfaces und das was die Konsole an Interface-Konfig. über dem Menü anzeigt.

Teddy

Nabend,
anbei mal die Interface Einstellungen vor dem Neu-Aufsetzen.
Habe PFSense nochmal platt gemacht, neu aufgesetzt, scheinbar irgendetwas anders gemacht und bis jetzt läuft alles wie gewünscht.
Werde heute Abend nochmal näher auf die Einstellungen eingehen, bin sicherlich nicht der einzige, der PFSense mit Cyberghost füttert. ;)

Bin jetzt auch in anderen Subnets unterwegs:
Kabelmodem: 192.168.0.xxx
PFSense: 192.168.1.xxx
FritzBox: 192.168.178.xxx

WAN.png_thumb

LAN.png_thumb
![Status VPN.png](/public/imported_attachments/1/Status VPN.png)
![Status VPN.png_thumb](/public/imported_attachments/1/Status VPN.png_thumb)

Teddy

Nabend,
wie versprochen hier nochmal meine jetzt funktionierende Konfiguration der jeweiligen Punkte:

System -> Cert Manager:
Nichts besonderes, alles aus den jeweiligen Dateien vom Anbieter einfügen (CA, CERT, KEY Files).

System -> Routing Gateway:
Standardeinstellungen belassen

Erstelltes Opt1 Interface:
IPv4 / IPv6: jeweils NONE
KEIN Haken bei Bogon / Block private Networks

Firewall NAT Outbound:
Regeln UNTEN anstellen (!)

1. Regel (WAN Bound):
Interface: WAN
Protocol: Any
Source: Network: (bei mir: 192.168.1.0, also Subnet vom PFSense)
Port: Leer
Destination: any

2. Regel (VPN Bound):
Interface: OPT1 (erstelltes VPN Interface)
Protocol: Any
Source: Network (bei mir wieder 192.168.1.0, also Subnet vom PFSense)
Port: Leer lassen
Destination: Any

3. Regel (LAN):
Action: Pass
Interface: LAN
Protocol: Any
Source: Any
Destination: LAN Net (HAKEN SETZEN bei "not")
Unter Advanced: Gateway = Cyberghost (OPT, VPN Interface, wie ihr es auch genannt habt)

Und natürlich auf der Haupseite der NAT Regeln auswählen:
Manual Outbound NAT rule generation
(AON - Advanced Outbound NAT)

Firewall -> Rules -> WAN:
Cyberghost Fallback erstellt
Interface: WAN
Type: TCP/UDP
Source: Any
Destination: Any
Destination port Range: 9081 (Cyberghost Ports)

OpenVPN Cyberghost Settings:
Daten oben sollten klar sein (TCP/UDP, Serveradresse, Port 9081 etc.)
Entsprechende Encryption Algorythmen auswählen (AES256CBC), SHA1(160Bit)
Compression: Enabled without adaptive compression
Ansonsten KEIN Haken auf dieser Seite gesetzt

Feld Advanced:

auth-user-pass /conf/CYBERGHOST.pas
resolv-retry infinite
redirect-gateway def1
persist-key
persist-tun
cipher AES-256-CBC
auth MD5
keepalive 5 60
ping-timer-rem
explicit-exit-notify 2
script-security 2
remote-cert-tls server
route-delay 5
tun-mtu 1500
fragment 1300
mssfix
verb 4
comp-lzo

Das Routing sieht mittlerweile auch ein wenig anders aus, aber es läuft erstmal.
Muss mich hier mal reinfuchsen, wie ich es hinbekomme, dass kein Traffic mehr bei Verbindungsabbruch erfolgt und stattdessen erstmal die VPN Verbindung von alleine neu aufgebaut wird.

Danke an eure Mithilfe, reproduzierbar war das ganze bisher nicht, weshalb ich auch gerade nicht direkt wüsste, wo der Fehler zu Anfang lag!
Denke mal bei irgendeiner Firewall-Regel! :(

viragomann

Toll, dass es nun läuft. Ein Neustart war vielleicht eh der schnellste Weg.

@Teddy:

Das Routing sieht mittlerweile auch ein wenig anders aus, aber es läuft erstmal.
Muss mich hier mal reinfuchsen, wie ich es hinbekomme, dass kein Traffic mehr bei Verbindungsabbruch erfolgt und stattdessen erstmal die VPN Verbindung von alleine neu aufgebaut wird.

Wie man das fixiert, wird hier erklärt:
https://forum.pfsense.org/index.php?topic=76015.msg494089#msg494089

Ist doch ein nettes Forum. :)

Grüße

Marvho

Derelict hat dieses Tutorial diesbezüglich verfasst. Kann bestimmt dem ein oder anderen helfen. https://www.infotechwerx.com/blog/Policy-Routing-Certain-Traffic-Through-OpenVPN-Client-Connection