[Gelöst] OpenVPN, 2x Fritzbox - kein Ping

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
M

ma1

Neuer User
Mitglied seit
25 Jan 2013
Beiträge
17
Punkte für Reaktionen
0
Punkte
1
Hallo,

hab folgenden Aufbau:
2x Fritzbox 7270, beide mit aktuellem Freetz-devel und OpenVPN geflasht
Bei beiden ist LAN1 als Internetzugang konfiguriert und über einen Switch verbunden (Später soll das dann über das DSL laufen, aber zum testen erschien mir das einfacher)
An je einem weiterem LAN-Anschluss hängt ein PC (später dann ein kleines Netzwerk mit Drucker, PC usw)
Nun soll die OpenVPN-Verbindung über die beiden Anschlüsse LAN1 aufgebaut werden.
Dies scheint auch zu funktionieren (in der Freetz-Oberfläche wird der Client als verbunden angezeigt), jedoch bekomme ich keinerlei Verbindung zwischen den beiden PC's bzw den Fritzboxen

Server-Fritzbox:
IP 10.0.0.1/255.255.255.0​
LAN1 10.200.0.1/255.255.255.0​

Client-Fritzbox:
IP 10.0.1.1/255.255.255.0​
LAN1 10.200.0.2/255.255.255.0​

Server
openvpn.conf
Code: 
proto udp
dev tap0
#Helperline for rc.openvpn to add tap0 to lan bridge
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
port 1194
ifconfig 192.168.200.1 255.255.255.0
push "route-gateway 192.168.200.1"
push "route 10.0.0.0 255.255.255.0"
route 10.0.1.0 255.255.255.0 192.168.200.2
max-clients 5
mode server
ifconfig-pool 192.168.200.100 192.168.200.150
push "route 192.168.200.0 255.255.255.0"
client-to-client
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
cipher BF-CBC
float
keepalive 10 120
status /var/log/openvpn.log
chroot /tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

Client-Box
openvpn.conf
Code: 
proto udp
dev tap0
#Helperline for rc.openvpn to add tap0 to lan bridge
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
ns-cert-type server
remote 10.200.0.1
nobind
route 10.0.0.0 255.255.255.0 192.168.200.1
ifconfig 192.168.200.2 255.255.255.0
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
cipher BF-CBC
float
keepalive 10 120
resolv-retry infinite
status /var/log/openvpn.log
chroot /tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

Server-Box ifconfig
Code: 
lan       Link encap:Ethernet  HWaddr 00:1A:4F:06:71:34  
          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::21a:4fff:fe06:7134/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:292 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2635 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:49949 (48.7 KiB)  TX bytes:523873 (511.5 KiB)

tap0      Link encap:Ethernet  HWaddr EA:D2:B2:85:1B:B0  
          inet addr:192.168.200.1  Bcast:192.168.200.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:109 errors:0 dropped:0 overruns:0 frame:0
          TX packets:132 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:21209 (20.7 KiB)  TX bytes:26951 (26.3 KiB)

Client-Box ifconfig
Code: 
lan       Link encap:Ethernet  HWaddr 00:24:FE:11:72:72  
          inet addr:10.0.1.1  Bcast:10.0.1.255  Mask:255.255.255.0
          inet6 addr: fe80::224:feff:fe11:7272/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:279 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2578 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:47159 (46.0 KiB)  TX bytes:516990 (504.8 KiB)

tap0      Link encap:Ethernet  HWaddr FA:8D:39:F7:1C:01  
          inet addr:192.168.200.2  Bcast:192.168.200.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:71 errors:0 dropped:0 overruns:0 frame:0
          TX packets:256 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:23612 (23.0 KiB)  TX bytes:53462 (52.2 KiB)

Server-Box route
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
10.0.0.0        *               255.255.255.0   U     0      0        0 lan
10.0.1.0        192.168.200.2   255.255.255.0   UG    0      0        0 tap0
10.200.0.0      *               255.255.255.0   U     2      0        0 dsl
192.168.200.0   *               255.255.255.0   U     0      0        0 tap0
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

Client-Box route
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
10.0.0.0        192.168.200.1   255.255.255.0   UG    0      0        0 tap0
10.0.1.0        *               255.255.255.0   U     0      0        0 lan
10.200.0.0      *               255.255.255.0   U     2      0        0 dsl
192.168.200.0   *               255.255.255.0   U     0      0        0 tap0
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

