OpenVPN-Paket

squib · 27 Nov 2009

Hallo,

seit nun mehr Tagen versuche ich OpenVPN auf FB 7170 zum laufen zu bringen - leider ohne Erfolg

Mein Vorhaben:
Ich möchte mit der FB eine VPN Verbindung zum meinem Server aufbauen und anschließend diese Verbindung meinen lokalen Rechnern (hinter der FB) zur Verfügung stellen.

PC (lokales Netz) --> FB mit VPN Verbindung (VPN Client, IP 10.9.0.6) --> Internet --> Server (VPN Server mit der IP 10.9.0.1)

Stand der Dinge:
Eigentlich sieht es nicht allzu schlecht aus.

1. Ich kann mit der FB eine Verbindung zum Server aufbauen und diesen auch von der FB aus anpingen (10.9.0.1).

2. Tun (10.9.0.6) auf der FB ist auch vom PC (zuhause) erreichbar

Problem
Leider kann ich mit meinen Rechnern im lokalen Netz (hinter der FritzBox) nicht den VPN Server 10.9.0.1 erreichen.

Ich habe leider keine Ahnung, was da schief läuft. Brauche ich noch weiter Routing-Reglen oder NAT? Über Hilfe würde ich mich sehr freuen

Zusatz Infos:

OpenVPN config

Code:

#  OpenVPN 2.1 Config, Fri Nov 27 10:42:51 CET 2009
proto udp
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
tls-client
ns-cert-type server
remote XXXXXXXXX 1194
nobind
pull
redirect-gateway
tun-mtu 1500
mssfix
verb 3
daemon
cipher DES-EDE3-CBC
comp-lzo
float
keepalive 10 120
resolv-retry infinite

Route

Code:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.9.0.5        *               255.255.255.255 UH    0      0        0 tun0
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
10.9.0.1        10.9.0.5        255.255.255.255 UGH   0      0        0 tun0
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
212.71.11.68    *               255.255.255.255 UH    2      0        0 dsl
192.168.2.0     *               255.255.255.0   U     0      0        0 lan
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl

Ifconfig

Code:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.9.0.6  P-t-P:10.9.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:15 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:900 (900.0 B)  TX bytes:982 (982.0 B)

RalfFriedl · 27 Nov 2009

Du schreibst oben von 10.9.0.6, unten steht aber 10.9.0.5.

Wenn ein Ping auf den einzelnen Strecken (Server <-> Box, Box <-> Pc) funktioniert, aber nicht auf der gesamten Strecke (Server <-> PC), dann liegt es meistens am Routing auf dem Server oder auf dem PC, wobei das Routing am PC vermutlich in Ordnung ist. Ansonsten käme noch das Forwarding auf der Box in Frage.

Wie sieht die Routing-Tabelle auf dem Server aus?

squib · 27 Nov 2009

Besten Dank für die schnelle Antwort.

Du schreibst oben von 10.9.0.6, unten steht aber 10.9.0.5.

10.9.0.6 ist die IP des TUN
10.9.0.5 ist das GW für das TUN (P-t-P:10.9.0.5 vgl . ifconfig)

Wenn ein Ping auf den einzelnen Strecken (Server <-> Box, Box <-> Pc) funktioniert, aber nicht auf der gesamten Strecke (Server <-> PC), dann liegt es meistens am Routing auf dem Server oder auf dem PC, wobei das Routing am PC vermutlich in Ordnung ist.

Ich glaube eher, dass das Routing auf der Box das Problem ist "traceroute 10.9.0.1" zeigt, dass es nach der FB (192.168.2.1) nicht mehr weitergeht.

Ansonsten käme noch das Forwarding auf der Box in Frage.

Ich habe folgende Regel in der FB eingetragen: "udp 0.0.0.0:1194 0.0.0.0:1194"

Wie sieht die Routing-Tabelle auf dem Server aus?

Code:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.0.2.1       *               255.255.255.255 UH    0      0        0 venet0
10.9.0.2        *               255.255.255.255 UH    0      0        0 tun0
10.9.0.0        10.9.0.2        255.255.255.0   UG    0      0        0 tun0
default         192.0.2.1       0.0.0.0         UG    0      0        0 venet0

RalfFriedl · 27 Nov 2009

squib schrieb:
10.9.0.6 ist die IP des TUN
10.9.0.5 ist das GW für das TUN (P-t-P:10.9.0.5 vgl . ifconfig)

Was hast Du denn noch alles für Adressen? 10.9.0.1, 10.9.0.2, 10.9.0.5, 10.9.0.6 ?
Dem Server sagst Du also, Server ist 10.9.0.1 und Box ist 10.9.0.2.
Der Box sagst Du, Server ist 10.9.0.5 und Box ist 10.9.0.6.
Ein Wunder, daß es überhaupt funktioniert.

Ich glaube eher, dass das Routing auf der Box das Problem ist "traceroute 10.9.0.1" zeigt, dass es nach der FB (192.168.2.1) nicht mehr weitergeht.

Wenn Du es besser weißt, warum fragst Du dann?
Das Routing auf der Box funktioniert, sonst könnte sie nicht beide Ziele anpingen. Mach Dir mal Gedanken darüber, was Routing bedeutet, und wie die Ausgabe von traceroute wäre, wen ausschließlich die Verbindung vom Server zum PC nicht funktionieren würde.

Ich habe folgende Regel in der FB eingetragen: "udp 0.0.0.0:1194 0.0.0.0:1194"

Das Forwardung auf der Box habe ich nur der Vollständigkeit halber erwähnt. Die Regel mag notwendig sein, damit OpenVPN überhaupt funktioniert, hat aber nichts mit dem Forwarding auf der Box zu tun.

Code:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.0.2.1       *               255.255.255.255 UH    0      0        0 venet0
10.9.0.2        *               255.255.255.255 UH    0      0        0 tun0
10.9.0.0        10.9.0.2        255.255.255.0   UG    0      0        0 tun0
default         192.0.2.1       0.0.0.0         UG    0      0        0 venet0

Ist 192.0.2.1 ernsthaft die öffentliche IP-Adresse des Servers?
Ich gehe mal davon aus, daß Dein PC eine Adresse in der Form 192.168.2.x hat, mit x größer als 1. Was sollte pasieren, wenn Du vom Server aus diese Adresse anpingst? Was sollte passieren, wenn Du vom Server die Adresse 192.168.2.1 anpingst (ich gehe mal davon aus, daß das die Adresse Deiner Box ist).
Was passiert tatsächlich, wenn Du es mit diesen beiden Adressen versuchst?

squib · 27 Nov 2009

Zu den IPs
Ja, ich gebe zu die IP sind ein wenig verwirrend - aber das wird vom OpenVPN Server gemacht. Im wesentlichen bekommt jeder Rechner eine eigene IP und ein eigenes Gateway (Rechner IP -1).

Ist 192.0.2.1 ernsthaft die öffentliche IP-Adresse des Servers?

Nein, dies ist nicht seine öffentliche IP. Es ahndelt sich um ein Virtual Server und der Provider übersetzt die lokale Adresse (192.0.2.1) später in die öffentliche Adresse (irgendwas in der Art 212.133.xxx.xxx)

Problem

Ich versuche mein Problem mal vollständig zu beschreiben. Ich möchte gerne einige IP-Adressen/Webseiten über meinen VPN-Server ansprechen (da einige Webseiten/Dienste ortsgebunden sind).

Bisher habe auf jedem Rechner in meinem Netz zuhause den openvpn Client installiert und jedesmal eine Verbindung zum Server aufgebaut - das funktioniert auch alles wunderbar.

Nun hatte ich gedacht nutze ich mein Fritzbox, um das zentrall zu machen (Vorteile keine Software auf den Rechner zuhause nötig und kein neu Aufbau der Verbindung nach jedem Neustart der Rechner).

Warum ich denke das mein Problem bei der FB liegt.

VPN-Verbingung (FB - Server) - geht und ich kann direkt auf der FB die Webseiten durch den VPN-Server ansprechen.

Also sollte die FB jetzt nur noch per Routing bestimmte IP-Bereiche über den VPN-Server schicken - das funktioniert aber leider nicht.

Der Rechner im Netz zuhause (hinter der FB) kann weder den VPN-Server noch irgend eine Webseite, die ich duch den VPN-Server ansprechen möchte erreichen.

Routingtabelle (vom Server gepush):

Code:

212.58.0.0      10.9.0.5        255.255.0.0     UG    0      0        0 tun0

Sorry, für den langen Text aber ich konnte mein Problem leider nicht kürzer darstellen.

cando · 27 Nov 2009

Das hängt ja wohl auch vom Tunnel ab, ob du eine Netz zu Netz Kopplung oder Host zu Netz Kopplung machst.

Im 2. Fall bekommtst Du eine einzige IP Adresse zugewiesen und kein ganzes LAN Segment. Folglich musst Du (wenn es nicht anders geht) auf diese Adresse NAT-en. Dein Gegenüber weiss ja nichts von den LAN Segmenten Deiner Fritz Box, und dass er den Traffic dafür durch den Tunnel schicken muss. Das Routing muss auf beiden Seiten richtig eingestellt sein, damit es funktioniert

RalfFriedl · 27 Nov 2009

squib schrieb:
VPN-Verbingung (FB - Server) - geht und ich kann direkt auf der FB die Webseiten durch den VPN-Server ansprechen.

Also sollte die FB jetzt nur noch per Routing bestimmte IP-Bereiche über den VPN-Server schicken - das funktioniert aber leider nicht.

Ich habe noch immer nichts gesehen, was diese Vermutung untermauert. Ich bleibe bei meiner Vermutung, daß die Box durchaus die Pakete zum Server routet.

Du bist leider nicht auf die von mir gestellten Fragen eingegangen. Ich vermute, sie würden Deinem Verständnis der Problematik helfen, und damit letztlich auch der Lösung des Problems.

cando · 27 Nov 2009

Ich denke ja auch , dass das Routing auf der Fritz Box damit nichts zutun hat, sondern das Routing auf der anderen Seite des Tunnels....

squib · 27 Nov 2009

Besten Dank für deine Antwort cando,

Du hast recht, vielleicht ist NAT/IP masqurading der einzig Ausweg ist. Aber wie kann ich das auf der Fritzbox machen?

PS:
Was mich wundert, ich hatte im Netz niemanden gefunden, der etwas ähnliches wie ich vor hatte (VPN per FB anstatt auf meheren Rechnern).

cando · 27 Nov 2009

Die Frage ist ja, inwieweit Du das Routing auf der Gegenseite beeinflussen kannst. Wenn der Rechner auch Dir gehört, dann kannst Du es ja einstellen und gut ist. Wenn nicht, ist NAT der letzte Ausweg.

Hierfür gibts z.B. iptables. Ich glaube nicht, dass Du den dsld von AVM zu einem weiteren NAT ohne weiteres überreden kannst...

MaxMuster · 27 Nov 2009

Wenn ich das richtig interpretiere, hast du den VPN-Server "unter deiner Gewalt" oder könntest da zumindest die Config ändern ("...über meinen VPN-Server...")?

Dann ist das kein Problem und NAT ist unnötig.

In die Server-Config zusätzlich ein "route 192.168.2.0 255.255.255.0" und das wars, der Server weiß, wo die PCs sind, nämlich "hinter" der VPN-Client, deiner Box ;-)

Jörg

sf3978 · 27 Nov 2009

cando schrieb:
[...]Ich glaube nicht, dass Du den dsld von AVM zu einem weiteren NAT ohne weiteres überreden kannst...

Doch, das funktioniert:

iptables -t nat -I POSTROUTING 2 -s 169.254.2.1 -d 192.168.158.1 -o dsl -j SNAT --to-source 192.168.148.1

MaxMuster · 27 Nov 2009

... naja, die NAT ist dann aber nicht vom dsld gemacht, sondern vom iptables ;-)

cando · 27 Nov 2009

bei iptables schon, nicht aber beim dsld (avm firewall)...

Hab ich doch geschrieben, oder?

sf3978 · 27 Nov 2009

MaxMuster schrieb:
... [...], sondern vom iptables ;-)

Ja, ich habe hier (klick) schon geschrieben, dass es mit iptables geht.;-)

squib schrieb:
[...]
, der etwas ähnliches wie ich vor hatte (VPN per FB anstatt auf meheren Rechnern).

Hier Auszüge aus den Konfig-Dateien betr. VPN zwischen 2 FritzBoxen:

Client:

...
up {
ifconfig "%% 10.7.0.2 pointopoint 10.7.0.1";
route "add -net 192.168.128.0 netmask 255.255.255.0 gw 10.7.0.1";
};
down {
ifconfig "%% down";
route "del -net 192.168.128.0 netmask 255.255.255.0 gw 10.7.0.1";
};

Server:

...
up {
ifconfig "%% 10.7.0.1 pointopoint 10.7.0.2";
route "add -net 192.168.118.0 netmask 255.255.255.0 gw 10.7.0.2";
firewall "-t nat -A POSTROUTING -o %% -j MASQUERADE";
};
down {
ifconfig "%% down";
route "del -net 192.168.118.0 netmask 255.255.255.0 gw 10.7.0.2";
firewall "-t nat -D POSTROUTING -o %% -j MASQUERADE";
};

cando · 27 Nov 2009

~~OK, dann ist die AVM-Firewall GUI noch erweiterungsfähig...;-)~~

~~Da gibts nämlich nichts mit~~

Code:

firewall -t nat -A POSTROUTING -o %% -j MASQUERADE

EDIT, Sorry, das war gar nicht die AVM-VPN, sondern Deine iptables Lösung....

sf3978 · 27 Nov 2009

cando schrieb:
OK, dann ist die AVM-Firewall GUI noch erweiterungsfähig...;-)

Nein, bitte nicht. Warum nur für alles eine GUI?;-)

EDIT:
Mein 1. Beitrag in diesem Thread ist für AVM-VPN und mein 2. Beitrag ist für VTUN zwischen 2 FritzBoxen. Aber VPN bleibt VPN, egal ob AVM-VPN, OpenVPN oder VTUN.;-)

MaxMuster · 27 Nov 2009

Ich würde immer noch raten, das ganze ohne NAT zu machen, wenn es geht. Falls man die von
sf3978 genannte Lösung von Start- und Stop-Skripten nutzen will, bitte das "--script-security 2" beim Openvpn nicht vergessen, sonst klappt das nicht (mehr) mit dem Scriptaufruf.

Jörg

RalfFriedl · 27 Nov 2009

MaxMuster schrieb:
In die Server-Config zusätzlich ein "route 192.168.2.0 255.255.255.0" und das wars

Ja, aber squib weigert sich beharrlich, einzusehen, daß das der wahrscheinlichste Fehler und die einfachste Lösung ist. Lieber will er es mit NAT versuchen.

squib · 28 Nov 2009

Ja, aber squib weigert sich beharrlich, einzusehen, daß das der wahrscheinlichste Fehler und die einfachste Lösung ist. Lieber will er es mit NAT versuchen.

So langsam schwindet mein Wiederstand

Eine Lösung ohne NAT wäre mir so wieso viel lieber.

Ich bin euren Ratschlägen gefolgt und habe eine neue Route (192.168.2.0) auf dem Server eingefügt - leider ohne Erfolg.
(Ich kann vom Server aus nicht meine 192.168.2.XXX Rechner anpingen (mein VPN-Tunnel es Clients 10.9.0.6 geht wunderbar))

Meine routing Tabelle sieht jetzt wie folgt aus:

Code:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.0.2.1       *               255.255.255.255 UH    0      0        0 venet0
10.9.0.2        *               255.255.255.255 UH    0      0        0 tun0
192.168.2.0     10.9.0.2        255.255.255.0   UG    0      0        0 tun0
10.9.0.0        10.9.0.2        255.255.255.0   UG    0      0        0 tun0
default         192.0.2.1       0.0.0.0         UG    0      0        0 venet0

Hab ich schon wieder ein Denkfehler gemacht?

OpenVPN-Paket

Neuer User

Anhänge

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

Neuer User

Aktives Mitglied

IPPF-Promi

IPPF-Promi

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

IPPF-Promi

IPPF-Urgestein

Neuer User

Statistik des Forums