Freetz als OpenVPN-Client um allen Geräten "VPN" Zugang zu ermöglichen

qupfer

Neuer User
Mitglied seit
30 Dez 2009
Beiträge
44
Punkte für Reaktionen
0
Punkte
0
Boah ist das schwer sich eine vernünftige Überschrift einfallen zu lassen.

In unseren Wohnheim ist UDP-Traffic gesperrt, so das ich gelegentlich eine VPN verbindung nutze. (Openvpn auf einen billigen vServer)
Server-config:
Code:
dev tap
proto tcp-server
tls-server
ca /etc/openvpn/keys/ca.crt
key /etc/openvpn/keys/server.key
cert /etc/openvpn/keys/server.crt
dh /etc/openvpn/keys/dh1024.pem
client-to-client
port 1194
#push "dhcp-option DNS 8.8.8.8"
server 192.168.42.0 255.255.255.0
push "redirect-gateway def1"
keepalive 10 60
comp-lzo

Ich brächte jetzt Ideen oder noch besser Beispielkonfigurationen wie ich die Freetz-Openvpn-Konfig einstellen muss, damit alle an ihr hängenden Geräte ihren Traffic über den Tunnel schicken und auch die Antworten wieder erhalten.
Ich vermute mal, dass wird also auf eine art "Doppel-Nat" hinaus laufen, 1x der OpenVPN-server wie bisher auch und dann nochmal die FritzBox.

Tips, Hinweise, Tutorials?
Danke
 
doppel-nat ist haesslich. ein "route" und "iroute" sollte reichen, um den traffic in den tunnel zu bekommen.
 
ich wuerde "mode tun" bevorzugen. mit tap gibt es instabilitaeten, wenn deine box auch wlan hat.
wenn du unbedingt tap verwenden willst, dann sollte dein vserver anpingbar sein, richtig?
 
Anhang anzeigen 66870
ich wuerde "mode tun" bevorzugen. mit tap gibt es instabilitaeten, wenn deine box auch wlan hat.
wenn du unbedingt tap verwenden willst, dann sollte dein vserver anpingbar sein, richtig?

Ich muss nicht unbedingt TAP nehmen, aber mit TAP lief halt gerade der Server. Aber ich habe mir jetzt auch eine "tun" config gebastelt, die mit meinen PC als Client gut funktioniert. Aber ich bekomme die FritzBox nicht verbunden. Ich habe es sogar schon hinbekommen, dass ich ein "Initialization Sequence Completed" erhalte, aber dennoch Funktioniert der Tunnel nicht bzw. bricht danach wieder zusammen

Code:
root@fritz:/var/mod/root# cat /var/tmp/debug_openvpn.out
Mon Dec  3 23:59:59 2012 OpenVPN 2.2.2 mipsel-linux [SSL] [LZO2] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Dec  3 2012
Mon Dec  3 23:59:59 2012 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Mon Dec  3 23:59:59 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Dec  3 23:59:59 2012 LZO compression initialized
Mon Dec  3 23:59:59 2012 Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
Mon Dec  3 23:59:59 2012 Socket Buffers: R=[87380->131072] S=[16384->131072]
Mon Dec  3 23:59:59 2012 TUN/TAP device tun0 opened
Mon Dec  3 23:59:59 2012 TUN/TAP TX queue length set to 100
Mon Dec  3 23:59:59 2012 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Dec  3 23:59:59 2012 /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.1 mtu 1500
Mon Dec  3 23:59:59 2012 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Dec  3 23:59:59 2012 chroot to '/tmp/openvpn' and cd to '/' succeeded
Mon Dec  3 23:59:59 2012 GID set to openvpn
Mon Dec  3 23:59:59 2012 UID set to openvpn
Mon Dec  3 23:59:59 2012 Attempting to establish TCP connection with [AF_INET]82.211.xxxxxx:1195 [nonblock]
Tue Dec  4 00:00:01 2012 TCP connection established with [AF_INET]82.211.xxxxx:1195
Tue Dec  4 00:00:01 2012 TCPv4_CLIENT link local: [undef]
Tue Dec  4 00:00:01 2012 TCPv4_CLIENT link remote: [AF_INET]82.211.xxxxx:1195
Tue Dec  4 00:00:01 2012 TLS: Initial packet from [AF_INET]82.211.xxxxx:1195, sid=f9eb8d9f 4dd25213
Tue Dec  4 00:00:01 2012 VERIFY OK: depth=1, /C=DE/ST=TH/L=Ilmenau/O=none/OU=none/CN=server/name=Henning/[email protected]
Tue Dec  4 00:00:01 2012 VERIFY OK: depth=0, /C=DE/ST=TH/L=Ilmenau/O=none/OU=none/CN=server/name=Henning/[email protected]
Tue Dec  4 00:00:02 2012 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Tue Dec  4 00:00:02 2012 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec  4 00:00:02 2012 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Tue Dec  4 00:00:02 2012 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec  4 00:00:02 2012 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Dec  4 00:00:02 2012 [server] Peer Connection Initiated with [AF_INET]82.211xxxxx:1195
Tue Dec  4 00:00:03 2012 Initialization Sequence Completed
Tue Dec  4 00:00:12 2012 Authenticate/Decrypt packet error: cipher final failed
Tue Dec  4 00:00:12 2012 Fatal decryption error (process_incoming_link), restarting
Tue Dec  4 00:00:12 2012 TCP/UDP: Closing socket
Tue Dec  4 00:00:12 2012 SIGUSR1[soft,decryption-error] received, process restarting
Tue Dec  4 00:00:12 2012 Restart pause, 5 second(s)


Die Server-Conf sieht im Moment so aus:
Code:
port 1195
proto tcp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key  # This file should be kept secret
dh /etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp_tun.txt
client-to-client
keepalive 10 120
user openvpn
group openvpn
persist-key
persist-tun
status openvpn-status.log
log         /var/log/openvpn_tun.log
verb 3

Und auf der box habe ich folgendes zusammen geklickt: (siehe Bildanhang)
 

Anhänge

  • Screenshot+on+12.4.2012+at+12.09.49+AM.png
    Screenshot+on+12.4.2012+at+12.09.49+AM.png
    52.8 KB · Aufrufe: 39
Zuletzt bearbeitet:
dein server will bf-cbc (standard), dein client aes-256-cbc. stell deinen server auch mal auf "topology subnet" um.
 
Danke, habe zwar cipher AES-256-CBC mit in den Server geschrieben, hat aber genauso geholfen. Jetzt funktioniert der Tunnel scheinbar, zumind kann ich den Server über die VPN IP anpingen. *freu*

Nun kommt aber mein größtes "Problem". Wie bekomme ich es hin, dass die hitner der FB hängenden Geräte über das VPN ihr Internet bekommen? Habe den Haken bei "Clientverkehr umleiten" gesetzt und als aller ersten Versuch bei Entferntes Netz "192.168.42.0 255.255.255.0" eingetragen, in der Hoffnung dass dann meine Gerätschaften schonmal zugriff auf den "Server" bekommen. Aber ohne Erfolg, verschwinden im nirgendwo. Eventuell blockiert die FB da auch noch was? Oder wie muss ich das machen?


Edit: langsam mache ich fortschritte ;)
Wenn ich manuell ein route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.42.1 ausführe, kann ich von der FritzBox aus übers VPN surfen.Zumind. gibt ein traceroute als ersten Hop den Provider des Servers an und nicht meinen ;)
Die Clienten dahinter fühlen sich von der Route aber nur bedingt beeindruckt und funktionieren dann garnicht mehr....vermutlich fehlt die Antwort. Muss ich da der FB noch irgendwie SNAT/MASQUERADE oder ähnliches beibringen? Weil die das nur fürs "dsl" Device und nicht fürs tun0 Device macht?
 
Zuletzt bearbeitet:
in der gui keine ip und keine route angeben. "optionen empfangen" anhaken. (damit wird auch "clientverkehr umleiten" mitgepushed, somit wird der haken in der gui ueberfluessig).
beim server "route 192.168.42.0/24" und "client-config-dir ccd" angeben. in ccd/<cn_der_fb> "iroute 192.168.42.0/24" angeben.
 
Danke für deine Gedult, ich befürchte ich werde die aber noch weiter strapazieren müssen, denn noch stell ich mich zu blöd an.

Aktuell aus dem log
Code:
Tue Dec  4 02:28:43 2012 OpenVPN 2.2.2 mipsel-linux [SSL] [LZO2] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Dec  3 2012
Tue Dec  4 02:28:43 2012 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Tue Dec  4 02:28:43 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Dec  4 02:28:43 2012 LZO compression initialized
Tue Dec  4 02:28:43 2012 Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
Tue Dec  4 02:28:43 2012 Socket Buffers: R=[87380->131072] S=[16384->131072]
Tue Dec  4 02:28:43 2012 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Dec  4 02:28:43 2012 NOTE: chroot will be delayed because of --client, --pull, or --up-delay
Tue Dec  4 02:28:43 2012 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Tue Dec  4 02:28:43 2012 Attempting to establish TCP connection with [AF_INET]82.211.56.146:1195 [nonblock]
Tue Dec  4 02:28:44 2012 TCP connection established with [AF_INET]82.211.56.146:1195
Tue Dec  4 02:28:44 2012 TCPv4_CLIENT link local: [undef]
Tue Dec  4 02:28:44 2012 TCPv4_CLIENT link remote: [AF_INET]82.211.56.146:1195
Tue Dec  4 02:28:44 2012 TLS: Initial packet from [AF_INET]82.211.56.146:1195, sid=54ee3cb4 fea55c97
Tue Dec  4 02:28:44 2012 VERIFY OK: depth=1, /C=DE/ST=TH/L=Ilmenau/O=none/OU=none/CN=server/name=Henning/[email protected]
Tue Dec  4 02:28:44 2012 VERIFY OK: depth=0, /C=DE/ST=TH/L=Ilmenau/O=none/OU=none/CN=server/name=Henning/[email protected]
Tue Dec  4 02:28:45 2012 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Dec  4 02:28:45 2012 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec  4 02:28:45 2012 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Dec  4 02:28:45 2012 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec  4 02:28:45 2012 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Dec  4 02:28:45 2012 [server] Peer Connection Initiated with [AF_INET]82.211.56.146:1195
Tue Dec  4 02:28:47 2012 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Tue Dec  4 02:28:47 2012 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway,route-gateway 192.168.42.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.42.2 255.255.255.0'
Tue Dec  4 02:28:47 2012 OPTIONS IMPORT: timers and/or timeouts modified
Tue Dec  4 02:28:47 2012 OPTIONS IMPORT: --ifconfig/up options modified
Tue Dec  4 02:28:47 2012 OPTIONS IMPORT: route options modified
Tue Dec  4 02:28:47 2012 OPTIONS IMPORT: route-related options modified
Tue Dec  4 02:28:47 2012 TUN/TAP device tun0 opened
Tue Dec  4 02:28:47 2012 TUN/TAP TX queue length set to 100
Tue Dec  4 02:28:47 2012 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Dec  4 02:28:47 2012 /sbin/ifconfig tun0 192.168.42.2 netmask 255.255.255.0 mtu 1500 broadcast 192.168.42.255
Tue Dec  4 02:28:47 2012 NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Tue Dec  4 02:28:47 2012 chroot to '/tmp/openvpn' and cd to '/' succeeded
Tue Dec  4 02:28:47 2012 GID set to openvpn
Tue Dec  4 02:28:47 2012 UID set to openvpn
Tue Dec  4 02:28:47 2012 Initialization Sequence Completed

Der server ist mitlerweile:
Code:
route 192.168.42.0/24
client-config-dir ccd
port 1195
topology subnet
proto tcp
dev tun
ca /etc/openvpn/easy-rsa2/keys/ca.crt
cert /etc/openvpn/easy-rsa2/keys/server.crt
key /etc/openvpn/easy-rsa2/keys/server.key  # This file should be kept secret
dh /etc/openvpn/easy-rsa2/keys/dh1024.pem
server 192.168.42.0 255.255.255.0
ifconfig-pool-persist ipp_tun.txt
push "redirect-gateway"
client-to-client
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status openvpn-status.log
log         /var/log/openvpn_tun.log
;log-append  openvpn.log
verb 3

Und Client, also freetz:
Entferntes Netz: leer
Clientverkehr umleiten (wenn richtig verstanden, "umsonst" aktiviert
Optionen vom Server empfangen (nur mit Zertifikaten): aktiv
auch IP-Adresse vom Server empfangen: aktiv

In /etc/openvpn/ccd liegt eine Datei midgard mit den Inhalt "iroute 192.168.42.0/24"

Manulles setzen der Route mit route add -net 0.0.0.0/1 dev tun0 brauchte auch kein Erfolg. Danach sind alle angeschlossenen Geräte das Internet los ;)
 
Zuletzt bearbeitet:
wieso nimmst du n 2.0 template fuern openvpn 2.2?
nimm das alte file, das ist uebersichtlicher!
wenn dein lokales netz 192.168.42.0/24 ist, dann kannst du es selbstverstaendlich nicht als tunnelnetz verwenden.
wie sieht die routingtabellen auf dem server und fb aus?
 
Zuletzt bearbeitet:
weil ichs vorhin der Überischt nur zusammen gekürzt hatte, hatte dies schon die ganze Zeit. Aber nun "angst" ungewollte ne entscheidende Zeile raus zu kürzen. Aber gut, werde ich bei gelegenheit kürzen. (Edit: oben angepasst)

Um überhaupt mal die ganzen Netzte auf zu drußeln.
82.211.56.146 ist die globale IP des VPN-Server
141.24.53.76 ist die aktuelle globale IP meines Internetanschlusses
192.168.42.0 ist das VPN, hat nur 42.1 für den Server und 42.2 für die FB
192.168.188.0 ist das LAN der FritzBox.
Der VPN-Server macht MASQUARADE mit den aus dem VPN kommenden Paketen.

route vom server
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.42.0    *               255.255.255.0   U     0      0        0 tun0
default         *               0.0.0.0         U     0      0        0 venet0

route der FB (ohne VPN)
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
141.24.53.0     *               255.255.255.0   U     2      0        0 dsl
192.168.188.0   *               255.255.255.0   U     0      0        0 lan
192.168.189.0   *               255.255.255.0   U     0      0        0 guest
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl


route von der FB mit vpn
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
141.24.53.0     *               255.255.255.0   U     2      0        0 dsl
192.168.42.0    *               255.255.255.0   U     0      0        0 tun0
192.168.188.0   *               255.255.255.0   U     0      0        0 lan
192.168.189.0   *               255.255.255.0   U     0      0        0 guest
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl
 
Zuletzt bearbeitet:
dann nimm das 188er netz als route und iroute.
versuch mal def1 bei redirect-gateway.
 
beides Versucht, aber ohne Erfolg. Naja, dann solls wohl nicht. Für heute hör ich erstmal auf...das wird jetzt auch nix mehr. Aber dennoch vielen Dank
 
nimm bitte comp-lzo bei server raus.
hat sich die routingtabelle der fb geaendert?
evtl das redirect-gw bei server rausnehmen und doch den haken in der fb setzen. stehen dann die routen richtig?
beim server sollte ne 188er route auf den tunnel zeigen.
 
Hilft irgendwie alles nicht, OpenVPN erstellt keine Routen und versuche ich es manuell, klappts nur für die FB, nicht fürs angeschlossene Netz.

Was ich gestern komplett vergessen habe, aber auhc nicht Funktioniert. Ich kann vom Server auch nach dem manuellen Setzen der 188er Route nicht die FB über diese IP anspreichen. Muss ich denn noch irgendwas in der AVM-Firewall freischalten?

Aber ich habe einen "Ansatz" für das "NOTE: unable to redirect default gateway -- Cannot read current default gateway from system" Problem. Schaue ich mir nach einen reboot die routen an, fällt auf das über "DSL" drei gehen
Code:
192.168.180.1 dev dsl  metric 2
192.168.180.2 dev dsl  metric 2
141.24.53.0/24 dev dsl  metric 2
192.168.188.0/24 dev lan  src 192.168.188.1
192.168.189.0/24 dev guest  src 192.168.189.1
169.254.0.0/16 dev lan  src 169.254.1.1
default dev dsl  metric 2
und sich openvpn vielleicht daran stört?
 
Zuletzt bearbeitet:
Ja, es geht um die Route auf DSL: Die "redirect-gateway" Option funktioniert auf der FB nicht, weil OpenVPN mit einer vorhandenen Default-Route "auf ein Interface" nicht klar kommt. Das kann nur eine Route "auf eine next-Hop IP".
Da gibt es im Forum ein paar Ansätze zu, wie man "herumarbeiten" kann, müsstest du mal nach "redirect-gateway" suchen....

Eine weitere Möglichkeit wäre, auf den RC von OpenVPN 2.3 zu gehen (ist im Trunk), der kommt nach meiner Erinnerung damit klar...
 
also nochmal wirklich ein rießen Dank an alle Beteiligten, besonders an µRaCoLi, der(die?) sich auch nachts zu später Stunde mit meinen Problem auseinander gesetzt hat.
Dennoch habe ich das ganze aber jetzt verworfen und anders gelöst. Bin in den nächsten Blödmarkt, fürn 10er ne zweite Netzwerkkarte gekauft, in den PC gestopft und nutze die Internetverbindungsfreigabe von Windows. Damit hats dann geklappt. Die FB hab ich zu nen switch degradiert und lasse aufm PC die Verbindung laufen und stelle unter Windows manuell mittels route zwischen nativen und VPN-Internet um, so das die VPN-Verbindung selber dauerhaft bestehen kann. Im groben scheint das geklappt zu haben. Mal sehen wie (in)stabil das ganze letztendlich dann ist.

PS.: dass Freetz hat ich aus dem trunk gebaut....wobei ich da nur openvpn angeklickert habe und kann jetzt nicht mal genau sagen obs 2.2 oder 2.3 war. Müsst ich wenn ich daheim bin nochmal nachschauen, wobei spielt *jetzt* ja auch keine Rolle mehr. Im nächsten Anlauf dann ;)
 
Zuletzt bearbeitet:
Mal sehen wie (in)stabil das ganze letztendlich dann ist.
auf venet0 sollte MASQUERADE nicht vernuenftig laufen, weil es sehr wahrscheinlich auch bei dir 2 ip-adressen hat. SNAT ist hier besser. ich benutze folgendes:
Code:
#!/bin/sh
IPTABLES=/sbin/iptables
EXTIP=$(/sbin/ifconfig venet0:0 | grep -i 'inet' | awk '{print $2}' | cut -d: -f2) 

$IPTABLES -P FORWARD DROP
$IPTABLES -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -i tun+ -o venet0 -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -s 192.168/16 -o venet0 -j SNAT --to-source $EXTIP
 
Hallo,

das Problem hier hört sich so ähnlich an wie bei mir hier:

http://www.ip-phone-forum.de/showthread.php?t=254408

Ihr seit aber schon einen Schritt weite rund scheint iptables mit NAT lauffähig zu haben.

Welchen Freetz trunk und welche AVM Basis FW habt Ihr ?

Danke und Gruß

JMan
 
ich kann natürlich nur für mich reden, aber ich habe kein iptables auf auf der FB am laufen. Dies habe ich ganz klassisch auf einen 3€ vServer.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.