Server-Box debug_openvpn.out
Code: 
Fri Jan 25 09:32:55 2013 OpenVPN 2.3.0 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Jan 18 2013
Fri Jan 25 09:32:55 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Jan 25 09:32:55 2013 Diffie-Hellman initialized with 1024 bit key
Fri Jan 25 09:32:55 2013 Socket Buffers: R=[178176->131072] S=[178176->131072]
Fri Jan 25 09:32:55 2013 TUN/TAP device tap0 opened
Fri Jan 25 09:32:55 2013 TUN/TAP TX queue length set to 100
Fri Jan 25 09:32:55 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Jan 25 09:32:55 2013 /sbin/ifconfig tap0 192.168.200.1 netmask 255.255.255.0 mtu 1500 broadcast 192.168.200.255
Fri Jan 25 09:32:55 2013 /sbin/route add -net 10.0.1.0 netmask 255.255.255.0 gw 192.168.200.2
Fri Jan 25 09:32:55 2013 chroot to '/tmp/openvpn' and cd to '/' succeeded
Fri Jan 25 09:32:55 2013 GID set to openvpn
Fri Jan 25 09:32:55 2013 UID set to openvpn
Fri Jan 25 09:32:55 2013 UDPv4 link local (bound): [undef]
Fri Jan 25 09:32:55 2013 UDPv4 link remote: [undef]
Fri Jan 25 09:32:55 2013 MULTI: multi_init called, r=256 v=256
Fri Jan 25 09:32:55 2013 IFCONFIG POOL: base=192.168.200.100 size=51, ipv6=0
Fri Jan 25 09:32:55 2013 Initialization Sequence Completed
Fri Jan 25 09:33:44 2013 10.200.0.2:60004 TLS: Initial packet from [AF_INET]10.200.0.2:60004, sid=4c44bd1c 4fb14099
Fri Jan 25 09:33:45 2013 10.200.0.2:60004 VERIFY OK: depth=1, xxx
Fri Jan 25 09:33:45 2013 10.200.0.2:60004 VERIFY OK: depth=0, xxx
Fri Jan 25 09:33:45 2013 10.200.0.2:60004 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jan 25 09:33:45 2013 10.200.0.2:60004 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 25 09:33:45 2013 10.200.0.2:60004 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jan 25 09:33:45 2013 10.200.0.2:60004 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 25 09:33:45 2013 10.200.0.2:60004 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Jan 25 09:33:45 2013 10.200.0.2:60004 [client01] Peer Connection Initiated with [AF_INET]10.200.0.2:60004
Fri Jan 25 09:33:45 2013 client01/10.200.0.2:60004 MULTI_sva: pool returned IPv4=192.168.200.100, IPv6=(Not enabled)
Fri Jan 25 09:33:48 2013 client01/10.200.0.2:60004 MULTI: Learn: 00:24:fe:11:72:72 -> client01/10.200.0.2:60004
Fri Jan 25 09:33:49 2013 client01/10.200.0.2:60004 MULTI: Learn: fa:8d:39:f7:1c:01 -> client01/10.200.0.2:60004
Fri Jan 25 09:34:39 2013 client01/10.200.0.2:60004 MULTI: Learn: 00:1b:24:17:80:15 -> client01/10.200.0.2:60004

Client-Box debug_openvpn.out
Code: 
Fri Jan 25 09:33:48 2013 OpenVPN 2.3.0 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Jan 18 2013
Fri Jan 25 09:33:48 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Jan 25 09:33:48 2013 Socket Buffers: R=[178176->131072] S=[178176->131072]
Fri Jan 25 09:33:48 2013 TUN/TAP device tap0 opened
Fri Jan 25 09:33:48 2013 TUN/TAP TX queue length set to 100
Fri Jan 25 09:33:48 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Jan 25 09:33:48 2013 /sbin/ifconfig tap0 192.168.200.2 netmask 255.255.255.0 mtu 1500 broadcast 192.168.200.255
Fri Jan 25 09:33:48 2013 /sbin/route add -net 10.0.0.0 netmask 255.255.255.0 gw 192.168.200.1
Fri Jan 25 09:33:48 2013 chroot to '/tmp/openvpn' and cd to '/' succeeded
Fri Jan 25 09:33:48 2013 GID set to openvpn
Fri Jan 25 09:33:48 2013 UID set to openvpn
Fri Jan 25 09:33:48 2013 UDPv4 link local: [undef]
Fri Jan 25 09:33:48 2013 UDPv4 link remote: [AF_INET]10.200.0.1:1194
Fri Jan 25 09:33:48 2013 TLS: Initial packet from [AF_INET]10.200.0.1:1194, sid=3390f5bf 62497944
Fri Jan 25 09:33:48 2013 VERIFY OK: depth=1, xxx
Fri Jan 25 09:33:48 2013 VERIFY OK: nsCertType=SERVER
Fri Jan 25 09:33:48 2013 VERIFY OK: depth=0, xxx
Fri Jan 25 09:33:49 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jan 25 09:33:49 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 25 09:33:49 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jan 25 09:33:49 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jan 25 09:33:49 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Jan 25 09:33:49 2013 [server] Peer Connection Initiated with [AF_INET]10.200.0.1:1194
Fri Jan 25 09:33:50 2013 Initialization Sequence Completed

Vielleicht kann mir jemand weiterhelfen.

Besten dank im voraus
 
Zuletzt bearbeitet:
Was genau hast du denn getestet? Erster Test wäre, ob die "eine VPN-Seite die andere erreicht", also Ping von 192.168.200.1 auf 192.168.200.2.

Ich würde jedoch dringend davon abraten, die Netze per "TAP" miteinander direkt zu verbinden. Die Konfig so wäre prima, wenn du "TUN" nutzt.
Wenn du wirklich unbedingt eine "Brückung" der Netze benötigst, muss auch die Konfig das berücksichtigen (nur ein IP-Kreis auf den beiden
LANs, wer macht DHCP, wo ist das Defaultgateway usw. Du siehst in deinem LOG z.B., dass der Server die LAN(!) MAC-Adresse des Clients über das VPN lernt.)

Ohne "dringenden Bedarf" und entsprechende Konfig (die, ohne dir persönlich zu nahe treten zu wollen, oft einiges an "Wissens-Erweiterung" bedarf)
ist eine "Netzkoppelung" über Tunnel die deutlich bessere Lösung.
 
Ja das war der erste Test. Ich hab von der einen Fritzbox versucht, die andere anzupingen. Also mit ping 192.168.200.1 bzw. umgekehrt.
Aber selbst das geht nicht.

Werde deinen Rat befolgen und das morgen mal mit TUN probieren.

Jedoch würde es mich trotzdem interessieren, warum ich bei TAP keinen Ping zwischen den beiden Fritzboxen zusammen bekomme.

Trotzdem schon mal Danke für die Antwort.
 
Zuletzt bearbeitet:
Entweder es liegt an dem Haken bei "mit LAN brücken". Sind die Boxen LAN- und WLAN-mäßig komplett getrennt?!?

Oder es liegt am "IP-Pool", denn du hast der Server-Box gesagt, IPs ab 192.168.200.100 zu vergeben, der Client-Box aber "fest" die 192.168.200.2 gegeben.
Eventuell will die Server-Box die Client-Box mit der 192.168.200.100 ereichen?
Du könntest mal schauen, ob die ARP-Auflösung geht: Ping und dann ein "arp -an". Das sollte zur IP der anderen Box die MAC-Adresse des TAP anzeigen.

Ansonsten mach es doch mal so:
Weise beim Server dem Client mit dem Namen "client01" in der "erweiterten Clientconfig" fest eine IP zu und trage dort das LAN beim Client ein.
Beim Client dann IP und Route entfernen und "auch IP vom Server empfangen" anhaken, dann klappt das auch.

Hatte ich erst übersehen: Das mit der "erweiterten Client-Config" ist bei dir sowieso erforderlich, damit dann Geräte aus dem LAN beim Client in das Netz beim Server kommen (Falls du es weiter vertiefen willst: "mode server" benötigt einen "iroute" Eintrag, um ein Netz beim Client zu verwalten)
 
Zuletzt bearbeitet:
Ja, die Boxen sind komplett getrennt.
Also nur über einen Switch über LAN1 verbunden und je ein PC an LAN4.

Aber mir scheint, das mir da die Konfiguration über LAN1 Probleme macht, denn selbst ein Ping von einer Fritzbox auf die andere Box klappt nicht (egal ob Openvpn läuft oder nicht), obwohl ich mir sicher war, das das am anfang funktioniert hatte.
Versteh jedoch nicht, wie dann die Verbindung erfolgreich aufgebaut werden kann.
Ich werd das ganze wohl doch nochmal über DSL testen und meld mich dann wieder.

Danke für deine Mühe bisher, MaxMuster.
Auch werd ich das doch noch mit dem TAP weiter vertiefen, will ja auch was lernen.
 
Zuletzt bearbeitet:
ma1 schrieb:
... selbst ein Ping von einer Fritzbox auf die andere Box klappt nicht (egal ob Openvpn läuft oder nicht), obwohl ich mir sicher war, das das am anfang funktioniert hatte.
Zum Vergrößern anklicken....
Zumindest bei den neueren FW der 7390 konnte man "seine eigene" externe IP aus dem LAN nicht erreichen, ich meine aber das war "von extern" weiterhin möglich. Kann vielleicht sein, dass das in deiner Firmware von AVM deaktiviert wurde?
 
Ok. Ich hab jetzt alles zurück gesetzt.
Kann jetzt wieder die eine Box von der anderen anpingen (LAN1 10.0.0.1/10.0.1.1).
 
MaxMuster schrieb:
Ansonsten mach es doch mal so:
Weise beim Server dem Client mit dem Namen "client01" in der "erweiterten Clientconfig" fest eine IP zu und trage dort das LAN beim Client ein.
Beim Client dann IP und Route entfernen und "auch IP vom Server empfangen" anhaken, dann klappt das auch.

Hatte ich erst übersehen: Das mit der "erweiterten Client-Config" ist bei dir sowieso erforderlich, damit dann Geräte aus dem LAN beim Client in das Netz beim Server kommen (Falls du es weiter vertiefen willst: "mode server" benötigt einen "iroute" Eintrag, um ein Netz beim Client zu verwalten)
Zum Vergrößern anklicken....

Hab ich jetzt so gemacht. Der Client bekommt auch die Adresse 192.168.200.100 aber ein Ping auf 192.168.200.100 klappt trotzdem nicht von der Server-Fritzbox.
Außerdem bekomme ich jetzt im debug-Log des Servers den Hinweis: "MULTI --iroute options rejected for client01/10.200.200.1:49337 -- iroute only works with tun-style tunnels".
 
Danke cloudmember.

mit ping auf 10.0.1.1 von der Serverbox bzw. umgekehrt steht dann folgendes in /proc/net/arp

Serverbox:
Code: 
IP address       HW type     Flags       HW address            Mask     Device
10.0.0.20        0x1         0x2         00:40:d0:5f:2b:d5     *        lan
192.168.200.100  0x1         0x0         00:00:00:00:00:00     *        tap0

Clientbox:
Code: 
IP address       HW type     Flags       HW address            Mask     Device
10.0.1.21        0x1         0x2         00:1b:24:17:80:15     *        lan
192.168.200.1    0x1         0x0         00:00:00:00:00:00     *        tap0
 
Ich meinte erstmal einen Ping auf die "VPN-IP" der Gegenseite, also die 192.168.200.1 bzw .192.168.200.100 und dann den "arp". Hast du den Haken bei "mit LAN brücken" rausgenommen?!?
 
Super, an dem Haken bei "LAN brücken" lags.
Ping klappt jetzt.


Was bedeutet jetzt die Meldung im Serverlog ?
MULTI: --iroute options rejected for client01/10.200.0.2:60121 -- iroute only works with tun-style tunnels
 
Wenn du noch mit "TAP" arbeitest, kannst/brauchst du die Netze nicht dem Client zuordnen.

Bei "TUN" kennt die FB selbst nur eine Route zum VPN-Prozess. Das VPN selbst kann aber mit dem üblichen Befehl "rote <irgendein Netz> <Netzmaske>" noch nicht auskommen.
Es muss noch eingetragen werden, zu welchem Client das Netz muss, und das passiert mit dem "iroute", das die "erweiterte Config" anlegt (das müsste ich für TAP mal rausnehmen, denn das ist so scheinbar ein Fehler in der Auswertung der GUI).
Bei "TAP" ist das VPN-Netz ja quasi für die FB selbst bekannt, der Routingprozess kann jeden Client "selbst adressieren", so dass eine Route der Art "route <irgendein Netz> <Netzmaske> <TAP-IP des entsprechenden Clients>"

"Workaround": Nimm das "Netz beim Client" aus der Tabelle raus und trage das Netz doch wieder bei "enferntes Netz" ein:
10.0.1.0 255.255.255.0 192.168.200.100

EDIT:
Versuch sonst doch mal diesen Workaround. Mache im freetz Ordner:
Code: 
sed -i '/iroute/ s#echo# [ "$TYPE" = "tun" ] \&\& echo#'  make/openvpn/files/root/etc/default.openvpn/openvpn_conf
Und baue ein neues Image.
 
Zuletzt bearbeitet:
MaxMuster schrieb:
EDIT:
Versuch sonst doch mal diesen Workaround. Mache im freetz Ordner:
Code: 
sed -i '/iroute/ s#echo# [ "$TYPE" = "tun" ] \&\& echo#'  make/openvpn/files/root/etc/default.openvpn/openvpn_conf
Und baue ein neues Image.
Zum Vergrößern anklicken....

Hab ich getestet und die Meldung ist weg. Danke schön.
 
Danke für die Rückmeldung, Fix ist seit REV 9990 auch im Trunk
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 456 (Mitglieder: 3, Gäste: 453)

Neueste Beiträge

Statistik des Forums

Themen
246,779
Beiträge
2,257,309
Mitglieder
374,814
Neuestes Mitglied
soundworx
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück