Gateway offline- OpenVPN Problem

viragomann

Hallo!

Ich frage mich, wie du od. pfSense auf die Gateway Adresse von "SKISS_VPNV4" kommt. Du hast einen simplen Client konfiguriert, dem Interface ist 10.11.63.10/32 zugewiesen. Da ist kein Platz mehr für ein Gateway.

Meiner Meinung sollte dem Gateway die Client-IP zugeordnet werden oder du musst ein /30er Netz für den VPN Client konfigurieren.

Grüße
Richard

esschallert

mhm ok, in dem Tutorial wurde davon nicht erwähnt, nur das man eben das neue Netzwerk namens SKISS erstellen soll. Wie kann ich denn ein /30 Netzwerk erstellen, damit der Spaß endlich funktioniert bzw. wie ordne ich dem Gateway die Client IP zu?

viragomann

Leider keine Erfahrung mit OVPN Clients auf pfSense, habe bislang nur Server konfiguriert. Was Netzwerk und Routing betrifft, wird das aber ähnlich sein.

Daher meine Frage, wie es zu dieser Gateway IP kam. Selbst konfiguriert oder hat das pfSense automatisch gemacht.
Die richtige Einstellung könnte ich daher nur mit Probieren herausfinden.
Also in System > Routing die Gateway IP von SKISS_VPNV4 auf die des VPN Clients setzen, 10.11.63.10.
Wenn das nicht zulässig sein sollte oder nicht funktioniert, das Netz in der OVPN Client Konfig umstellen. Die 10.11.63.10/32 hast du ja wohl selbst eingegeben. Da bei "IPv4 Tunnel Network" 10.11.63.10/30 einstellen, dann kann 10.11.63.9 die Gateway IP sein.

Hoffe, eine der Lösungen funkt.

esschallert

die Gateway ip hat pfsense selbst gemacht. Also der erste Lösungsansatz geht leider nicht, da ist der Gateway zwar online kann aber totzdem nicht ins Internet. Wenn ich die zweite Lösung mache, kann ich die Gateway ip nicht auf die von dir genannte IP ändern da kommt dann folgende Meldung.

The following input errors were detected:

The gateway address 10.11.63.9 does not lie within one of the chosen interface's subnets.

Kann es sein das es ein DNS Fehler ist? Hier mal ein Bild dazu was ich unter DHCP Server für LAN eingestellt habe

http://abload.de/image.php?img=dns6js0c.jpg

Hier ein Bild von dem IPv4 Tunnel
http://abload.de/image.php?img=gateway-offline-23ssft.jpg

Hier dann nachdem die IP nach der Tunnel Einstellung automatisch zugewießen wurde (musste die 10.11.63.9 nicht selbst eingeben, hat er dann automatisch geregelt)

http://abload.de/image.php?img=gateway-offlineijs9o.jpg

Wenn ich aber die Tunnel IP wieder rausnehme und die 10.11.63.9 selbst eingeben will kommt folgendes

http://abload.de/image.php?img=gatewayaddress3ns0j.jpg

versteh es einfach nicht, in dem Guide ist garnichts weiter dazu beschreiben, da geht es einfach, in dem Guide wird nur beschreiben, wenn es nicht gehen sollte, kann es nur an der DNS ip liegen.

Hier noch mal ein Bild von Status System Logs > OpenVPN

http://abload.de/image.php?img=openvpn-statusxksc4.jpg

vll hat auch der proxy über den ich gehe keine richtige Verbindung? Wäre das eine weitere Möglichkeit?

EDIT:

Hier noch ein Bild von pfSense VM direkt nachdem ich den Gateway mit der OpenVPN adresse verbunden haben, nachdem er online ist.

http://abload.de/image.php?img=pfsense-nderungdss2x.jpg
http://abload.de/image.php?img=gateway-onlinecxsll.jpg (Internet ist aber trotzdem nicht anwählbar, wie oben beschrieben)

viragomann

Okay, verstehe. Die Netzkerk-Konfiguration bekommst du vom OVPN-Server zugewiesen.
Demnach sollten beide Lösungen hinfällig sein. Damit wird die Client-IP und das Gateway automatisch konfiguriert und es darf bei "IPv4 Tunnel Network" auch nichts eingegeben werden.

Bei der neuen Verbindung hast du auch eine neue IP zugewiesen bekommen: 10.10.14.74
Was ich aber nicht verstehe ist, weswegen dein VPN ein /32 Netz ist. Laut dem Log sollte dir ein 30er Netz zugewiesen werden und das Gateway sollte 10.10.14.73 sein.
Das /32er Netz am Interface lässt dieses aber nicht zu, das ist auch die Aussage der Fehlermeldung, wenn man versucht das Gateway selbst zu setzen. Durch den VPN Client funktioniert das Einrichten des Gateways offenbar, bringt aber nix.

Nein, mit der Client-Adresse als Gateway kann es nicht funktionieren, dass war eine dumme Idee, darauf hat mich das /32er-Netz gebracht, weil da kein Platz für eine Gateway-IP ist.
Die Client-IP ist aber nötig, damit der Server IP Pakete zu dir schicken kann. Auf deiner Seite ist wieder eine Gateway-IP nötig, damit deine Paket darüber geroutet werden können und zum Server gelangen.

Mit dem DNS sollte es nichts zu tun haben. Das kannst du aber leicht überprüfen indem du eine IP einer Standardwebsite anstatt des Namens im Browser eingibst. Z.B. f. google.de http://173.194.46.23/
Mit derselben IP kannst du auch mit traceroute testen, ob dein Routing funktioniert:
traceroute 173.194.46.23
Wenn die Routen stimmen, sollte 10.10.0.1 als erster Hopp drinnen stehen. Wenn da aber dein WAN_GW kommt, ist da was faul.

Was meinst du mit proxy? Den OVPN Server, mit dem du dich verbindest?
Das verrät dir auch obiger Test.

Ich halte im Übrigen die Anleitung auch nicht gerade für übersichtlich. Ich denke die ist klarer, behandelt aber nicht ganz dein Thema:
https://forum.pfsense.org/index.php?topic=29944.0
Vor allem der Part der Gateway-Konfig:

ensure the Interface selected is the new one we have just assigned to the vpn client; should be "OPT1"
Enter the gateway name.
for "Gateway", enter "dynamic"
do NOT click "Default gateway"
for monitor IP, enter 208.67.222.222 (or whater will respond to ICMP)(208.67.222.222 is openDNS fyi)
leave "Advanced" alone
enter a description for "Description"
click save

Bei deinem ist "Default Gateway" gesetzt. Ob das dynamic was bringt, weiß ich nicht. Ich denke, das sollte automatisch so sein.

Noch etwas, deine Bilder zeigen nichts vom NAT. Hast du das Outbound NAT gemäß der Anleitung konfiguriert?

Vielleicht meldet sich hier ja auch mal jemand, der mit dem Thema VPN Client f. Web-Gateway vertraut ist.

esschallert

ok werde ich mir mal anschauen.

@viragomann:

…Hast du das Outbound NAT gemäß der Anleitung konfiguriert?

Vielleicht meldet sich hier ja auch mal jemand, der mit dem Thema VPN Client f. Web-Gateway vertraut ist.

~~steht das mit dem Outbound NAT in der Anleitung von meinem ersten Post wohl mit drin? Wenn ja hab ichs übersehen, oder meinst du die sache mit der Firewall?~~

EDIT: OH mann, irgendwie, fragt mich nicht wie, hab ich genau die Stelle überlesen, kein wunder das es dann nicht ging….
EDIT2: Jetzt kommt der entscheidende Part mit den nested chains, mal schauen ob ich die nächste pfsense zum laufen bekomme

esschallert

so erstmal sorry für doppel post, nur wegen der Übersicht hier.

Bin jetzt an dem Tutorial mit NestedChains. Werde aber nur 2 pfSense betreiben, also nicht wie dort beschrieben 4+ usw.

Das andere Problem wurde ja jetzt gelöst, nun versuche ich mit einer zweiten pfSense VM eine weitere Proxyverbindung zu schaffen. Soll dann so funktionieren.

1. pfSense bildet den Grundbaustein
2. pfSense wird sozusagen durch die 1. durchgeschleift und stellt ebenfalls eine VPN Verbindung her
3. ubuntu greift dann also auf die 2. pfSense zu welche ihr "Signal" von der 1. bekommt

Nun im folgenden ein paar Bilder wie es jetzt auf der zweiten pfSense aussieht. Auf gut deutsch, da geht im moment garnix ^^

Dashboard http://abload.de/image.php?img=1ywupu.jpg

Gateways down (diesmal auch der WAN) http://abload.de/image.php?img=gateways-downwdutl.jpg

OpenVPN bekommt keine Verbindung, denke mal das es daran liegt, das der Gateway down ist. http://abload.de/image.php?img=opvenvpn-downuduin.jpg

beide pfSense an 1. funktioniert auch nur zweite halt nicht http://abload.de/image.php?img=pfsense12mwulv.jpg

Hier der 1. Adapter der pfSense, welcher auf die erst erstellte pfSense zugreift. http://abload.de/image.php?img=vm-adapter-1yeuv8.jpg

und hier der zweite Adapter, von diesem wird dann die Verbindung zu Ubuntu hergestellt http://abload.de/image.php?img=vm-adapter-27nu2m.jpg

Hab auch das mit den IP ranges gemacht vom Tutorial

Also, in chaining multiple pfSense VPN-client VMs, it’s crucial that adjacent pfSense VMs have different LAN IP address ranges. Otherwise, no traffic will flow, because pfSense is a NAT router, not a switch. The simplest approach is using 192.168.1.0/24 for the first pfSense VPN-client VM, 192.168.2.0/24 for the second, 192.168.3.0/24 for the third, and so on. It’s true that routing local resources through VirtualBox internal networks with distinct IP ranges would be difficult, but that’s less important than ensuring security through full isolation.

So jetzt wieder die Frage, wo ist der Hund begraben?

schonmal vielen vielen dank für die Hilfe

viragomann

Hallo!

Mal eine Gegenfrage: Wozu betreibt man diesen ganzen Aufwand eigentlich, wenn man kein schlechtes Gewissen hat??? Was bringt das?

OK, die VPN anonymisiert die Internetzugriffe in gewisser Weise. Ich denke aber, dass die VPN-Dienste auch gesetzlich angehalten sind die Nutzer-Daten für einige Zeit vor zuhalten, oder?
Und warum macht man das über eine Firewall VM. VPN kann ich ja auch direkt vom OS her aufbauen?

Zu deinem aktuellen Problem:
Dass die 2. VM keine Verbindung hat, sollte nicht allzu schwer zu beheben sein.

Was aus deiner Erklärung und Screenshots nicht klar hervorgeht, sind deine virtuellen internen Netze. Du benötigst für dein Vorhaben zumindest 2 getrennte interne Netze:

VNetz1: Damit verbindest du nur pfSense1/LAN und pfSense2/WAN
VNetz2: Das sichere Netz. Damit verbindest du dein Ubuntu und alles übrige

Ist das so sichergestellt? Dann müsste pfSense2 sein WAN-GW finden.

esschallert

schlechtes gewissen habe ich nicht, nur finde ich dieses Thema zwecks Anonymität sehr interessant.

Sichergestellt ist es eben nicht, weiß eben nicht genau was ich jetzt wo noch einrichten muss damit die Verbindung zustande kommt.

JeGr

Ich habe mich auch gerade gefragt wozu der Aufwand. Plus VPNs hintereinanderzukoppeln ist totaler Irrwitz. Auch von der Performance Seite her. Schön, wenn das alles virtuelle Maschinen sind auf einem kräftigen System, aber was da an (sinnloser) Performance auf der Strecke bleibt, ist schon enorm. Dazu kommt, dass die Pakete von der Ubuntu VM dann verschlüsselt und getunnelt werden in Pfs1, dann nochmals verschlüsselt und getunnelt in pfs2. Das alles wird um das arme IP Paket drumherum geschnürt. Das eh nur 1500 Byte (etwas weniger bei DSL) groß sein darf. Sprich die Payload sinkt, der Overhead steigt enorm und der Traffic muss in viele kleine Pakete zusammengeschlagen werden, was nochmals Latenz und Leistung kostet.

Als Lern/Test/Experimental-Projekt sicher ganz interessant, aber produktiv ein Albtraum.