OpenVPN: FBF <--> OpenWRT

Toggle sidebar Toggle sidebar
Upgrade 3CX to v18 and get it hosted free!
Μ

µRaCoLi

Mitglied
Mitglied seit
22 Sep 2005
Beiträge
239
Punkte für Reaktionen
0
Punkte
0
Bin OpenVPN-Anfänger und habe versucht, 2 Netze (192.168.6.0/24 hinter meiner FBF und 192.168.7.0/24 hinter meinem OpenWRT-Router) für gegenseitigen Zugriff zu konfigurieren.
Die vom dsmod generierte conf-datei (server):
Code: 
# OpenVPN 2.1 Config
proto udp
port 1194
dev tun
secret /tmp/flash/static.key
ifconfig 10.8.0.1 10.8.0.2
route 10.8.0.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.6.0 255.255.255.0"
max-clients 5
tun-mtu 1500
mssfix

daemon
verb 3

cipher BF-CBC
route 192.168.7.0 255.255.255.0
keepalive 10 120
Dies ist meine client-config:
Code: 
remote xxx.dyndns.org
proto udp
port 1194
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret "/etc/openvpn/secret.key"
tun-mtu 1492
float
mssfix
#comp-lzo
nobind
verb 3
Und dies kam dabei heraus:
Code: 
root@OpenWrt:/etc/openvpn# openvpn --version
OpenVPN 2.0.8 mipsel-linux [SSL] [LZO] [EPOLL] built on Nov  6 2006
Developed by James Yonan
Copyright (C) 2002-2005 OpenVPN Solutions LLC <[email protected]>
root@OpenWrt:/etc/openvpn# openvpn --config client.conf &
Fri May 18 18:54:41 2007 OpenVPN 2.0.8 mipsel-linux [SSL] [LZO] [EPOLL] built on Nov  6 2006
Fri May 18 18:54:41 2007 WARNING: file '/etc/openvpn/secret.key' is group or others accessible
Fri May 18 18:54:41 2007 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri May 18 18:54:41 2007 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri May 18 18:54:41 2007 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri May 18 18:54:41 2007 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri May 18 18:54:41 2007 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1492)
Fri May 18 18:54:42 2007 TUN/TAP device tun0 opened
Fri May 18 18:54:42 2007 /sbin/ifconfig tun0 10.8.0.2 pointopoint 10.8.0.1 mtu 1492
Fri May 18 18:54:42 2007 Data Channel MTU parms [ L:1536 D:1450 EF:44 EB:4 ET:0 EL:0 ]
Fri May 18 18:54:42 2007 Local Options hash (VER=V4): '84a852d1'
Fri May 18 18:54:42 2007 Expected Remote Options hash (VER=V4): '76a925ec'
Fri May 18 18:54:42 2007 UDPv4 link local: [undef]
Fri May 18 18:54:42 2007 UDPv4 link remote: 87.123.215.39:1194
Fri May 18 18:54:52 2007 read UDPv4 [EHOSTUNREACH]: No route to host (code=148)
Fri May 18 18:55:02 2007 read UDPv4 [EHOSTUNREACH]: No route to host (code=148)
Fri May 18 18:55:12 2007 read UDPv4 [EHOSTUNREACH]: No route to host (code=148)
Fri May 18 18:55:22 2007 read UDPv4 [EHOSTUNREACH]: No route to host (code=148)
Fri May 18 18:55:32 2007 read UDPv4 [EHOSTUNREACH]: No route to host (code=148)
Fri May 18 18:55:42 2007 read UDPv4 [EHOSTUNREACH]: No route to host (code=148)
route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.1        *               255.255.255.255 UH    0      0        0 tun0
192.168.7.0     *               255.255.255.0   U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
Hätte ich hier nicht die Route zum 6er Netz gepusht kriegen sollen?
Versionskonflikt 2.1rc2<-->2.0.8?
Brett vorm Kopf?
Wer weiß Rat?
 
ich bin mir nicht ganz sicher, aber mir wurde mal gesagt, dass der push von route nur mit zertifikaten geht.
ich schau mal ob ich den betrag noch finde.
matze

edit:
hier ist der betrag
 
Ich denke es liegt eher daran, dass du die gepushten Befehle Client-seitig garnicht abholst.
Dafür benötigst du noch ein
Code: 
pull
in der Client-Config
 
Ihr habt beide recht. Pull fehlt und das läuft nur mit TLS...
Hab jetzt diese beiden Zeilen zum client.conf hinzugefügt:
Code: 
route 10.8.0.0 255.255.255.0
route 192.168.6.0 255.255.255.0
Allerdings hab ich damit immer noch keinen Erfolg
Code: 
...snip...
Sat May 19 09:00:14 2007 read UDPv4 [EHOSTUNREACH]: No route to host (code=148)
Sat May 19 09:00:24 2007 read UDPv4 [EHOSTUNREACH]: No route to host (code=148)
route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.1        *               255.255.255.255 UH    0      0        0 tun0
192.168.7.0     *               255.255.255.0   U     0      0        0 br0
192.168.6.0     10.8.0.1        255.255.255.0   UG    0      0        0 tun0
10.8.0.0        10.8.0.1        255.255.255.0   UG    0      0        0 tun0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
Steh voll aufm Schlauch...
 
Zuletzt bearbeitet:
µRaCoLi schrieb:
Code: 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.1        *               255.255.255.255 UH    0      0        0 tun0
192.168.7.0     *               255.255.255.0   U     0      0        0 br0
[B]192.168.6.0     10.8.0.1        255.255.255.0   UG    0      0        0 tun0[/B]
[B]10.8.0.0        10.8.0.1        255.255.255.0   UG    0      0        0 tun0[/B]
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
Zum Vergrößern anklicken....
Sind doch da die Routen?
 
Wie beurteilst du, dass du keine Routen hast? ping-e mal bitte. Wenn es dann nicht geht: Firewalls, Antiviren & Co tools abschalten. Und dann step-by-step in Betrieb nehmen.

MfG
 
Ok, die Routen sind da, aber ein ping auf 10.8.0.1 hat keinen Erfolg. (no route)
Kann höchstens sein, daß 192.168.1.1 etwas wegfiltert, aber da hab ich keinen Einfluß drauf...
Ist der Port 1194 auf der FBF denn standardmäßig offen? Hab leider keinen Zugriff darauf, um das zu testen...
 
Zuletzt bearbeitet:
Nein, nicht offen. Entweder ar7.cfg per hand editieren (mein Favorit), oder Paket virtualip benutzen.
MfG
 
na dann kann ich das ja Morgen korrigieren, wenn ich bei meiner FBF bin. Dropbear hat leider nicht mehr ins Image gepaßt, somit ist das mit der Fernwartung etwas schwierig...
 
Hi,

vielleicht ist für dich auch dieser Thread interessant, scheint mir sehr ähnlich und mit gleicher Fehlermeldung. Dort ging der Tunnel mit TCP, Problem war wohl 'ne Firewall dazwischen, die UDP geblockt hatte...

Jörg
 
Habe jetzt versucht, in der ar7.cfg das portforwarding einzurichten. Das ist leider an einem reproduzierbaren Fehler gescheitert: nach dem Editieren reboote ich, und die Box resettet alle Netzwerk-, DSL- und DynDNS-Einstellungen. Konnte das Problem noch nicht näher einkreisen, glaube aber, daß es mit minifo zusammenhängt, da ich das vorher noch nicht im Mod hatte.
Also habe ich VirtualIP genommen. Hier sagt das Wiki, daß es auch mal nicht läuft mit OpenVPN :-((
Mein Log sieht jetzt so aus:
Code: 
root@OpenWrt:/etc/openvpn# Tue May 22 19:50:57 2007 OpenVPN 2.0.8 mipsel-linux [SSL] [LZO] [EPOLL] built on Nov  6 2006
Tue May 22 19:50:57 2007 WARNING: file '/etc/openvpn/secret.key' is group or others accessible
Tue May 22 19:50:57 2007 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue May 22 19:50:57 2007 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 22 19:50:57 2007 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue May 22 19:50:57 2007 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 22 19:50:57 2007 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1492)
Tue May 22 19:50:57 2007 TUN/TAP device tun0 opened
Tue May 22 19:50:57 2007 /sbin/ifconfig tun0 10.8.0.2 pointopoint 10.8.0.1 mtu 1492
Tue May 22 19:50:57 2007 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.1
Tue May 22 19:50:57 2007 /sbin/route add -net 192.168.6.0 netmask 255.255.255.0 gw 10.8.0.1
Tue May 22 19:50:57 2007 Data Channel MTU parms [ L:1536 D:1450 EF:44 EB:4 ET:0 EL:0 ]
Tue May 22 19:50:57 2007 Local Options hash (VER=V4): '84a852d1'
Tue May 22 19:50:57 2007 Expected Remote Options hash (VER=V4): '76a925ec'
Tue May 22 19:50:57 2007 UDPv4 link local: [undef]
Tue May 22 19:50:57 2007 UDPv4 link remote: 87.123.xxx.xxx:1194
Es kommen keine Fehlermeldungen mehr, daß Routen fehlen, allerdings passiert jetzt rein gar nichts. Pings auf 10.8.0.1 kommen nicht durch...
*ratlos*
Hat vielleicht jemand ein Log eines funktionierenden Openssl mti PSK?
 
Zumindest temporär kannst du das mit dem Port-Forwarding "direkt" testen, wenn du auf die Box kommst. Du kannst du mit ifconfig eth1:1 192.168.1.123 (oder welche Adresse auch immer noch frei ist) eine weitere Adresse auf deiner Box anlegen, auf die du die Weiterleitung per Weboberfläche machen kannst...

Ergänzung: Falls es klappt, kannst du das ifconfig dann per debug.cfg beim Hochfahren machen lassen.

Jörg
 
so mache ich es immer:
Code: 
cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
vi /var/tmp/ar7.cfg
cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg
Klar, wenn du ar7.cfg zerschießt, dann sind alle Einstellungen weg, weil die Box dann die default ar7.cfg aus dem jeweiligen Branding nimmt.
MfG
 
ok, scheint jetzt ansatzweise zu laufen:
Code: 
root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.1        *               255.255.255.255 UH    0      0        0 tun0
192.168.7.0     *               255.255.255.0   U     0      0        0 br0
192.168.6.0     10.8.0.1        255.255.255.0   UG    0      0        0 tun0
10.8.0.0        10.8.0.1        255.255.255.0   UG    0      0        0 tun0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
root@OpenWrt:~# ping 192.168.6.1
PING 192.168.6.1 (192.168.6.1): 56 data bytes
64 bytes from 192.168.6.1: icmp_seq=0 ttl=64 time=42.2 ms
64 bytes from 192.168.6.1: icmp_seq=1 ttl=64 time=43.1 ms

--- 192.168.6.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 42.2/42.6/43.1 ms
root@OpenWrt:~# ping 192.168.6.32
PING 192.168.6.32 (192.168.6.32): 56 data bytes
64 bytes from 192.168.6.32: icmp_seq=0 ttl=127 time=46.5 ms
64 bytes from 192.168.6.32: icmp_seq=1 ttl=127 time=42.0 ms
64 bytes from 192.168.6.32: icmp_seq=2 ttl=127 time=42.8 ms
64 bytes from 192.168.6.32: icmp_seq=3 ttl=127 time=44.3 ms

--- 192.168.6.32 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 42.0/43.9/46.5 ms
Wenn ich das allerdings von einem Client im 7er Netz versuche, dann klappt das nicht:-(
Der Openwrt-Router scheint hier nicht zu routen...
Auch wenn das eher eine Frage fürs Openwrt-Forum wäre, so hoffe ich doch, daß mir jemand weiterhelfen kann.
Code: 
root@OpenWrt:~# cat /proc/sys/net/ipv4/ip_forward
1
Was kann man sonst noch nachschauen?
 
Hi,

könntest du mal einen Trace aus dem Netz am OpenWrt-Router in das andere Netz machen? Am besten einmal auf das 192.168.6.0-er Netz und einmal auf das "Transfernetz" zwischen den Routern (10.8.0.1). Gibt es auf dem OpenWrt-Router eine "Firewall"?

Jörg
 
Firewall war das Stichwort!
hiermit gehts: (für rc6)
/etc/firewall.user
Code: 
iptables -A forwarding_rule -i $LAN -o tun+ -j ACCEPT
iptables -A forwarding_rule -i tun+ -o $LAN -j ACCEPT
Verbindung bricht bei IP-Wechsel ein; hoffe das mit diesen Parametern beim client zu lösen:
Code: 
resolv-retry
ping 10
ping-restart 60
 
Um antworten zu können musst du eingeloggt sein.
Kostenlos!
Jetzt holen

Neueste Beiträge

Kategorien

Wissenswertes

Zurzeit aktive Besucher

Gesamt: 514 (Mitglieder: 11, Gäste: 503)

Statistik des Forums

Themen
248,110
Beiträge
2,281,646
Mitglieder
377,324
Neuestes Mitglied
aonard8

3CX jetzt einen Monat kostenlos testen

Die Verbindung, Zusammenarbeit und Kommunikation mit Ihrem Team und Ihren Kunden war noch nie so einfach. Nutzen Sie unsere kostenlose 30-Tage-Testversion und entdecken Sie die richtige Lösung für Ihr Unternehmen.

3CX start your free trial guy
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.
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten