OpenVPN als Gateway

[Peter1]

Hallo zusammen,

also mein VPN Server läuft soweit (feste IP, da gemieteter Server) und ich kann mich auch verbinden (von Client hinter Router). Leider kann ich ihn nicht als Gateway nutzen.

Meine configs:

server:

local [IP]

port 51261

proto udp

dev tun844-33

tls-server

mode server

ca /etc/openvpn/examples/easy-rsa/2.0/keys/ca.crt

cert /etc/openvpn/examples/easy-rsa/2.0/keys/server.crt

key /etc/openvpn/examples/easy-rsa/2.0/keys/server.key

dh /etc/openvpn/examples/easy-rsa/2.0/keys/dh1024.pem

push "redirect-gateway def1"

push "dhcp-option DNS [DNS IP]"

push "dhcp-option DNS [DNS IP]"

comp-lzo

keepalive 10 60

ping-timer-rem

persist-tun

persist-key

client:

client

dev tun

proto udp

remote [IP]

resolv-retry infinite

nobind

persist-key

persist-tun

ca ca.crt

cert client.crt

key client.key

ns-cert-type server

comp-lzo

verb 3

ifconfig 10.0.0.2 10.0.0.1

resolv-retry infinite

route-method exe

route-delay 2

Leider komme ich nicht ins Internet.

Danke...

Gruße:-)

Peter

[Peter1]

Folgende Information wollte ich noch hinzufügen: Ich kann den Server nicht pingen und ich weiß auch nicht so ganz genau welche Adresse (VPN) er hat, weil die Konfiguration nur dem Provider obliegt und ich die Adresse nicht mit "server ..." festlgen kann.

Ok...folgende Frage: Wenn ich auf dem Server "Ifconfig" nutze, dann stehen bei dem TUN-Dev folgende IPs: inet: 10.0.0.125 und p-t-p: 10.0.0.126. Ich bin jetzt mal davon ausgegangen, dass 10.0.0.125 seine IP im VPN ist. Deshalb habe ich die letzte Zeile in der client.conf umgeändert zu "ifconfig 10.0.0.2 10.0.0.125".

Daraufhin kann ich mich aber nicht mehr mit dem Server verbinden. Der Client gibt folgende Fehlermeldung: "There is a problem in your selection --ifconfig endpoints. The local and remote VPN endpoints must exist within the same 255.255.255.252 subnet. This is a limitation of --dev tun when used the TAP-WIN32 driver. Try "openvpn --show-valid-subnets" option for more info."

Heißt das jetzt, dass die lokale VPN-IP des Servers doch 10.0.0.1 ist? Wie kommt die Netzmaske zustande? Eigentlich sind sie ja im selben Netz, da die Netzmaske zwei Benutzer erlaubt!? Wo soll ich "openvpn --show-valid-subnets" ausprobieren?

Ich danke für die Unterstützung:-)

Gruß

Peter

[Crash2001]

[...]Heißt das jetzt, dass die lokale VPN-IP des Servers doch 10.0.0.1 ist? Wie kommt die Netzmaske zustande? Eigentlich sind sie ja im selben Netz, da die Netzmaske zwei Benutzer erlaubt!? Wo soll ich "openvpn --show-valid-subnets" ausprobieren?[...]

Ich denke einmal, damit ist unter der Console gemeint.

[Peter1]

OK...das Problem war, dass die IPs (remot und local bei ifconfig) nebeneinander liegen müssen.

Ich habe deshalb folgende Sachen in der client.conf ausprobiert:

ifconfig 10.0.0.125 10.0.0.126

ifconfig 10.0.0.126 10.0.0.125

Ich konnte die Verbindung mit den obigen Einstellungen zwar herstellen (Monitore auf Grün), aber beides brachte leider keinen Erfolg in der Sache. Kann die lokale VPN-IP des Servers nicht anpingen (wobei ich immer noch nicht weiß, ob es die richtige ist) und als Gateway kann ich ihn auch nicht nutzen.

Kann es am Router liegen hinter dem der Client liegt?

[Peter1]

Im Übrigen kommt, wenn ich mit dem Server verbunden bin und eine Anfrage starte, z.B. www.irgendEineSeite.de, dauernd die Meldung am Server:

" client2/[öffentliche IP]:57491 Need IPv6 code in mroute_extract_addr_from_packet"

[Peter1]

Wenn ich verbunden bin (Client) und mir den Status bei dem TUN-Device anschaue (unter Windows), dann sehe ich, dass das Feld hinter Gateway leer ist. Müsste da nicht was drinne stehen?

[Peter1]

Ich habe mal das geplante Netz aufgezeichnet und angehangen. Eine direkte Verbindung zwischen beiden Netzen ohne Server ist nicht möglich. Mir würde es zunächst ausreichen von client1 aus den VPN Server als Gateway zu nutzen.

Nochmals danke für die Hilfe.

Netzwerk.pdf

[Peter1]

Hier mal noch die Ausgabe von "ifconfig":

tun844-33 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

inet addr:10.0.0.125 P-t-P:10.0.0.126 Mask:255.255.255.255

UP POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:100

RX bytes:0 (0.0 TX bytes:0 (0.0

[Peter1]

Hat keiner eine Idee oder einen Ansatz?

[Crash2001]

Im Übrigen kommt, wenn ich mit dem Server verbunden bin und eine Anfrage starte, z.B. www.irgendEineSeite.de, dauernd die Meldung am Server:

" client2/[öffentliche IP]:57491 Need IPv6 code in mroute_extract_addr_from_packet"

Hmmm... wird bei dir IPV6 geroutet auf der Linux-Kiste? Bzw. hast du eine IPV6-Adresse auf deinem Server? Das könnte das Problem sein.

Wenn ich verbunden bin (Client) und mir den Status bei dem TUN-Device anschaue (unter Windows), dann sehe ich, dass das Feld hinter Gateway leer ist. Müsste da nicht was drinne stehen?

Hast du denn bei der Konfiguration eingetragen, dass es das GAteway sein soll? Wenn nicht, wirds auch nicht als Gateway eingetragen. Ansonsten aknnst du dir natürlich auch noch immer eine statische Nullroute einrichten, so dass alles, was nciht direkt verbunden ist, dann darüber geroutet ist. Dafür muss aber das Routing auf der Linux-Kiste richtig aktiviert sein und es muss eine Rückroute zu deinem Rechner geben.

[Peter1]

Kann gut sein, dass der Server IPv6 unterstützt. Mit welchen Befehlen kann ich herausfinden, ob IPv6 geroutet wird? Und wenn ja, wie könnte ich das Problem lösen?

Bei der Config bin ich jetzt soweit, dass das Gateway mit eingetragen wird, aber das Problem besteht weiterhin.

Vielen Dank:-)

[Peter1]

Also ich habe nochmal nachgeschaut...es wird kein IPv6 vom Provider unterstützt. Gut...das muss jetzt natürlich nicht heißen, dass irgendwas in den Einstellungen nicht stimmt.

[Crash2001]

Ein Provider der kein IPV6 unterstützt?!? :eek:

Sehr zukunftsträchtig...

Also kriegst du das Gateway beim Client eingetragen jetzt?

Routing auf dem Server richtig konfiguriert? Falls ja, solltest du auch raus kommen...

[Peter1]

IPv6 wird erst ab nächsten Jahr unterstützt;-)

Ja das Gateway klappt. Das Ding ist halt, dass ich die VPN-IP des Servers nicht manipulieren kann, d.h. ich bin mir nicht sicher, ob 10.0.0.125 überhaupt mein server ist. Ein ping funkioniert jedenfalls nicht. Sollte ich vielleicht mal alle 254 IPs durchpingen?

Ich habe mal den Haken bei IPv6 (Windows client; eigenschaften tap/tun device) herausgenommen. Jetzt ist die Fehlermeldung weg und es kommt:

"MULTI: bad source address from client [10.0.0.126], packet dropped"

Bzgl. Routing: Ich habe keine Routen in meiner Server-Config eingetragen (s. oben). Was müsste da u.U. rein?

[Crash2001]

Hmmm... also welche IP das Tunnelinterface deines Servers hat, solltest du ja wohl problemlos per "ipconfig [tunnelinterfacename]" herausfinden können.

Wenn du auf dem Server routing prinzipiell aktiviert hast, sollte eigentlich automatisch ein Routing zwischen dem Tunnelinterface und der öffentlichen IP Adresse deines Servers stattfinden.

Lies dir diesen Artikel mal durch.

Du brauchst das Forwarding / Routing, DNS und Masquereading evtl auch noch. Wenn das alles läuft, sollte eigentlich auch das surfen über den V-Server als Gateway gehen.

[Peter1]

Hmmm... also welche IP das Tunnelinterface deines Servers hat, solltest du ja wohl problemlos per "ipconfig [tunnelinterfacename]" herausfinden können.

Joa...das habe ich mir auch gedacht. Die Ausgabe von "ifconfig" habe ich ja oben schon geschrieben. Da steht 10.0.0.125. Leider kann ich die IP nicht pingen. Ich habe jetzt mal spaßeshalber das ganze Netz durchgepingt. Leider auch ohne Erfolg. Die einzige IP, die reagiert ist 10.0.0.126, also die IP des Clientes, was ja kein wunder ist.

Danke für den Link. Schau ich mir gleich mal an:-)

[Crash2001]

Nunja, da du eine Mask von 255.255.255.255 hast, kann dir auch niemand darauf antworten, da dies eine Hostmaske ist und genau 1 IP-Adresse in der Range der Subnet-Mask liegt.

Evtl musst du die doch noch anpassen. Sollte eigentlich aber auch mit der /32 Subnet mask gehen.

[Peter1]

Also am tun device lässt sich nichts ändern. Subnetzmaske ist fest. Ich habe mal mit "lsmod" geschaut welche Module geladen sind:

Module Size Used by

tun 12939 2

sch_htb 12456 1

scsi_transport_iscsi 24728 1

xt_tcpudp 2263 1

nf_conntrack_ipv4 9395 2

nf_defrag_ipv4 1195 1 nf_conntrack_ipv4

xt_state 1183 2

nf_conntrack 46263 2 nf_conntrack_ipv4,xt_state

xt_multiport 1598 1

iptable_filter 1200 1

ip_tables 13520 1 iptable_filter

x_tables 13988 5 xt_tcpudp,xt_state,xt_multiport,iptable_filter,ip_tables

dm_mod 56212 89

i2c_i801 7294 0

i2c_core 14887 1 i2c_i801

i5000_edac 7244 0

edac_core 29907 3 i5000_edac

ioatdma 32206 20

serio_raw 3888 0

container 2429 0

dca 4337 1 ioatdma

rng_core 3118 0

tpm_tis 7072 0

tpm 9509 1 tpm_tis

tpm_bios 4657 1 tpm

i5k_amb 4351 0

button 4754 0

processor 19944 0

sd_mod 23690 10

ahci 19441 8

libahci 16034 1 ahci

e1000e 116581 0

libata 135522 2 ahci,libahci

scsi_mod 154723 3 scsi_transport_iscsi,sd_mod,libata

uhci_hcd 18204 0

ehci_hcd 31868 0

thermal 11890 0

fan 3226 0

thermal_sys 12070 3 processor,thermal,fan

Nix zu sehen von "masquereade". Kann es daran liegen?

[Crash2001]

Ich bin grad am überlegen, wie das normal gemacht wird.

Wenn man einen VPN Software Client installiert, nimmt dieser ja normal die eigene VPN IP Adresse (auch mit einer /32 Subnet Mask) als Gateway IP Adresse. Probier das mal aus, ob es dann geht.

[Peter1]

Also die Subnetz Maske der Clients ist 255.255.255.252. Ich probier mal die /32 Subnetzmaske aus.

[Peter1]

Mh ich komme nicht weiter. Ich wollte nunmal überprüfen, ob eventuell eine Firewall blockiert wegen "MULTI: bad source address from client [10.0.0.126], packet dropped". Ich selbst habe zwar nichts konfiguriert, um dies als Fehlerquelle auszuschließen, aber eventuell ist ja bereits einiges vorkonfiguriert. Leider funktioniert "iptables" nicht (command not found). Das Modul ist aber geladen (siehe oben). An was kann das liegen?

[unclesamwk]

Gibt es hier schon weiter Erkenntnisse?